- dns-wg - mailman.ripe.net

Re: domain name for european parliament
by Werner Vogels 18 Jan '93

18 Jan '93

I have been passed on the following message and would like to comment on it: > Subject: Re: domain name for european parliament > > Cc: dns-wg(a)ripe.net, Pierre.Verbaeten(a)cs.kuleuven.ac.be > Date: Mon, 18 Jan 1993 12:29:54 +0100 > From: Piet Beertema <Piet.Beertema(a)cwi.nl> > > If you think thats funny then check this one out: > > whois -h nic.ddn.mil "ec.org" > Commission of the European Communities (EC1-DOM) > Directorate-general Telecommunications, Information > Industry and Innovation. Rue de la loi, 200 > B-1049 Brussel, Belgium > > Domain Name: EC.ORG > > Administrative Contact: > Mullender, Sape (SM3383) Mullender(a)cs.utwente.nl > +31 53 89 3709 > Technical Contact, Zone Contact: > Vogels, Werner (WV33) werner(a)inesc.pt > +351 1 3100316 > > Record last updated on 20-Feb-92. > > Domain servers in listed order: > > FREYA.INESC.PT 146.193.4.36 > HELIOS.CS.UTWENTE.NL 130.89.15.6 > > > Yes - we told them it might not be a good idea in the > long term but what can you do.... > > Not much. It's a bit surprising though that the NIC did > accept this registration from people outside DG. We have been funded by the CEC/BRA to set up an support infrastructure to help researchers in Europe exchange information and to supply support for issues like storage, naming, etc. The infrastructure is based on a large number of fileservers throughout Europe using AFS as main technology. Although in the startup phase aiming to support the nodes covered by the three first Networks Of Excellence: ELSNET, CaberNet and Compulog, the infrastructure is supposed to be the blueprint for an infrastructure also covering the new NOE's formed last year. In the framework of naming we wanted to enable resolution through the DNS. As there was no top domain available that would cover a general CEC organization, under which the infrastructure could be placed, we requested (with full knowledge and appreciation of DG) a domain name for a top domain ec.org. This domain was to be managed by the Infrastructure Task Force of the proposed infrastructure for a startup-period, after which the management of the top domain would be handed over to an institution selected by DG. The subdomains dedicated to the research infrastructure would still be managed by our own people. (Instead of calling it "funny", Dave, you could have explained all this as you are aware of most of the details of the infrastructure provision, including the naming part) > And as > far as the nameservers are concerned: ..... > So not to be taken serious. I do not think that is a remark to be made without any further consultation of the people involved. At the time of registration of the ec.org name, the machines to run the servers were not yet delivered. The two names were supplied to the NIC as being "temporary", to be replaced as soon as the initial part of the research infrastructure was in place. The first two servers (INESC and Univ. of Twente) are running now, while this week the servers at the Univ. of Newcastle and at LAAS will be added. Our first concern is to have the AFS servers properly running, after that the NIC will be informed about which machines will provide the DNS service. If there are any other areas related to the CEC that want to make use of the ec.org name they are happily invited to cooperate in managing a possible subdomain of ec.org. In our planning we aim to provide DNS service starting half of February. Hope this clears up the confusion. Werner Vogels Distributed Systems and Industrial Automation Group INESC - Instituto de Engenharia de Sistemas e Computadores Rua Alves Redol, 9-6o - 1000 Lisboa - Portugal Tel: +351 1 3100316, Fax: +351 1 525843, e-mail: werner(a)inesc.pt / C=pt;A= ;P=inesc;S=werner

2 2

Re: domain name for european parliament
by Dave Morton 18 Jan '93

18 Jan '93

> I would like some advice on the most appropriate > top level domain. > I see 3 alternatives: > 1. Creation of a new top level domain. They already proposed > eur > Considering the status of the European Community, such a > request looks reasonable to me. >Yet another non-standard (non-ISO3166) top level domain? >Yech! Who is going to register it? Who is going to manage >it? Who can register it? It's opening a can of worms... If you think thats funny then check this one out: whois -h nic.ddn.mil "ec.org" Commission of the European Communities (EC1-DOM) Directorate-general Telecommunications, Information Industry and Innovation. Rue de la loi, 200 B-1049 Brussel, Belgium Domain Name: EC.ORG Administrative Contact: Mullender, Sape (SM3383) Mullender(a)cs.utwente.nl +31 53 89 3709 Technical Contact, Zone Contact: Vogels, Werner (WV33) werner(a)inesc.pt +351 1 3100316 Record last updated on 20-Feb-92. Domain servers in listed order: FREYA.INESC.PT 146.193.4.36 HELIOS.CS.UTWENTE.NL 130.89.15.6 To see this host record with registered users, repeat the command with a star ('*') before the name; or, use '%' to show JUST the registered users. Yes - we told them it might not be a good idea in the long term but what can you do.... Dave

3 2

secondary server needed
by bonito＠nis.garr.it 18 Jan '93

18 Jan '93

Hallo folks, I need to replace one of the secondary servers for reverse 131.114 PISA-NET Can you suggest me any good volunteer in Europe? Thanks in advance ---------- ---------- Antonio_Blasco Bonito E-Mail: bonito(a)nis.garr.it GARR - Network Information Service c=it;a=garr;p=garr;o=nis;s=bonito c/o CNUCE - Istituto del CNR Tel: +39 (50) 593246 Via S. Maria, 36 Telex: 500371 CNUCE I 56126 PISA Italy Fax: +39 (50) 589354 ---------- ----------

1 0

domain name for european parliament
by Pierre.Verbaeten＠cs.kuleuven.ac.be 15 Jan '93

15 Jan '93

Hello, I received a request for a domain name from the European Parliament. They propose the name ep which is acceptable; I would like some advice on the most appropriate top level domain. I see 3 alternatives: 1. Creation of a new top level domain. They already proposed eur Considering the status of the European Community, such a request looks reasonable to me. Is the also acceptable? Better names? 2. Use an existing top level domain such as int (and join "nato" there). 3. Register ep under be (because the current connection is realized in Belgium). From a political point of view this is not a good solution. I would probably also imply that they will register also ep.fr ep.lu I suggest to discuss this in Praag. Regards, Pierre

3 3

Problems with bind.4.8.3
by Willi Huber 22 Dec '92

22 Dec '92

we have discovered a problem with our bind.4.8.3. It does not correctly handel records of type TXT for zones where our DNS is a secondary for. What version of bind is the current production version and where can the source or patches be obtained from? What versions do you use? I have heard of the alpha and beta tests of a new version of bind, but I'd rather prefer, as I said, a production version. Willi Huber

4 3

DNS settings for '.tr' domain
by Attila OZGIT 20 Oct '92

20 Oct '92

Dear DNS-WG people, We would like our domain to be registered officially under Internet's world-wide name servers. At the moment we are using an IP/X25 link to NIKHEF (9.6K). In almost 2 months we will have our primary IP link to ICM/NSF (64K). We will be running our primary name server for .tr at IP address 144.122.199.20 (an HP-UX machine), and secondary name server at IP address at 144.122.1.1 (an IBM VM/XA with TCP/IP v2.2). I suppose, we should know the IP numbers of name servers running on your side, and the the rest of the world should know about name servers for .tr domain. Please let us know in case you need more information from our side. IP number assignment, and physical connection to NIKHEF are being handled by Marten Terpstra. Thanks in advance, Attila Ozgit

2 1

Re: To get things started
by Matti.Rendahl＠bion.kth.se 15 Oct '92

15 Oct '92

> Matti Rendahl from NORDUnet, who's also on this list, is managing the > nameserver at nic.nordu.net, and promised to give some input on the impact of > having a rootserver, to the group. I know it was something that had high priority when I got back from vacation, sorry about the delay, and sorry about this brief and hasty contribution (I really was planning to get to Paris, but there is no time for that). > One of the "hot" items that have to be discussed is wether we need another > root name server in Europe. My guess would be yes. Yes, I really think we do. And the larger the European IP community gets, the more we need the redundancy in root servers here. > I think it is the task of this working group to get input from people wanting > to set up another root-server, make them aware of the consequences in terms > of manpower, hardware, connectivity (especially the last one, since a root > server must be reachable from EVERY single host on the Internet). First let me summarize: Regarding manpower, not very much is needed in hours, more in alertness. And when looking at hardware, a SparcStation 1 with 500M disk and 16M memory will do. The crucial point is the connectivity, this must be good, otherwise there is not much use adding one more root server. 1) manpower It is not that much work to get the server to run, the only thing that must be done/checked is to pickup the new zone files from nic.ddn.mil (with ftp, zone-transfers won't do). This can be made with a script (a mail message is sent when the new files are available), even if I prefer to do it manually as the transefer fails every now and then (or the zone files themself can be corrupt/ truncated). The important thing is that the new zone files is loaded ASAP, and that the servers continues to work after this (can be checked with e.g. doc). Checking that the server is running is easy with a script, and as BIND crashes every now and then this is vital. The zone files are updated twice a week (Tuesday and Thursday, late evening MET). 2) hardware NIC.NORDU.NET is a SparcStation 1, and this works nice (we tried an ELC, but that didn't really work, don't know if it was the e-net interface or what, but it didn't really manage the load). If it is only used for the name server, I would say that 16M memory will do, BIND tends to get big, lots of cache. The zone files does not require much disk, but if one like to log questions (LOGIT patches) a few 100M disk is needed for the server. (We scratch the log every 24 hours at nordunic, but the daily log can get > 100M.) (To process these large logfiles you need more memory...) The root servers are all (?) running BIND 4.8.3, but there is no real coordination that they have the same patches applied &c. There are som patches available to disable zone transfers except from "trusted" hosts (to get some load of the network), and to disable recursive queries. 3) connectivity This is really important, there is no use in adding one more root server if it is not well connected. (Networks that have problems with bad connectivity should set up a fake root server, like we did here at nordunic, not apply for a root server. There are ways to manage a fake server so that it in all except the NS list for `.' is a mirror of the real root servers. The fake root server we had on nordunic was most of the time more in sync with NIC.DDN.MIL that the real ones :-) It is also required for the root server to act as a primary server for the 3-letter zones and ARPA/IN-ADDR.ARPA as well as the root zone. And it is preferred that is also a server for the zone it resides in. To get an idea of the load, here is the monthly statistics from nordunic (note: nordunic does recursive lookup, but those questions is not included in this, this is only the questions received bye nordunic). I haven't really checked, but I think one can see an increase in load that to some extent reflects the upgrades of lines to both Europe and US. Month Questions Day min Day max Day mean Q/sec 9107 8315817 22211 981077 277193 3 9108 10171786 58963 797348 339059 4 9109 8997370 2882 957857 299912 3 9110 11810123 8167 3178018 393670 5 9111 6837735 28871 1046749 227924 3 9112 10124765 24931 1665318 337492 4 9201 33076339 11873 3510106 1102544 13 9202 31598520 16778 3478439 1053284 12 9203 17007590 8843 1628033 566919 7 9204 24153201 29870 4394418 805106 9 9205 26104016 27969 3461392 870133 10 9206 49711587 939 4426938 1657052 19 9207 43547168 30481 5350535 1451572 17 9208 76186421 92550 7481229 2539547 29 I'm working with a program that should be able to give more information from the logs than this and Top-10 lists. Would be nice to get some kind of indication about from where the questions are generated, I know that we see a lot of questions from the US, but I have no real feeling for how the geographic distribution looks. I have some figures about DNS/UDP traffic also, but I can't find them right now. But if I remember correct, it was a few % of the total use (which is "normal" DNS usage), with ftp(.funet.fi) as the winner :-) Matti ------------------------------------------------------------------------------ Matti Rendahl | SUNET/NORDUnet Operation Center | Phone: +46 8 7907224 | Royal Institute of Technology, KTH | Fax: +46 8 7230302 | S-100 44 Stockholm, Sweden | Internet: matti(a)nordu.net

4 4

Re: Suggestion from Piet Beertema
by Arnold Nipper 23 Jul '92

23 Jul '92

> As far as I remember there is a "*di" - tag for domain name > entries listing IP adresses used in this domain. Hence no > usual "nslookup"! >A "*di" tag may ever have been proposed, but I don't >see it in any of the RIPE templates. Just have a look at document "ripe-w02" chapter 2.1 (RIPE Databases; R.Blokzijl <k13(a)nikhef.nl>; 28 August, 1990) Arnold

3 5

Re: Suggestion from Piet Beertema
by root＠estec.esa.nl 22 Jul '92

22 Jul '92

thank you the only OSF offices that i know of are in Munich, the US and Japan regards

2 1

Re: Suggestion from Piet Beertema
by Arnold Nipper 22 Jul '92

22 Jul '92

> Suppose "nslookup" does domain name to adress translation, > "net" does IP adress to IP net translation and finally > "connect" gives the connect information about IP networks What I was thinking of was the "*n[io]" - tag already used. (e.g: *ni: 1=701 2=1800 3=1238 ) > (This information already is in the RIPE DB), then > connect ( net ( nslookup ( domain name ) ) ) > does what you want. >No, it doesn't. The connect field gives the connectivity >a given network has, partly in "real" connectivity (e.g. >"EU"), partly in "pseudo" connectivity ("RIPE"), but it >doesn't state which the network service providers are nor >nor the order in which these are service providers. And >the latter is extremely important for determining policy >based routing. The least that should be done to treat the >connect field as routing source is to list the mnemonics >that stand for the real service providers in order of >routing preference (for the associated network of course). >However, I don't like this "solution" at all, given the >mix of "real" and "pseudo" connectivity in the connect >field. Besides, a new field could be based an AS numbers >in order of preference, much like the NSFnet policy routing >database does now, making life infinitely easier. > >Furthermore I would consider building potentially large >access or other lists for a router in the suggested way, >through massive DNS queries, a crime... As far as I remember there is a "*di" - tag for domain name entries listing IP adresses used in this domain. Hence no usual "nslookup"! > > Don't overload the DB with information (Current size: 7315558 Byte. > We started with some hundred KB). >It will keep on growing anyway, especially when the RIPE, >NIC and Merit databases get synchronized. Database size >should not be used as an argument to keep out *useful* Don't misunderstand me!! I don't want to keep out *useful* information. I just want to minimize and streamline the DB. Keep the DB as small as possible and join the information on your local machine (NO DNS lookups!). >and authoritative information. > > > Piet Arnold

2 1