- dns-wg - mailman.ripe.net

Re: gTLD-MoU Web Site
by Hank Nussbacher 02 Jun '97

02 Jun '97

On Sun, 1 Jun 1997 16:38:24 -0700 you said: >At 10:34 PM -0700 6/1/97, Robert Shaw wrote: When you go to dnswalk there is in big bold letters: NOTE THAT THERE ARE PROBLEMS WITH THIS DNS WALK TEST AND A NEW VERSION WILL BE MADE AVAILABLE WHEN THE GTLD REGISTRAR APPLICATION PROCESS STARTS. What is your point to do the test on a broken dnswalk and to post those results to hundreds of people - when it clearly states it has "problems". -Hank > >I thought the best part of the site was DNS Walk: >http://www.gtld-mou.org/dnswalk.html > >dnswalk -F for www.iahc.org. > >warning: www.iahc.org. has NO authoritative nameservers! >Cannot check www.iahc.org.: no available nameservers! > >dnswalk -F for www.gtld-mou.org. > >warning: www.gtld-mou.org. has NO authoritative nameservers! >Cannot check www.gtld-mou.org.: no available nameservers! > >dnswalk -F for www.itu.int. > >warning: www.itu.int. has NO authoritative nameservers! >Cannot check www.itu.int.: no available nameservers! > >I hope the new TLDs resolve better than the existing ones do... > >;-) > >> Hi, >> >> The gTLD-MoU web site is now officially available and >> can be found at: >> >> http://www.gtld-mou.org >> >> Some important information is now available. >> >> 1. Draft application form for becoming a Registrar under >> the aegis of the gTLD-MoU. Applications cannot yet be >> made but there is a draft of the near finalized application >> form with the probably final criteria. >> >> 2. Draft of the Council of Registrars (CORE) Memorandum >> of Understanding. >> >> 3. Draft of the Council of Registars (CORE) Articles of >> Association. >> >> Queries/comments concerning these and related documents >> should be addressed to poc-submit(a)gtld-mou.org >> >> Robert > > >

1 0

IANA Statement on gTLDs ant the Root Zone
by postel＠isi.edu 28 May '97

28 May '97

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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(a)ISI.EDU ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1 0

FYI: "." NS at LINX Operational
by Daniel Karrenberg 20 May '97

20 May '97

------- Forwarded Message Date: Mon, 19 May 1997 17:27:49 -0700 From: postel(a)ISI.EDU Sender: owner-rootns-admin(a)ISI.EDU To: rootns-admin(a)ISI.EDU cc: postel(a)ISI.EDU, iana(a)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(a)ISI.EDU - ----- Begin Included Message ----- From: Mark Kosters <markk(a)internic.net> Subject: Root Nameserver Changes To: namedroppers(a)internic.net Date: Mon, 19 May 1997 18:07:15 -0400 (EDT) Cc: iana(a)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 . <file>" ; 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

1 0

A DNS Database Referral Mechanism
by Carol Orange 14 May '97

14 May '97

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(a)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: <type> <host> <port> where <type> is one of RIPE, InterNIC or SIMPLE, indicating which style of whois service is provided. <host> is the DNS name of the whois service. <port> 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.

3 6

Re: A DNS Database Referral Mechanism
by Wilfried Woeber, UniVie/ACOnet 14 May '97

14 May '97

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 <forward-type> 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.

1 0

A DNS Database Referral Mechanism
by Wilfried Woeber, UniVie/ACOnet 13 May '97

13 May '97

>Subject: A DNS Database Referral Mechanism >Date: Tue, 13 May 1997 10:44:31 +0200 >From: Carol Orange <Carol.Orange(a)ripe.net> 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(a)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 --------------------------------------------------------------------------

1 0

Inaddr Robot <auto-inaddr@ripe.net>
by Carol Orange 22 Apr '97

22 Apr '97

Dear All, First off, my apologies to all who get more than one copy of this message. I'm hoping not to miss anyone who may be effected. As many of you may know, we have long been planning to more fully automate our inaddr robot <auto-inaddr(a)ripe.net>. Well, we've gotten around to it and are happy to announce we will soon be doing almost all processing automatically, with just a touch of human intervention at the end to make certain our robot behaves as expected. The result will be a substantial reduction in rather tedius work for the NCC staff, and consistent short response times (one working day) for inaddr requests. The new robot, programmed by Mal Morris, will be installed on *** Tuesday, May 6, 1997 *** It is essential that users take the following changes into account: 1. The domain or inetnum database object must be in the RIPE database before the request is submitted to <auto-inaddr(a)ripe.net>. 2. As is required in ripe-140 (Section 3.4.2), the "status" field must be filled in properly for any inetnum associated with the request. The robot will complain and fail if either of these does not hold. We hope the new robot serves you well, Carol

1 0

FYI: APNIC and IAHC MoU
by Daniel Karrenberg 19 Apr '97

19 Apr '97

------- Forwarded Message Date: Sat, 19 Apr 1997 16:21:28 +0900 From: "David R. Conrad" <davidc(a)apnic.net> Sender: owner-apnic-talk(a)apnic.net To: apnic-talk(a)apnic.net Subject: APNIC's actions on the IAHC gTLD-MoU Hi, As you may have heard, APNIC has signed the gTLD MoU. The APNIC Executive Council was unanimous (well, almost: one EC member never responded to my request for comments, although that member's alternate did respond positively and it is quite likely that the EC member would be in favor since he was a member of the IAHC) in expressing the desire that APNIC sign the gTLD-MoU. Comments ranged from expressing strong support for the IAHC final recommendation to wanting Asia Pacific region to have input in future related developments should the IAHC recommendation be implemented. It should be noted that signing the gTLD-MoU in no way constrains the APNIC membership from either supporting or not supporting the IAHC final recommendation as they see fit, but rather insures APNIC has the option of input in future IAHC-related developments (should there be any) as a member of the Policy Advisory Board. Regards, - -drc _________________________________________________________________________ | To unsubscribe: send "unsubscribe" to apnic-talk-request(a)apnic.net | +-----------------------------------------------------------------------+ ------- End of Forwarded Message

1 0

Re: Europen Commission Meeting with National TLD Registrars
by Miguel A. Sanz. RedIRIS/CSIC 11 Apr '97

11 Apr '97

On Apr 11, 14:40, Daniel Karrenberg wrote: > Subject: Europen Commission Meeting with National TLD Registrars ... > A total of eight TLD administrators was directly represented: BE DE FI > FR IE IT LU UK. I counted nine: also ES ;-) Miguel

2 1

Europen Commission Meeting with National TLD Registrars
by Daniel Karrenberg 11 Apr '97

11 Apr '97

Europen Commission Meeting with National TLD Registrars Brussels, April 9th 1997 Chair: Christopher Wilkinson, DG 13 As announced on the DNS WG list I attended this meeting on behalf of RIPE at the request of Rob who had prior commitments. The following is a subjective and selective summary of the meeting focussing on issues relevant for RIPE and the TLD administrators. It has not een checked with any of those represented and any misrepresentations are my responsibility. Purpose of the meeting as stated by the commision was to collect information about European DNS administration structures and to gather input from TLD registrars about recent developments as well as the commission's reactions to them. A numer of relevant documetns were circulated, most notably an issue paper used to raise this issue with the council of ministers (telecomms cttee) and a letter from the commission to the government of the United States. I try to make these available as soon as practical. The commission's stated interest is to follow DNS issues as they are becoming more political with the increasing importance of the Internet and to instigate the member countries to do the same. The commission is also taking steps on the intergovernmental level to raise the issue of European representation in the relevant processes. The commission states that they presently have no intention to directly interfere with the administration of the DNS in Europe nor to advise the governments of member states to do so. A total of eight TLD administrators was directly represented: BE DE FI FR IE IT LU UK. CH and NL were represented by informal proxy via RIPE. The European telecommunications operators association (ETNA ?) were also present. The commission participated with representatives from DG1, DG3, DG12, DG13 and DG15. (Eurocrats please forgive me the arabic numbers ;-). Currently the DNS is subject to deliberations of the commission, the EU council of ministerrs as well as many international treaty organisations such as ITU, WIPO and OECD. The TLD registrars were unanimous in the opinion that the DNS in Europe is functioning well. National TLDs work, they are accessible, fairly administered and registration is doen on a not-for-profit basis. Conflict resoloution also works on the national level. There was also agreement that the process to decide on the creation of additional gTLDs via the IAHC is flawed for several reasons including but not limited to the excessive speed with which it was conducted and the general preoccupation to solve unstated North American prolems. The process and its results would greatly benefit from more careful consultation with European stakeholders which would result in the necessary level of acceptance of the conclusions. There were some concerns that the structures produced by the flawed process would eventually become effective also for the administration of national TLDs. None of the represented organisation had the intention to sign the MoU resulting from the IAHC process neither were they considering to become a registrar for one of the new gTLDs. All TLD registrars present also stated explicitly that currently RIPE is considered an appropriate forum for a process of forming and formulating common positions of the TLD administrators as well as general coordination. Privately some of them expressed concern about the lack of concrete activity in this area. Christopher Wilkonson suggested that a small group be formed from those present and charged to develop a common positions in an open and transparent process. Due to lack of time no conclusion was reached about this. Further e-mail discussion on this topic was agreed on a list t.b.a.. If progress warrants it a meeting concurrent with the Dublin RIPE meeting is being considered. Wilkinson also asked for all those who have indeed made comments to IAHC to provide him with copies to be used in the commissions discussions with the US government. Wilkinson also expressed that the commission was interested to talk to the European ISPs on these issues and requested input on suitable organisations to approach. The conclusion was that while a number of national organisations exist representing ISPs, there currently is no such animal on a European level. I reported that RIPE had considered this issue and so far consciously decided not to move towards becoming a representative or lobbying body for the European ISP industry. Further short items of interest: Some of those present felt more stakeholders than just the classic ISPs should be encouraged to take an active part in TLD administration. Mentioned were consumers groups, web hosting organisations and specialised name registration companies. The latter were observed to generate an increasingly significant part of registration requests f.i. in the UK. Appropriate legal structures for national TLD administration seem to be a recurring problem and much energy is spent on finding cq. defining them. A DG13 representative felt that it was necessary and inevitable to convert the monopolistic registration structures in national TLDs into oligopolies with market forces having free play. Some of those present questioned the generalised and immediate necessity for this given the existance of accepted and fair mechanisms that currently work. Others questioned whether such structures would actually work given that there is little space for different registration services to distinguish themselves from others and consequently a danger of only a single one or a very small number surviving after a very short time. A DG15 representative noted that WIPO has a one week meeting scheduled at the end of May to collect opinions form governments and NGOs about their proposals to start registrations in TM.INT as well the use of their arbitration service to resolve DNS disputes. RIPE has received an invitation to that meeting but currently does not intend to go to an informal meeting lasting for a whole week. DE-NIC is in the final stages to reorganise themselves as a cooperative wich is much more open to participation than the current structure. NOMINET (UK TLD admin) have had good experiences when releasing restrictions on the number and kind of names that can be registrered as much as possible. While the number of registrations has increased to 4000+/month customers are much happier and tend to consider registering in gTLDs muc less frequently. The FI TLD administration is slated to move from EUnet FI to the Finnish Telecom Administration (a governmental body) in May/June. It was not clear to me by which process this was decided nor if there is consensus about this in FI. A DG13 representative reported that OECD (telecomms cttee ???) was currently considering a statement about DNS administration. Apparently they have a draft document which includes quite some detail about the current state of affairs. Unfortunately the document is not publicly available at this time and even somewhat shrouded in secrecy. Also the relevance of OECD in this context remained unclear to me. Does anyone know more? Conclusion For RIPE an important conclusion of this is that we are being looked at as a forum to form common opinions among the ISPs and TLD admins. Other European bodies are very much prepared to listen to the results. There is some concern that RIPE has not clearly stepped up this task. RIPE has to decide quickly whether it wants to take action in this area and which steps if any it will take. If we decide not to get involved we should also state so quickly in order to avoid blocking progress and being damaged by not fulfilling expectations. That's all folks. I'll be happy to answer any questions you may have. Daniel

1 0