- dns-wg - mailman.ripe.net

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

Suggestion from Piet Beertema
by Daniel Karrenberg 22 Jul '92

22 Jul '92

------- Forwarded Message Date: Tue, 21 Jul 1992 11:45:04 +0200 From: Piet.Beertema(a)mcsun.EU.net Sender: piet(a)mcsun.EU.net To: ncc(a)ripe.net Subject: Suggestion Add a "connect" field to domain entries, showing the service provider(s) for a particular domain; alternatively set up a new field for it, although I can't think of an appropriate name for it right away. This feature would be valuable, as it would provide sites all over Europe with the possibility to exert access control on domain names, using the RIPE whois database as authoritative source (like it is used already for e.g. router access lists). Piet ------- End of Forwarded Message

2 1

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

22 Jul '92

>Subject: Suggestion from Piet Beertema >From: Daniel Karrenberg <Daniel.Karrenberg(a)ripe.net> >Date: Wed, 22 Jul 92 13:52:14 +0200 >Sender: Daniel.Karrenberg(a)ripe.net > >------- Forwarded Message > >Date: Tue, 21 Jul 1992 11:45:04 +0200 >From: Piet.Beertema(a)mcsun.EU.net >Sender: piet(a)mcsun.EU.net >To: ncc(a)ripe.net >Subject: Suggestion > >Add a "connect" field to domain entries, showing the service >provider(s) for a particular domain; alternatively set up a >new field for it, although I can't think of an appropriate >name for it right away. >This feature would be valuable, as it would provide sites all >over Europe with the possibility to exert access control on >domain names, using the RIPE whois database as authoritative >source (like it is used already for e.g. router access lists). > > > Piet > >------- End of Forwarded Message 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 (This information already is in the RIPE DB), then connect ( net ( nslookup ( domain name ) ) ) does what you want. What I want to say is: a domain name ( when used acessing a site ) can be mapped onto an IP address. Don't overload the DB with information (Current size: 7315558 Byte. We started with some hundred KB). Arnold

2 1

Re: Domains in the RIPE database
by rafal＠cocos.fuw.edu.pl 06 Jul '92

06 Jul '92

Yes, in my opinion this information is spurious while causing unnecesary work for the NCC sfaff. As such the domain registration should be discontinued. Rafal

1 0

Domains in the RIPE database
by Daniel Karrenberg 06 Jul '92

06 Jul '92

While I am busy asking difficult questions :-). Recent statistics show that the number of domain entries in the RIPE database is increasing at a sub-linear rate. I infer from this that by far not all European domains are represented by domain objects in the database. At the same time RFC1183 defines a method of incorporating contact information for zones into the DNS itself. Doesn't this invalidate the rationale for keeping information about domains in the database? Should we discontinue the domain object in the database? Daniel

2 1

NCC to provide secondary name service for Top Level Domains?
by Daniel Karrenberg 06 Jul '92

06 Jul '92

Thomaz Kalin has raised the question with me whether the NCC should provide secondary domain service for top level domains with servers located in Europe and (by arrangement) on other continents. Should this be added to the NCC activity plan? So far my personal experience has been that all top level domain administrators have been able to make satisfactory arrangements for this service. Daniel

2 1