From Carol.Orange at ripe.net Tue May 13 10:44:31 1997 From: Carol.Orange at ripe.net (Carol Orange) Date: Tue, 13 May 1997 10:44:31 +0200 Subject: A DNS Database Referral Mechanism Message-ID: <9705130844.AA08931@ncc.ripe.net> Hi all, Below is a proposal put together by Wilfried Woeber and myself to address the need for a referral mechanism for domain name queries in the RIPE database. The mechanism is designed to address the immediate needs of those trying to get domain related information, and of DNS administrators trying to provide it. Certainly the mechanism may be adapted with time (see the three options below), however we choose to start with something that can provide the required functionality immediately. We hope to discuss this proposal on the mailing lists and in the database and dns working group meetings in Dublin. Carol Orange RIPE NCC --------------------------------------------------------------------- RIPE Database Referral Mechanism for Domain Queries - A Proposal Carol Orange & Wilfried Woeber, April 1997 ------------------------------------------ In the following, we propose a mechanism for forwarding whois queries to the appropriate database if the RIPE database does not contain the authoritative data for a given tree in the DNS name space or subset thereof. It is thus applicable for the "domain" object only: domain: [mandatory] [single] descr: [mandatory] [multiple] admin-c: [mandatory] [multiple] tech-c: [mandatory] [multiple] zone-c: [mandatory] [multiple] nserver: [optional] [multiple] sub-dom: [optional] [multiple] dom-net: [optional] [multiple] remarks: [optional] [multiple] notify: [optional] [multiple] mnt-by: [optional] [multiple] mnt-lower: [optional] [multiple] changed: [mandatory] [multiple] source: [mandatory] [single] The goal of the mechanism is to provide a means for TLD domain administrators (and other "high-level" domains) to enable users to obtain an authoritative response for a domain object query sent to the RIPE database, regardless of whether the data for the domain is maintained in the RIPE database itself. Algorithm --------- If the following query is submitted to the RIPE database: whois [flags] xxx.yyy.zz the algorithm will work as follows: ------- NAME="xxx.yyy.zz" until (NAME = "") { If object with domain = NAME found, If object contains referral (see "Referral" below) forward query (see "Forward" below) Else return object Else Strip(NAME) (xxx.yyy.zz -> yyy.zz, etc) } NOTES ----- 1. We move up the tree here, and return the next level answer if present. If the query requests "tuintje.cwi.nl" (Piet, do you mind?), they currently get "No entries found ...". In the new mechanism, they would get: domain: cwi.nl . . . mnt-by: NL-DOMREG changed: hostmaster at domain-registry.nl 19950227 source: RIPE Moreover, if the object for cwi.nl contains a referral, the query would be passed on to the specified server as explained below. 2. The algorithm will be set off by any query which causes a search in the domain object index. This means any query with "-T domain", or any general query (no -T flag) with something that "looks like a domain". Referral -------- A whois referral can be entered in a "refer" attribute by specifying the type of database in which the data is maintained, and the domain name of the server that should be queried: refer: where is one of RIPE, InterNIC or SIMPLE, indicating which style of whois service is provided. is the DNS name of the whois service. is the TCP port number (optional: 43 is the default). Examples: (CWI again): refer: RIPE domain-registry.nl 43 (InterNIC): refer: InterNIC whois.internic.net (Generic): refer: SIMPLE my.dns.tld Initially queries for the three types of databases shown here would be supported. If RIPE is specified, then the initial query together with all arguments would be passed to the specified whois server. If an InterNIC database is specified, then a query expected by the InterNIC database software would be generated for the specified domain name. The same would be true of "SIMPLE". In that case a simple query for the domain name would be passed on. If in the future, another domain name database is implemented with a given query language, it can be added. Forward ------- If the TLD object contains a whois referral, we can a) query the server, and pass the response to the requester, preceded by a comment of the form: "The following data has been obtained from domain-registry.nl". b) pass the referral to the requester c) send the query to the server with the address of the requester a) has the advantage of giving the user an immediate answer, and requires that only the RIPE database software be modified, not that of the TLD admins. Nothing has to be changed there. a) has the disadvantage that the RIPE server can become a bottleneck. However, local mirrors of referred to databases can be set up on a RIPE NCC server to alleviate this problem. Summary ------- We propose the above mechanism with (option (a) request forwarding) be used for TLD/domain referrals. We believe it will make the domain part of the database more transparent to users and easier to manage for TLD administrators. Acknowledgements ---------------- We would like to thank Chris Fletcher, Daniel Karrenberg, and David Kessens for useful comments. From bonito at nis.garr.it Tue May 13 12:59:04 1997 From: bonito at nis.garr.it (Antonio-Blasco Bonito) Date: Tue, 13 May 1997 12:59:04 +0200 (MET DST) Subject: A DNS Database Referral Mechanism In-Reply-To: <9705130844.AA08931@ncc.ripe.net> from "Carol Orange" at May 13, 97 10:44:31 am Message-ID: <199705131059.MAA05284@cuori.nis.garr.it> Quoting from Carol Orange's message: > > > Hi all, > > Below is a proposal put together by Wilfried Woeber and myself to > address the need for a referral mechanism for domain name queries in > the RIPE database. > > The mechanism is designed to address the immediate needs of those > trying to get domain related information, and of DNS administrators > trying to provide it. Certainly the mechanism may be adapted with time > (see the three options below), however we choose to start with > something that can provide the required functionality immediately. > > We hope to discuss this proposal on the mailing lists and in the > database and dns working group meetings in Dublin. > > Carol Orange > RIPE NCC Hi Carol, would it be possible to implement the suggestion made by Robert Martin-Legene ? It is more flexible... Date: Mon, 28 Apr 1997 17:16:09 +0200 (MET DST) From: Robert Martin-Legene > Forward > ------- > If the TLD object contains a whois referral, we can=20 >=20 > a) query the server, and pass the response to the requester, preceded > by a comment of the form: "The following data has been obtained from=20 > domain-registry.nl". > b) pass the referral to the requester > c) send the query to the server with the address of the requester I like the a) as well, but it shouldn't be a problem doing all three and let it be up the the owner of the object. Then the refer attrib could be refer: [] I guess the whois-server-type isn't needed on forward-type b, but it look= s good for consistency... (it's up to the client to use it then) -- Robert Martin-Leg=E8ne (RM59), Network Manager (AS2109) From Piet.Beertema at cwi.nl Tue May 13 17:25:29 1997 From: Piet.Beertema at cwi.nl (Piet Beertema) Date: Tue, 13 May 1997 16:25:29 +0100 Subject: A DNS Database Referral Mechanism In-Reply-To: <9705130844.AA08931@ncc.ripe.net> Message-ID: <3.0.1.16.19970513162529.29df2dc8@mail.cwi.nl> >Below is a proposal put together by Wilfried Woeber and myself to >address the need for a referral mechanism for domain name queries in >the RIPE database. At last... the long asked-for and long waited-for automatic whois query forwarding. Great! So we can get rid of the kludge of having to put the info in a remark field, suitable for humans only, which in many cases don't even know how to handle the info presented... Piet From Piet.Beertema at cwi.nl Tue May 13 17:37:59 1997 From: Piet.Beertema at cwi.nl (Piet Beertema) Date: Tue, 13 May 1997 16:37:59 +0100 Subject: A DNS Database Referral Mechanism In-Reply-To: <199705131059.MAA05284@cuori.nis.garr.it> References: <9705130844.AA08931@ncc.ripe.net> Message-ID: <3.0.1.16.19970513163759.29df9da0@mail.cwi.nl> >would it be possible to implement the suggestion made by Robert >Martin-Legene? It is more flexible... >> If the TLD object contains a whois referral, we can >> a) query the server, and pass the response to the requester, preceded >> by a comment of the form: "The following data has been obtained from >> domain-registry.nl". >> b) pass the referral to the requester >> c) send the query to the server with the address of the requester More flexible and more complicated. What exactly is the gain over the original, more simple proposal? Piet From woeber at cc.univie.ac.at Tue May 13 17:09:08 1997 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Tue, 13 May 1997 17:09:08 MET-DST Subject: A DNS Database Referral Mechanism Message-ID: <009B4348.D56C92AE.42@cc.univie.ac.at> >Subject: A DNS Database Referral Mechanism >Date: Tue, 13 May 1997 10:44:31 +0200 >From: Carol Orange Dear Carol! >Hi all, > >Below is a proposal put together by Wilfried Woeber and myself to >address the need for a referral mechanism for domain name queries in >the RIPE database. Thank you very much for putting that into proper wording and having it distributed to the groups. I feel it is appropriate to add that, while Carol and me did some finishing and sanity checking, we already received a considerable amount of very valuable comments and ideas from quite a few others. A big thank you to all of them! I thus urge the community to have a focussed discussion of the proposal, leading to a conclusion and implementation decision at the DNS & DB-WG meeting(s) is Dublin. Thanks, Wilfried. -------------------------------------------------------------------------- Wilfried Woeber : e-mail: Woeber at CC.UniVie.ac.at Computer Center - ACOnet : Vienna University : Tel: +43 1 4065822 355 Universitaetsstrasse 7 : Fax: +43 1 4065822 170 A-1010 Vienna, Austria, Europe : NIC: WW144 -------------------------------------------------------------------------- From bonito at nis.garr.it Tue May 13 17:43:20 1997 From: bonito at nis.garr.it (Antonio-Blasco Bonito) Date: Tue, 13 May 1997 17:43:20 +0200 (MET DST) Subject: A DNS Database Referral Mechanism In-Reply-To: <3.0.1.16.19970513163759.29df9da0@mail.cwi.nl> from "Piet Beertema" at May 13, 97 04:37:59 pm Message-ID: <199705131543.RAA09110@cuori.nis.garr.it> Quoting from Piet Beertema's message: > > > >would it be possible to implement the suggestion made by Robert > >Martin-Legene? It is more flexible... > > >> If the TLD object contains a whois referral, we can > >> a) query the server, and pass the response to the requester, preceded > >> by a comment of the form: "The following data has been obtained from > >> domain-registry.nl". > >> b) pass the referral to the requester > >> c) send the query to the server with the address of the requester > > More flexible and more complicated. What exactly is the > gain over the original, more simple proposal? The proposal was: ...it shouldn't be a problem doing all three and let it be up the the owner of the object. Then the refer attrib could be refer: [] where forward-type could be: CHAIN for a) method REFER for b) method FORWARD for c) method To me the advantage is obvious: the owner of the TLD object can change the behaviour of the RIPE-DB server just by changing the refer field... ---------- ---------- Antonio-Blasco Bonito E-Mail: A.Bonito at cnuce.cnr.it Reparto Applicazioni Telematiche c=it;a=garr;p=cnr;o=cnuce;s=A.Bonito CNUCE - Istituto del CNR Tel: +39 (50) 593246 Via S. Maria, 36 Telex: 500371 CNUCE I I-56126 PISA Italy Fax: +39 (50) 904052 ---------- ---------- From Carol.Orange at ripe.net Tue May 13 17:53:15 1997 From: Carol.Orange at ripe.net (Carol Orange) Date: Tue, 13 May 1997 17:53:15 +0200 Subject: A DNS Database Referral Mechanism In-Reply-To: Your message of "Tue, 13 May 1997 12:59:04 +0200." <199705131059.MAA05284@cuori.nis.garr.it> Message-ID: <9705131553.AA25780@ncc.ripe.net> Hi Blasco, Antonio-Blasco Bonito writes: >> would it be possible to implement the suggestion made by Robert Martin-Legen >> e ? >> It is more flexible... >> >> Date: Mon, 28 Apr 1997 17:16:09 +0200 (MET DST) >> From: Robert Martin-Legene >> >> > Forward >> > ------- >> > If the TLD object contains a whois referral, we can=20 >> >=20 >> > a) query the server, and pass the response to the requester, preceded >> > by a comment of the form: "The following data has been obtained from=20 >> > domain-registry.nl". >> > b) pass the referral to the requester >> > c) send the query to the server with the address of the requester >> >> I like the a) as well, but it shouldn't be a problem doing all three and >> let it be up the the owner of the object. Then the refer attrib could be >> >> refer: [] >> >> I guess the whois-server-type isn't needed on forward-type b, but it look= >> s >> good for consistency... (it's up to the client to use it then) >> >> -- Robert Martin-Leg=E8ne (RM59), Network Manager (AS2109) We actually discussed this point a bit in a slightly different light. An important question is: should the forward type be up to the object maintainer, to the whois server providing the referral (in this case RIPE), or the whois client, or end user. As proposed here, it is the whois server, but could be modified in the future to also be the whois client. The object maintainer can in fact always prevent automatic request forwarding by putting the referral information in a remarks field. However, if such a mechanism should become popular, then it may be suitable that whois clients be developed that can parse the refer field and resend the request to the appropriate server. If we allow the object maintainer to determine this in the field, then it actually limits flexibility in the future. Or is my thinking twisted? -- Carol From woeber at cc.univie.ac.at Wed May 14 10:07:51 1997 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Wed, 14 May 1997 10:07:51 MET-DST Subject: A DNS Database Referral Mechanism Message-ID: <009B43D7.256EF6BE.1@cc.univie.ac.at> Hi Carol, Blasco, Piet et.al.! >We actually discussed this point a bit in a slightly different light. >An important question is: should the forward type be up to the object >maintainer, to the whois server providing the referral (in this case >RIPE), or the whois client, or end user. > >As proposed here, it is the whois server, but could be modified in the >future to also be the whois client. > I think this touches on a line of discussion that we already began a while ago, but became forgotten later: What's the mechanism and who does maintain (e.g. supply, control, register) the necessary information? >The object maintainer can in fact always prevent automatic request >forwarding by putting the referral information in a remarks field. > >However, if such a mechanism should become popular, then it may be >suitable that whois clients be developed that can parse the refer >field and resend the request to the appropriate server. If we allow >the object maintainer to determine this in the field, >then it actually limits flexibility in the future. When and if we decide to eventually implement that flexibility (and we already had some private exchange on this aspect), then my first reaction would be to move that to some sort of maintainer object!? Initially, given the small set of affected objects, this can probably be sorted out infomally, but as soon as we open the flood gates... >Or is my thinking twisted? I don't think so, but mine might be :-) Wilfried. From bonito at nis.garr.it Wed May 14 13:02:59 1997 From: bonito at nis.garr.it (Antonio-Blasco Bonito) Date: Wed, 14 May 1997 13:02:59 +0200 (MET DST) Subject: A DNS Database Referral Mechanism In-Reply-To: <9705131553.AA25780@ncc.ripe.net> from "Carol Orange" at May 13, 97 05:53:15 pm Message-ID: <199705141103.NAA13354@cuori.nis.garr.it> Carol, Quoting from Carol Orange's message: > We actually discussed this point a bit in a slightly different light. > An important question is: should the forward type be up to the object > maintainer, to the whois server providing the referral (in this case > RIPE), or the whois client, or end user. This is a common problem in any distributed application (ie: DNS, X500, ...) Any of the party involved may wish a certain behaviour by other parties but the actual behaviour of the system is based on matching wishes with options chosen by implementors/administrators. The matching is usually done via a protocol. Proposing that the behavior of one of the components, the server, could be decided by the object maintainer is just a way to give a certain degree of autonomy to him. > > As proposed here, it is the whois server, but could be modified in the > future to also be the whois client. > > The object maintainer can in fact always prevent automatic request > forwarding by putting the referral information in a remarks field. Yes, if you reduce to two cases only: referral and [chaining,forwarding] However it has to be said that the referral method is more robust and can scale: the server could be a bottleneck/point of failure > > However, if such a mechanism should become popular, then it may be > suitable that whois clients be developed that can parse the refer > field and resend the request to the appropriate server. If we allow > the object maintainer to determine this in the field, > then it actually limits flexibility in the future. No, if the server getting requests from "powered clients" decide that the wishes of the client take precedence over those of the object maintainer > > Or is my thinking twisted? > > -- Carol > ---------- ---------- Antonio-Blasco Bonito E-Mail: A.Bonito at cnuce.cnr.it Reparto Applicazioni Telematiche c=it;a=garr;p=cnr;o=cnuce;s=A.Bonito CNUCE - Istituto del CNR Tel: +39 (50) 593246 Via S. Maria, 36 Telex: 500371 CNUCE I I-56126 PISA Italy Fax: +39 (50) 904052 ---------- ---------- From Daniel.Karrenberg at ripe.net Tue May 20 09:58:06 1997 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Tue, 20 May 1997 09:58:06 +0200 Subject: FYI: "." NS at LINX Operational Message-ID: <9705200758.AA02909@ncc.ripe.net> ------- Forwarded Message Date: Mon, 19 May 1997 17:27:49 -0700 From: postel at ISI.EDU Sender: owner-rootns-admin at ISI.EDU To: rootns-admin at ISI.EDU cc: postel at ISI.EDU, iana at ISI.EDU Subject: Root Nameserver Changes Hello: This change is a result of coordination and consultation between the Internet Assigned Numbers Authority (IANA) and the Internic. Please do make this change in all information files about the root servers. - --jon. Jon Postel Internet Assigned Numbers Authority c/o USC - ISI, Suite 1001 4676 Admiralty Way Marina del Rey, CA 90292-6695 Talk: +1-310-822-1511 Fax: +1-310-823-6714 EMail: IANA at ISI.EDU - ----- Begin Included Message ----- From: Mark Kosters Subject: Root Nameserver Changes To: namedroppers at internic.net Date: Mon, 19 May 1997 18:07:15 -0400 (EDT) Cc: iana at iana.org - -----BEGIN PGP SIGNED MESSAGE----- In an effort to provide more robust and geographically disparate service, one of the experimental "." servers currently at NSI has been moved to London and housed within LINX. k.root.servers will be managed by RIPE NCC. Consequently, there is an IP address change for k.root-servers.net: k.root-servers.net is now 193.0.14.129 The latest root servers list will be found at: ftp://rs.internic.net/domain/named.ca Checksum: MD5 (named.ca) 517452d39b04d1d02222d4db7292442c Regards, Mark ; This file holds the information on root name servers needed to ; initialize cache of Internet domain name servers ; (e.g. reference this file in the "cache . " ; configuration file of BIND domain name servers). ; ; This file is made available by InterNIC registration services ; under anonymous FTP as ; file /domain/named.root ; on server FTP.RS.INTERNIC.NET ; -OR- under Gopher at RS.INTERNIC.NET ; under menu InterNIC Registration Services (NSI) ; submenu InterNIC Registration Archives ; file named.root ; ; last update: May 19, 1997 ; related version of root zone: 1997051700 ; ; ; formerly NS.INTERNIC.NET ; . 3600000 IN NS A.ROOT-SERVERS.NET. A.ROOT-SERVERS.NET. 3600000 A 198.41.0.4 ; ; formerly NS1.ISI.EDU ; . 3600000 NS B.ROOT-SERVERS.NET. B.ROOT-SERVERS.NET. 3600000 A 128.9.0.107 ; ; formerly C.PSI.NET ; . 3600000 NS C.ROOT-SERVERS.NET. C.ROOT-SERVERS.NET. 3600000 A 192.33.4.12 ; ; formerly TERP.UMD.EDU ; . 3600000 NS D.ROOT-SERVERS.NET. D.ROOT-SERVERS.NET. 3600000 A 128.8.10.90 ; ; formerly NS.NASA.GOV ; . 3600000 NS E.ROOT-SERVERS.NET. E.ROOT-SERVERS.NET. 3600000 A 192.203.230.10 ; ; formerly NS.ISC.ORG ; . 3600000 NS F.ROOT-SERVERS.NET. F.ROOT-SERVERS.NET. 3600000 A 192.5.5.241 ; ; formerly NS.NIC.DDN.MIL ; . 3600000 NS G.ROOT-SERVERS.NET. G.ROOT-SERVERS.NET. 3600000 A 192.112.36.4 ; ; formerly AOS.ARL.ARMY.MIL ; . 3600000 NS H.ROOT-SERVERS.NET. H.ROOT-SERVERS.NET. 3600000 A 128.63.2.53 ; ; formerly NIC.NORDU.NET ; . 3600000 NS I.ROOT-SERVERS.NET. I.ROOT-SERVERS.NET. 3600000 A 192.36.148.17 ; ; temporarily housed at NSI (InterNIC) ; . 3600000 NS J.ROOT-SERVERS.NET. J.ROOT-SERVERS.NET. 3600000 A 198.41.0.10 ; ; housed in LINX, operated by RIPE NCC ; . 3600000 NS K.ROOT-SERVERS.NET. K.ROOT-SERVERS.NET. 3600000 A 193.0.14.129 ; ; temporarily housed at ISI (IANA) ; . 3600000 NS L.ROOT-SERVERS.NET. L.ROOT-SERVERS.NET. 3600000 A 198.32.64.12 ; ; temporarily housed at ISI (IANA) ; . 3600000 NS M.ROOT-SERVERS.NET. M.ROOT-SERVERS.NET. 3600000 A 198.32.65.12 ; End of File - -----BEGIN PGP SIGNATURE----- Version: 2.7.1 iQCVAwUBM4DDYh//vAsAupiRAQGAjQQA1LKBlEyqz3jibDq1rkjEPB5xVy0Kr6Wj PeRdX6Y9wjd/YnVIwFB3d1QizljYp0EJhMgYb6VzqyHviLC41znK8Gk/r1RD61Gl bKITaQOXXW3qWDikqxvMr+HC39oHYRZmy99oc1we+Z/LaBiLbmjiMD8PsD3mP2ac xZEVn0wQHqo= =AEmv - -----END PGP SIGNATURE----- - ----- End Included Message ----- ------- End of Forwarded Message From postel at isi.edu Wed May 28 23:44:23 1997 From: postel at isi.edu (postel at isi.edu) Date: Wed, 28 May 1997 14:44:23 -0700 Subject: IANA Statement on gTLDs ant the Root Zone Message-ID: <199705282144.AA11098@zen.isi.edu> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Hello: In light of recent developments concerning new generic top level domains (gTLDs) and frequently confusing press coverage of these developments, the IANA has been receiving inquiries about and requests for assignment of gTLDs that are not appropriately addressed to the IANA. The IANA manages the root of the Domain Name System (DNS) to promote stability and robustness. This role is primarily one of making minor technical decisions about the location of root nameservers, the qualifications of applicants to manage country code top level domains, and evaluating any additions to the established generic top level domains which are proposed by the community. Through the course of development of the Internet, IANA has historically played a central role in the management of the DNS to support and implement the community consensus about the appropriate overall structure of the system. There is now a community consensus that additional registries and additional gTLDs are needed to deal with trademark-related scarcity and conflicts, to add flexibility to the choice of domain names and to promote competition in the provision of domain name registration. The IANA initiated and supported a community process to arrive at a system for selecting and establishing these new registries and gTLDs. This process culminated in the International Ad Hoc Committee (IAHC) report and the signing of the gTLD-MoU. This system is now moving forward with the formation of the Policy Advisory Board (PAB) and the Policy Oversight Committee (POC) contemplated by the IAHC report. The IANA fully supports this activity and expects all new gTLDs to be established through this new system. That is, any changes to the root zone (or the dot domain) to add new gTLDs will be as a result of decisions made under the new POC/PAB/CORE system. --jon. Jon Postel Internet Assigned Numbers Authority c/o USC - ISI, Suite 1001 4676 Admiralty Way Marina del Rey, CA 90292-6695 Talk: +1-310-822-1511 Fax: +1-310-823-6714 EMail: IANA at ISI.EDU ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~