[From nobody Fri Dec 6 16:56:13 2019 X-Account-Key: account1 Return-Path: <fm-bounces+kim=centr.org@lists.centr.org> Delivered-To: kim@centr.org Received: from s15114026.rootmaster.info (localhost.localdomain [127.0.0.1]) by kaiser.centr.org (Postfix) with ESMTP id 43C903FA128 for <kim@centr.org>; Mon, 6 Jun 2005 12:53:34 +0000 (UTC) Delivered-To: fm@centr.org Received: from mx2.nic.fr (mx2.nic.fr [192.134.4.11]) by kaiser.centr.org (Postfix) with ESMTP id 1AF883FA0FA for <fm@centr.org>; Mon, 6 Jun 2005 12:53:25 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id CBC0126C08E; Mon, 6 Jun 2005 14:53:24 +0200 (CEST) Received: from maya40.nic.fr (maya40.nic.fr [192.134.4.151]) by mx2.nic.fr (Postfix) with ESMTP id 3460226C078; Mon, 6 Jun 2005 14:53:22 +0200 (CEST) Received: from james.nic.fr (james.nic.fr [192.134.4.83]) by maya40.nic.fr (8.12.4/8.12.4) with ESMTP id j56CrLkZ873751; Mon, 6 Jun 2005 14:53:22 +0200 (CEST) Received: from james.nic.fr (paris.nic.fr [127.0.0.1]) by james.nic.fr (Postfix) with ESMTP id D8309129128; Mon, 6 Jun 2005 14:53:21 +0200 (CEST) Received: (from guillard@localhost) by james.nic.fr (8.12.10/8.12.10/Submit) id j56CrLSg014077; Mon, 6 Jun 2005 14:53:21 +0200 X-Authentication-Warning: james.nic.fr: guillard set sender to Olivier.Guillard@nic.fr using -f Date: Mon, 6 Jun 2005 14:53:21 +0200 From: Olivier Guillard / AFNIC <Olivier.Guillard@nic.fr> To: Marcel Schneider <schneide@switch.ch> Message-ID: <20050606125321.GA13403@james.nic.fr> References: <17741.1115992721@switch.ch> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="+HP7ph2BbKc20aGI" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <17741.1115992721@switch.ch> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new at mx2.nic.fr Cc: fm@centr.org Subject: [centr-fm] Re: [centr-ga] FWD: IANA TLD delegation issue X-BeenThere: fm@lists.centr.org X-Mailman-Version: 2.1.2 Precedence: list Sender: fm-bounces+kim=centr.org@lists.centr.org Errors-To: fm-bounces+kim=centr.org@lists.centr.org --+HP7ph2BbKc20aGI Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit Marcel and colleagues, as the AFNIC multinamming story with IANA was quoted within exchanges, we felt necessary to provide the community with a report to clarify what happened. Find it here included. As there is no standard format to communicate over the TLD community this kind of reports, I have choosen the RFC one. It is not designed for this kind of communications, but I felt that it was the less unappropriate to use (-> it does exist and it is known by ccTLDs). This is a raw draft: I would higly appreciate *ANY* suggestions and inputs. This issue will be discussed over the next CENTR GA in Trondheim: http://www.centr.org/docs/2005/05/centr-ga26-agenda.pdf Best regards, le vendredi 13 mai à 15 H 58 , Marcel Schneider a ecrit : > Since this is a real technical concern to us all. Propose > we ask IANA to clarify. > > > Marcel > > > ------- Forwarded Message > > Date: Fri, 13 May 2005 14:50:00 +0100 > From: Jim Reid <jim@rfc1035.com> > To: dns-wg@ripe.net > Subject: [dns-wg] IANA TLD delegation issue > > Here is a copy of the mail that has just been sent to IANA in followup > to the discussion during last week's RIPE meeting. My thanks to those > who have helped draft this message so promptly. I will keep the WG > informed of developments. > > Dear Colleagues, > > This note follows a discussion at the DNS Working Group during last > week's RIPE meeting. Doug was unable to take part in this discussion > because he was called away early. Therefore we have sent you this > message so that we can clear up any possible misunderstandings and > hopefully avoid invoking more formal mechanisms. > > The RIPE DNS Working Group is concerned about some aspects of the > current practice regarding IANA TLD operations. In particular the > problems encountered by AFNIC last month are unsettling. > > It is our understanding that IANA has recently stopped accepting > certain updates to the DNS root zone. The current practice now appears > to require each particular network address used in glue address RRs to > have one unique DNS name. This requirement is new: multiple names > already exist in the root zone for some name server addresses. There > is no technical reason in the DNS protocols preventing this practice. > > Important technical and operational goals can require TLD operators to > use different names for the same address. The most obvious of these is > more efficient name compression to make room for additional data in > responses. Multiple names for the same address can reduce the amount > of co-ordination required in case of name server address changes. > > We do not understand why this requirement has been introduced or the > process by which it was agreed. The RIPE DNS Working Group is > disappointed that this change appears to have been carried out by IANA > without prior consultation or discussion. We would like to know > rationale for this policy and the mechanism which led to its > introduction. We'd appreciate any clarifications from you before Friday, > May 20th. > > Regards > > ..... > chairs RIPE DNS WG > > > ------- End of Forwarded Message -- Olivier --+HP7ph2BbKc20aGI Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="draft-guillard-multi-naming.txt" IANA operations O. Guillard Internet-Draft AFNIC Expires: November 19, 2005 may 18, 2005 IANA Multi-naming policy issue Status of this Memo This document is an Internet-Draft and is NOT offered in accordance with Section 10 of RFC 2026, and the author does not provide the IETF with any rights other than to publish as an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on November 19, 2005. Abstract IANA provides with the interface to maintain global TLD information. Therefore IANA policies have a direct impact on certain TLD operations and management. This document reports a particular experience of operational exchange between AFNIC and IANA. This should be seen as a simple "case study" illustrating the wider issue of interactions between IANA and TLD registries. Guillard Expires November 19, 2005 [Page 1] Internet-Draft IANA Multi-naming policy issue may 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. .re DNS management and context . . . . . . . . . . . . . . . . 4 3. AFNIC naming plan strategy and context . . . . . . . . . . . . 5 3.1 Homogeneity . . . . . . . . . . . . . . . . . . . . . . . 5 3.2 Geographical distribution . . . . . . . . . . . . . . . . 5 3.3 DNS compression . . . . . . . . . . . . . . . . . . . . . 5 3.4 .re IANA rejection history . . . . . . . . . . . . . . . . 7 4. Rationale (situation the 18th of may 2005) . . . . . . . . . . 8 5. TLD management considerations . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 11 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 12 A. UPDATE SECTION (what's next after the 18th of may 2005)? . . . 13 Guillard Expires November 19, 2005 [Page 2] Internet-Draft IANA Multi-naming policy issue may 2005 1. Introduction Top Level Domain DNS configuration submited to IANA for global publication in the root zone file are critical. These meet particular strategies, they respond to particular requirements or constraints. Therefore, the data published in the root zone file should square with the considered naming plans designed by managing TLD registries. Many goals may shape TLD registries naming plans such as : 1. homogeneity of DNS naming to streamline DNS management; 2. good geographical distribution of DNS servers (this may require to outsource secondary servers); 3. consensual or best practises recognized within the DNS community that may lead sometimes TLD managers to reconsider specific aspects of their naming plans (as of the time of writing this document, the most obvious one is name compression to make room for additional data in responses, see below). To implement their registry naming plan, TLD managers use the IANA channel. Therefore IANA policies and organisation may have a direct impact on certain TLD operations. This document, by reporting a TLD management issue to update .re DNS configuration, would like to echo this reminder attributed to Jon Postel RFC2468 [1]: "there is still much work to be done and ... we now have the responsibility and the opportunity to do our part". Guillard Expires November 19, 2005 [Page 3] Internet-Draft IANA Multi-naming policy issue may 2005 2. .re DNS management and context .re is the ISO3166 code coming for "Reunion Island". It has been managed by NIC-FRANCE (which became AFNIC) since April 1997 (see : .re IANA entry, http://www.iana.org/root-whois/re.htm and .re registry web page, http://www.nic.re). At that time, .re was not opened to registration and only a web site (http://www.nic.re) was set up to provide the community with .re status. .re zone was then hosted by two domain name servers: ns1.nic.fr (192.93.0.1) and ns2.nic.fr (192.93.0.4). These servers were configured by AFNIC as authoritative for .re in October 1996, and were announced in the root zone after IANA process in April 1997. .re was opened to registration in June 2001 after agreement with the local Internet community of the Reunion Island. To respond more efficiently to the DNS query growth, AFNIC asked IANA in may 2001 to announce ns3.nic.fr (192.134.0.49), as a new server for .re, which was done. This server is physically located on the SFINX and PARIX exchange points in Paris. For quite comparable reasons, we asked IANA in June 2002 to announce another DNS server for .re, ns3.domain-registry.nl (193.176.144.6), hosted in Amsterdam (NL). As a result of a partnership project between AFNIC and local stakeholders, a new AFNIC TLD name server was set up in late 2004: namely e.nic.fr (194.57.253.1). This server is operated locally in the Reunion Island with the objective to better answer to local queries. We asked IANA to announce this new server in April 2005: this request was rejected. Guillard Expires November 19, 2005 [Page 4] Internet-Draft IANA Multi-naming policy issue may 2005 3. AFNIC naming plan strategy and context 3.1 Homogeneity Usage of homogeneous rules to refer NS servers appears to be a widely recognised good practise to simplify and secure NS operations by increasing readability. From the very beginning, AFNIC used the following widely spread specification to designate its NS servers: ns[1-9].nic.fr As we outsource some of our secondaries, we initially used to announce the names indicated by our secondary providers "as is" in the root zone (like dns.inria.fr or ns-ext.vix.com) 3.2 Geographical distribution Because of the global nature of the Internet, a good DNS accessibility anywhere in the world is a crucial issue for TLD registries. Moreover, ccTLD registries pay a particular attention to provide their local Internet community with an appropriate NS time response. To ensure a network coverage that meets with this requirement, a good geographical domain name server distribution is a matter of first importance. To improve the .re reachability, a new name server has been set up in late 2004 locally in the Reunion Island after completion of a partnership between AFNIC and local stakeholders. 3.3 DNS compression The design of the DNS protocol limits the size of UDP DNS messages to 512 octets RFC1035 [5]. Although this issue has been raised long time ago RFC2671 [3], the practical deployment of a appropriate solutions will take time. This appeared more critical to the DNS community in 2003 when plans to deploy DNSv6 were foreseen. This issue was raised again, widely discussed at that time and quite well documented KATO VIXIE [7], NLNETLAB [8], AFNIC [9]. DNS naming compression quickly appeared as a widely recognized new best-practise to mitigate this DNS limitation. To implement such a "de facto" recommendation, AFNIC decided to move to a new naming designation for its Name Servers, adopting the Guillard Expires November 19, 2005 [Page 5] Internet-Draft IANA Multi-naming policy issue may 2005 following specification: [a-z].nic.fr for servers directly maintained by AFNIC [a-z].ext.nic.fr for those outsourced As there were no technical nor operational reasons to change our physical hosts at that time, we decided to add new names for our existing DNS servers, and keep the same IP addresses. New names were planned to be used as official global references announced in the root zone, the other names were kept for internal management reasons and transition purposes. In October 2004, we asked then IANA this new designation for .fr to be announced, which was done, shifting .fr from: ns1.nic.fr. ns2.nic.fr. ns3.nic.fr. dns.inria.fr. dns.cs.wisc.edu. dns.princetown.edu. ns-ext.vix.com. ns3.domain-registry.nl. To respectively: a.nic.fr. b.nic.fr. c.nic.fr. a.ext.nic.fr. b.ext.nic.fr. c.ext.nic.fr. d.ext.nic.fr. Guillard Expires November 19, 2005 [Page 6] Internet-Draft IANA Multi-naming policy issue may 2005 e.ext.nic.fr. The root zone includes IP address(es) as additional information for each NS servicing a TLD. Therefore, both references for each Name Server were announced by the root servers, as the new names became autoritave for .fr and old ones stayed authoritave for other TLDs that we operate (AFNIC currently manages 6 TLDs and provides with a secondary services for 18 others). Also, servers like ns3.domain- registry.nl or ns-axt.vix.com were providing with secondary services for many other TLD than .fr; therefore, these names also stayed referenced in the root zone. 3.4 .re IANA rejection history In April 2005, AFNIC sent a form to IANA to update .re. The request pursued two main objectives: 1. first, to ask IANA to announce the server located on the Reunion Island; 2. second, to implement homogeneisation and compression; The plan was then to shifted from: ns1.nic.fr. ns2.nic.fr. ns3.nic.fr. ns3.domain-registry.nl. To: a.nic.fr. b.nic.fr. c.nic.fr. e.nic.fr. e.ext.nic.fr. This request was rejected, the following statement was sent to us by mail: "IANA is no longer adding additional examples of host names in delegation records where multiple host names point to the same IP address". Guillard Expires November 19, 2005 [Page 7] Internet-Draft IANA Multi-naming policy issue may 2005 4. Rationale (situation the 18th of may 2005) Inconsistencies between the root zone implementation and IANA policy for .re were : a.nic.fr and ns1.nic.fr have the same IPv4 address: 192.93.0.1 b.nic.fr and ns2.nic.fr have the same IPv4 address: 192.93.0.4 c.nic.fr and ns3.nic.fr have the same IPv4 address: 192.134.0.49 a.ext.nic.fr and dns.inria.fr have the same IPv4 address: 193.51.208.13 c.ext.nic.fr and dns.princeton.edu have the same IPv4 address: 128.112.129.15 e.ext.nic.fr and ns3.domain-registry.nl have the same IPv4 address:193.176.144.6 After having studied this issue, to move forward in implementing AFNIC naming plan, the easiest solution that appeared to us was to add a new IP address for each NS among [a-z].nic.fr and [a-z].ext.nic.fr. Although this was a sensitive extra-work that might have been avoided, it stayed feasible for [a-c].nic.fr which were those servers that we were operating directly. Thing were different for [a-z].ext.nic.fr, as we needed to contact our name server secondary providers to : 1. inform them about a new and non documented IANA policy {done}; 2. show them the incidence of this policy on the TLDs they host {done}; 3. ask them to dedicate a new IP address for .fr (they might not be able to do that) {done}; 4. coordinate with them and with IANA to reach a reasonable and safe deployment {in progress}; Guillard Expires November 19, 2005 [Page 8] Internet-Draft IANA Multi-naming policy issue may 2005 5. TLD management considerations From a management and operation point of view, this unilateral IANA policy change trigger critical matters : 1. transparency: what was the nature of the problem? 2. communication: why the DNS community was not informed about it? 3. documentation: where is the reference repository keeping track about up to date IANA policies? 4. speaker: who these kind of issues could be referred to when they raise? Guillard Expires November 19, 2005 [Page 9] Internet-Draft IANA Multi-naming policy issue may 2005 6. Security Considerations This document does not define a protocol. No technical security consideration are really discussed here. However, operational risks and security matters are described under sections 3.1 (Section 3.1), 3.2 (Section 3.2) and 3.3 (Section 3.3). The security risks are also raising with operations described section 4 (Section 3.3). Another related issue: information that creates or updates a global TLD information needs to be authenticated CRISPIN [10]. Guillard Expires November 19, 2005 [Page 10] Internet-Draft IANA Multi-naming policy issue may 2005 7. IANA considerations The Internet Corporation for Assigned Names and Numbers (ICANN) has responsibility for country code (ccTLD) Top-Level Domain name system management, and root server system management functions. These services were originally performed under U.S. Government contract by the Internet Assigned Numbers Authority (IANA) and other entities. ICANN now performs the IANA function (ICANN information: http://www.icann.org/general/). IANA is the Internet Assigned Number Authority. It is dedicated to "preserving the central coordinating functions of the global Internet for the public good" http://www.iana.org. DNS services provided by IANA and related documentation can be found on the dedicated IANA web page. In the Domain Name System, IANA only deals with assignments at the higher-levels, while sub domains are administered by independent managing registries. In order for the IANA to manage the DNS space prudently, it needs guidelines describing the conditions under which new policies should be implemented. 8. References [1] Cerf., V., "I REMEMBER IANA", RFC 2468, October 1998. [2] Eastlake, D., Brunner-Williams, E., and B. Manning, "Domain Name System (DNS) IANA Considerations.", RFC 2929, September 2000. [3] Vixie., Vixie., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, August 1999. [4] Mockapetris, P., "Domain Names - Concepts and Facilities", RFC 1034, November 1987. [5] Mockapetris, P., "Domain Names - Implementation and Specifications", RFC 1035, November 1987. [6] Postel, J., "Domain Name System Structure and Delegation", RFC 1591, March 1994. [7] Kato, A. and P. Vixie, "DNS Response Size Issues", Internet Draft 01, July 2004, <http://www.ietf.org/proceedings/04aug/ I-D/draft-ietf-dnsop-respsize-01.txt>. Guillard Expires November 19, 2005 [Page 11] Internet-Draft IANA Multi-naming policy issue may 2005 [8] van der Pol, R. and D. Karrenberg, "Adding IPv6 glue to the root zone", Draft 00, October 2003, <http://www.nlnetlabs.nl/ipv6/publications/v6rootglue.pdf>. [9] Souissi, M., "DNS Response Size and Name Compression", AFNIC D1.52, September 2004, <http://w6.nic.fr/dnsv6/resp-size.html>. [10] Crispin, K., "The IANA Workflow System", CENTR Presentation ga19-05, September 2003, <http://www.centr.org/docs/2003/09/ centr-ga19-crispin-iana.pdf>. [11] "IANA Administrative Procedure for Root Zone Name Server Delegation and Glue Data", doc 00, July 2004, <http://www.iana.org/procedures/delegation-data.html>. [12] Crocker, S., "DNS Infrastructure Recommendation Of the Security and Stability Advisory Committee", SAC 005, November 2003, <htt p://www.icann.org/committees/security/ dns-recommendation-01nov03.htm>. Author's Address Olivier Guillard AFNIC Immeuble International 78181 Saint Quentin en Yvelines cedex France Phone: +33 1 39 30 83 00 Fax: +33 1 39 30 83 01 Email: Olivier.Guillard@afnic.fr URI: http://www.afnic.fr Guillard Expires November 19, 2005 [Page 12] Internet-Draft IANA Multi-naming policy issue may 2005 Appendix A. UPDATE SECTION (what's next after the 18th of may 2005)? The previous sections were written the 18th of May. At the time this document is posted to related DNS fora, the situation has evolved and might change again over the next few weeks or months. As a new important update, IANA clarified to the RIPE DNS forum that "adding new host names for IP addresses of name servers that already existed in the root zone produced an unexpected result" but that "this issue was now permanently fixed". AFNIC also received a mail from IANA inviting us to "submit a new template at [our] convenience describing all of the changes [we] would like to make" since "the problem with multiple names with the same IP address has been resolved". These new information lead us to contact our secondary providers again, to explain them that the IANA policy has changed yet another time and that the dedicated IPv4 address for .fr that we were asking for is not a IANA requirement anymore. The IANA multi-naming is an ongoing issue that has already generated some exchanges. From a technical point of view, it appears quite clearly that "multiple names for a single IP is a valid and widely accepted DNS configuration". However, the TLD management and operational matters triggered by this IANA policy change are still discussed : 1. transparency : what is the nature of an issue when it raises? 2. communication : how the DNS community is informed about it? 3. documentation : where is the reference repository keeping track about all up to date IANA policies? 4. and still valid : who to talk to when this kind of operational DNS management is raising? Guillard Expires November 19, 2005 [Page 13] --+HP7ph2BbKc20aGI Content-Type: text/html; charset=us-ascii Content-Disposition: attachment; filename="draft-guillard-multi-naming.html" <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> <html lang="en"><head><title>IANA Multi-naming policy issue</title> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> <meta name="description" content="IANA Multi-naming policy issue"> <meta name="generator" content="xml2rfc v1.29 (http://xml.resource.org/)"> <style type='text/css'> <!-- body { font-family: verdana, charcoal, helvetica, arial, sans-serif; margin: 2em; font-size: small ; color: #000000 ; background-color: #ffffff ; } .title { color: #990000; font-size: x-large ; font-weight: bold; text-align: right; font-family: helvetica, monaco, "MS Sans Serif", arial, sans-serif; background-color: transparent; } .filename { color: #666666; font-size: 18px; line-height: 28px; font-weight: bold; text-align: right; font-family: helvetica, arial, sans-serif; background-color: transparent; } td.rfcbug { background-color: #000000 ; width: 30px ; height: 30px ; text-align: justify; vertical-align: middle ; padding-top: 2px ; } td.rfcbug span.RFC { color: #666666; font-weight: bold; text-decoration: none; background-color: #000000 ; font-family: monaco, charcoal, geneva, "MS Sans Serif", helvetica, verdana, sans-serif; font-size: x-small ; } td.rfcbug span.hotText { color: #ffffff; font-weight: normal; text-decoration: none; text-align: center ; font-family: charcoal, monaco, geneva, "MS Sans Serif", helvetica, verdana, sans-serif; font-size: x-small ; background-color: #000000; } /* info code from SantaKlauss at http://www.madaboutstyle.com/tooltip2.html */ div#counter{margin-top: 100px} a.info{ position:relative; /*this is the key*/ z-index:24; text-decoration:none} a.info:hover{z-index:25; background-color:#990000 ; color: #ffffff ;} a.info span{display: none} a.info:hover span.info{ /*the span will display just on :hover state*/ display:block; position:absolute; font-size: smaller ; top:2em; left:2em; width:15em; padding: 2px ; border:1px solid #333333; background-color:#eeeeee; color:#990000; text-align: left ;} A { font-weight: bold; } A:link { color: #990000; background-color: transparent ; } A:visited { color: #333333; background-color: transparent ; } A:active { color: #333333; background-color: transparent ; } p { margin-left: 2em; margin-right: 2em; } p.copyright { font-size: x-small ; } p.toc { font-size: small ; font-weight: bold ; margin-left: 3em ;} span.emph { font-style: italic; } span.strong { font-weight: bold; } span.verb, span.vbare { font-family: "Courier New", Courier, monospace ; } span.vemph { font-style: italic; font-family: "Courier New", Courier, monospace ; } span.vstrong { font-weight: bold; font-family: "Courier New", Courier, monospace ; } span.vdeluxe { font-weight: bold; font-style: italic; font-family: "Courier New", Courier, monospace ; } ol.text { margin-left: 2em; margin-right: 2em; } ul.text { margin-left: 2em; margin-right: 2em; } li { margin-left: 3em; } pre { margin-left: 3em; color: #333333; background-color: transparent; font-family: "Courier New", Courier, monospace ; font-size: small ; text-align: left; } h3 { color: #333333; font-size: medium ; font-family: helvetica, arial, sans-serif ; background-color: transparent; } h4 { font-size: small; font-family: helvetica, arial, sans-serif ; } table.bug { width: 30px ; height: 15px ; } td.bug { color: #ffffff ; background-color: #990000 ; text-align: center ; width: 30px ; height: 15px ; } td.bug A.link2 { color: #ffffff ; font-weight: bold; text-decoration: none; font-family: monaco, charcoal, geneva, "MS Sans Serif", helvetica, sans-serif; font-size: x-small ; background-color: transparent } td.header { color: #ffffff; font-size: x-small ; font-family: arial, helvetica, sans-serif; vertical-align: top; background-color: #666666 ; width: 33% ; } td.author { font-weight: bold; margin-left: 4em; font-size: x-small ; } td.author-text { font-size: x-small; } table.data { vertical-align: top ; border-collapse: collapse ; border-style: solid solid solid solid ; border-color: black black black black ; font-size: small ; text-align: center ; } table.data th { font-weight: bold ; border-style: solid solid solid solid ; border-color: black black black black ; } table.data td { border-style: solid solid solid solid ; border-color: #333333 #333333 #333333 #333333 ; } hr { height: 1px } --> </style> </head> <body> <table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table> <table summary="layout" width="66%" border="0" cellpadding="0" cellspacing="0"><tr><td><table summary="layout" width="100%" border="0" cellpadding="2" cellspacing="1"> <tr><td class="header">IANA operations</td><td class="header">O. Guillard</td></tr> <tr><td class="header">Internet-Draft</td><td class="header">AFNIC</td></tr> <tr><td class="header">Expires: November 19, 2005</td><td class="header">may 18, 2005</td></tr> </table></td></tr></table> <div align="right"><span class="title"><br />IANA Multi-naming policy issue</span></div> <h3>Status of this Memo</h3> <p> This document is an Internet-Draft and is NOT offered in accordance with Section 10 of RFC 2026, and the author does not provide the IETF with any rights other than to publish as an Internet-Draft.</p> <p> Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.</p> <p> Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”</p> <p> The list of current Internet-Drafts can be accessed at <a href='http://www.ietf.org/ietf/1id-abstracts.txt'>http://www.ietf.org/ietf/1id-abstracts.txt</a>.</p> <p> The list of Internet-Draft Shadow Directories can be accessed at <a href='http://www.ietf.org/shadow.html'>http://www.ietf.org/shadow.html</a>.</p> <p> This Internet-Draft will expire on November 19, 2005.</p> <h3>Abstract</h3> <p> IANA provides with the interface to maintain global TLD information. Therefore IANA policies have a direct impact on certain TLD operations and management. This document reports a particular experience of operational exchange between AFNIC and IANA. This should be seen as a simple "case study" illustrating the wider issue of interactions between IANA and TLD registries. </p><a name="toc"></a><br /><hr /> <h3>Table of Contents</h3> <p class="toc"> <a href="#anchor1">1.</a>  Introduction<br /> <a href="#anchor2">2.</a>  .re DNS management and context<br /> <a href="#anchor3">3.</a>  AFNIC naming plan strategy and context<br />     <a href="#homogeneity">3.1</a>  Homogeneity<br />     <a href="#distribution">3.2</a>  Geographical distribution<br />     <a href="#compression">3.3</a>  DNS compression<br />     <a href="#anchor4">3.4</a>  .re IANA rejection history<br /> <a href="#anchor5">4.</a>  Rationale (situation the 18th of may 2005)<br /> <a href="#anchor6">5.</a>  TLD management considerations<br /> <a href="#anchor7">6.</a>  Security Considerations<br /> <a href="#anchor8">7.</a>  IANA considerations<br /> <a href="#rfc.references1">8.</a>  References<br /> <a href="#rfc.authors">§</a>  Author's Address<br /> <a href="#anchor10">A.</a>  UPDATE SECTION (what's next after the 18th of may 2005)?<br /> </p> <br clear="all" /> <a name="anchor1"></a><br /><hr /> <table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table> <a name="rfc.section.1"></a><h3>1. Introduction</h3> <p> Top Level Domain DNS configuration submited to IANA for global publication in the root zone file are critical. These meet particular strategies, they respond to particular requirements or constraints. Therefore, the data published in the root zone file should square with the considered naming plans designed by managing TLD registries. </p> <p> Many goals may shape TLD registries naming plans such as : </p> <ol class="text"> <li>homogeneity of DNS naming to streamline DNS management; </li> <li>good geographical distribution of DNS servers (this may require to outsource secondary servers); </li> <li> consensual or best practises recognized within the DNS community that may lead sometimes TLD managers to reconsider specific aspects of their naming plans (as of the time of writing this document, the most obvious one is name compression to make room for additional data in responses, see below). </li> </ol><p> </p> <p> To implement their registry naming plan, TLD managers use the IANA channel. Therefore IANA policies and organisation may have a direct impact on certain TLD operations. </p> <p> This document, by reporting a TLD management issue to update .re DNS configuration, would like to echo this reminder attributed to Jon Postel <a class="info" href="#refs.RFC2468">RFC2468<span> (</span><span class="info">Cerf., V., “I REMEMBER IANA,” October 1998.</span><span>)</span></a>[1]: "there is still much work to be done and ... we now have the responsibility and the opportunity to do our part". </p> <a name="anchor2"></a><br /><hr /> <table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table> <a name="rfc.section.2"></a><h3>2. .re DNS management and context</h3> <p> .re is the ISO3166 code coming for "Reunion Island". It has been managed by NIC-FRANCE (which became AFNIC) since April 1997 (see : .re IANA entry, <a href="http://www.iana.org/root-whois/re.htm">http://www.iana.org/root-whois/re.htm</a> and .re registry web page, <a href="http://www.nic.re">http://www.nic.re</a>). </p> <p> At that time, .re was not opened to registration and only a web site (http://www.nic.re) was set up to provide the community with .re status. .re zone was then hosted by two domain name servers: ns1.nic.fr (192.93.0.1) and ns2.nic.fr (192.93.0.4). </p> <p> These servers were configured by AFNIC as authoritative for .re in October 1996, and were announced in the root zone after IANA process in April 1997. </p> <p> .re was opened to registration in June 2001 after agreement with the local Internet community of the Reunion Island. </p> <p> To respond more efficiently to the DNS query growth, AFNIC asked IANA in may 2001 to announce ns3.nic.fr (192.134.0.49), as a new server for .re, which was done. This server is physically located on the SFINX and PARIX exchange points in Paris. </p> <p> For quite comparable reasons, we asked IANA in June 2002 to announce another DNS server for .re, ns3.domain-registry.nl (193.176.144.6), hosted in Amsterdam (NL). </p> <p> As a result of a partnership project between AFNIC and local stakeholders, a new AFNIC TLD name server was set up in late 2004: namely e.nic.fr (194.57.253.1). This server is operated locally in the Reunion Island with the objective to better answer to local queries. </p> <p> We asked IANA to announce this new server in April 2005: this request was rejected. </p> <a name="anchor3"></a><br /><hr /> <table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table> <a name="rfc.section.3"></a><h3>3. AFNIC naming plan strategy and context</h3> <a name="rfc.section.3.1"></a><h4><a name="homogeneity">3.1</a> Homogeneity</h4> <p> Usage of homogeneous rules to refer NS servers appears to be a widely recognised good practise to simplify and secure NS operations by increasing readability. </p> <p> >From the very beginning, AFNIC used the following widely spread specification to designate its NS servers: </p> <blockquote class="text"> <p>ns[1-9].nic.fr </p> </blockquote><p> As we outsource some of our secondaries, we initially used to announce the names indicated by our secondary providers "as is" in the root zone (like dns.inria.fr or ns-ext.vix.com) </p> <a name="rfc.section.3.2"></a><h4><a name="distribution">3.2</a> Geographical distribution</h4> <p> Because of the global nature of the Internet, a good DNS accessibility anywhere in the world is a crucial issue for TLD registries. Moreover, ccTLD registries pay a particular attention to provide their local Internet community with an appropriate NS time response. </p> <p> To ensure a network coverage that meets with this requirement, a good geographical domain name server distribution is a matter of first importance. </p> <p> To improve the .re reachability, a new name server has been set up in late 2004 locally in the Reunion Island after completion of a partnership between AFNIC and local stakeholders. </p> <a name="rfc.section.3.3"></a><h4><a name="compression">3.3</a> DNS compression</h4> <p> The design of the DNS protocol limits the size of UDP DNS messages to 512 octets <a class="info" href="#refs.RFC1035">RFC1035<span> (</span><span class="info">Mockapetris, P., “Domain Names - Implementation and Specifications,” November 1987.</span><span>)</span></a>[5]. Although this issue has been raised long time ago <a class="info" href="#refs.RFC2671">RFC2671<span> (</span><span class="info">Vixie., Vixie., “Extension Mechanisms for DNS (EDNS0),” August 1999.</span><span>)</span></a>[3], the practical deployment of a appropriate solutions will take time. This appeared more critical to the DNS community in 2003 when plans to deploy DNSv6 were foreseen. This issue was raised again, widely discussed at that time and quite well documented <a class="info" href="#refs.KATO-VIX">KATO VIXIE<span> (</span><span class="info">Kato, A. and P. Vixie, “DNS Response Size Issues,” July 2004.</span><span>)</span></a>[7], <a class="info" href="#refs.NLNETLAB">NLNETLAB<span> (</span><span class="info">van der Pol, R. and D. Karrenberg, “Adding IPv6 glue to the root zone,” October 2003.</span><span>)</span></a>[8], <a class="info" href="#refs.AFNIC">AFNIC<span> (</span><span class="info">Souissi, M., “DNS Response Size and Name Compression,” September 2004.</span><span>)</span></a>[9]. </p> <p> DNS naming compression quickly appeared as a widely recognized new best-practise to mitigate this DNS limitation. </p> <p> To implement such a "de facto" recommendation, AFNIC decided to move to a new naming designation for its Name Servers, adopting the following specification: </p> <blockquote class="text"> <p>[a-z].nic.fr for servers directly maintained by AFNIC </p> <p>[a-z].ext.nic.fr for those outsourced </p> </blockquote><p> </p> <p> As there were no technical nor operational reasons to change our physical hosts at that time, we decided to add new names for our existing DNS servers, and keep the same IP addresses. New names were planned to be used as official global references announced in the root zone, the other names were kept for internal management reasons and transition purposes. </p> <p> In October 2004, we asked then IANA this new designation for .fr to be announced, which was done, shifting .fr from: </p> <blockquote class="text"> <p>ns1.nic.fr. </p> <p>ns2.nic.fr. </p> <p>ns3.nic.fr. </p> <p>dns.inria.fr. </p> <p>dns.cs.wisc.edu. </p> <p>dns.princetown.edu. </p> <p>ns-ext.vix.com. </p> <p>ns3.domain-registry.nl. </p> </blockquote><p> To respectively: </p> <blockquote class="text"> <p>a.nic.fr. </p> <p>b.nic.fr. </p> <p>c.nic.fr. </p> <p>a.ext.nic.fr. </p> <p>b.ext.nic.fr. </p> <p>c.ext.nic.fr. </p> <p>d.ext.nic.fr. </p> <p>e.ext.nic.fr. </p> </blockquote><p> </p> <p> The root zone includes IP address(es) as additional information for each NS servicing a TLD. Therefore, both references for each Name Server were announced by the root servers, as the new names became autoritave for .fr and old ones stayed authoritave for other TLDs that we operate (AFNIC currently manages 6 TLDs and provides with a secondary services for 18 others). Also, servers like ns3.domain-registry.nl or ns-axt.vix.com were providing with secondary services for many other TLD than .fr; therefore, these names also stayed referenced in the root zone. </p> <a name="rfc.section.3.4"></a><h4><a name="anchor4">3.4</a> .re IANA rejection history</h4> <p> In April 2005, AFNIC sent a form to IANA to update .re. The request pursued two main objectives: </p> <ol class="text"> <li>first, to ask IANA to announce the server located on the Reunion Island; </li> <li>second, to implement homogeneisation and compression; </li> </ol><p> </p> <p> The plan was then to shifted from: </p> <blockquote class="text"> <p>ns1.nic.fr. </p> <p>ns2.nic.fr. </p> <p>ns3.nic.fr. </p> <p>ns3.domain-registry.nl. </p> </blockquote><p> To: </p> <blockquote class="text"> <p>a.nic.fr. </p> <p>b.nic.fr. </p> <p>c.nic.fr. </p> <p>e.nic.fr. </p> <p>e.ext.nic.fr. </p> </blockquote><p> This request was rejected, the following statement was sent to us by mail: "IANA is no longer adding additional examples of host names in delegation records where multiple host names point to the same IP address". </p> <a name="anchor5"></a><br /><hr /> <table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table> <a name="rfc.section.4"></a><h3>4. Rationale (situation the 18th of may 2005)</h3> <p> Inconsistencies between the root zone implementation and IANA policy for .re were : </p> <blockquote class="text"> <p>a.nic.fr and ns1.nic.fr have the same IPv4 address: 192.93.0.1 </p> <p>b.nic.fr and ns2.nic.fr have the same IPv4 address: 192.93.0.4 </p> <p>c.nic.fr and ns3.nic.fr have the same IPv4 address: 192.134.0.49 </p> <p>a.ext.nic.fr and dns.inria.fr have the same IPv4 address: 193.51.208.13 </p> <p>c.ext.nic.fr and dns.princeton.edu have the same IPv4 address: 128.112.129.15 </p> <p>e.ext.nic.fr and ns3.domain-registry.nl have the same IPv4 address:193.176.144.6 </p> </blockquote><p> </p> <p> After having studied this issue, to move forward in implementing AFNIC naming plan, the easiest solution that appeared to us was to add a new IP address for each NS among [a-z].nic.fr and [a-z].ext.nic.fr. </p> <p> Although this was a sensitive extra-work that might have been avoided, it stayed feasible for [a-c].nic.fr which were those servers that we were operating directly. </p> <p> Thing were different for [a-z].ext.nic.fr, as we needed to contact our name server secondary providers to : </p> <ol class="text"> <li> inform them about a new and non documented IANA policy {done}; </li> <li> show them the incidence of this policy on the TLDs they host {done}; </li> <li> ask them to dedicate a new IP address for .fr (they might not be able to do that) {done}; </li> <li> coordinate with them and with IANA to reach a reasonable and safe deployment {in progress}; </li> </ol><p> </p> <a name="anchor6"></a><br /><hr /> <table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table> <a name="rfc.section.5"></a><h3>5. TLD management considerations</h3> <p> >From a management and operation point of view, this unilateral IANA policy change trigger critical matters : </p> <ol class="text"> <li>transparency: what was the nature of the problem? </li> <li>communication: why the DNS community was not informed about it? </li> <li>documentation: where is the reference repository keeping track about up to date IANA policies? </li> <li>speaker: who these kind of issues could be referred to when they raise? </li> </ol><p> </p> <a name="anchor7"></a><br /><hr /> <table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table> <a name="rfc.section.6"></a><h3>6. Security Considerations</h3> <p> This document does not define a protocol. No technical security consideration are really discussed here. However, operational risks and security matters are described under sections <a class="info" href="#homogeneity">3.1<span> (</span><span class="info">Homogeneity</span><span>)</span></a>, <a class="info" href="#distribution">3.2<span> (</span><span class="info">Geographical distribution</span><span>)</span></a> and <a class="info" href="#compression">3.3<span> (</span><span class="info">DNS compression</span><span>)</span></a>. The security risks are also raising with operations described <a class="info" href="#compression">section 4<span> (</span><span class="info">DNS compression</span><span>)</span></a>. </p> <p>Another related issue: information that creates or updates a global TLD information needs to be authenticated <a class="info" href="#refs.CRISPIN">CRISPIN<span> (</span><span class="info">Crispin, K., “The IANA Workflow System,” September 2003.</span><span>)</span></a>[10]. </p> <a name="anchor8"></a><br /><hr /> <table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table> <a name="rfc.section.7"></a><h3>7. IANA considerations</h3> <p> The Internet Corporation for Assigned Names and Numbers (ICANN) has responsibility for country code (ccTLD) Top-Level Domain name system management, and root server system management functions. These services were originally performed under U.S. Government contract by the Internet Assigned Numbers Authority (IANA) and other entities. ICANN now performs the IANA function (ICANN information: <a href="http://www.icann.org/general/">http://www.icann.org/general/</a>). </p> <p> IANA is the Internet Assigned Number Authority. It is dedicated to "preserving the central coordinating functions of the global Internet for the public good" <a href="http://www.iana.org">http://www.iana.org</a>. </p> <p> DNS services provided by IANA and related documentation can be found on the dedicated IANA web page. </p> <p> In the Domain Name System, IANA only deals with assignments at the higher-levels, while sub domains are administered by independent managing registries. </p> <p> In order for the IANA to manage the DNS space prudently, it needs guidelines describing the conditions under which new policies should be implemented. </p> <a name="rfc.references1"></a><br /><hr /> <table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table> <h3>8. References</h3> <table width="99%" border="0"> <tr><td class="author-text" valign="top"><a name="refs.RFC2468">[1]</a></td> <td class="author-text">Cerf., V., “<a href="ftp://ftp.isi.edu/in-notes/rfc2468.txt">I REMEMBER IANA</a>,” RFC 2468, October 1998.</td></tr> <tr><td class="author-text" valign="top"><a name="refs.RFC2929">[2]</a></td> <td class="author-text">Eastlake, D., Brunner-Williams, E., and B. Manning, “<a href="ftp://ftp.isi.edu/in-notes/rfc2929.txt">Domain Name System (DNS) IANA Considerations.</a>,” RFC 2929, September 2000.</td></tr> <tr><td class="author-text" valign="top"><a name="refs.RFC2671">[3]</a></td> <td class="author-text">Vixie., Vixie., “<a href="ftp://ftp.isi.edu/in-notes/rfc2671.txt">Extension Mechanisms for DNS (EDNS0)</a>,” RFC 2671, August 1999.</td></tr> <tr><td class="author-text" valign="top"><a name="refs.RFC1034">[4]</a></td> <td class="author-text">Mockapetris, P., “<a href="ftp://ftp.isi.edu/in-notes/rfc1034.txt">Domain Names - Concepts and Facilities</a>,” RFC 1034, November 1987.</td></tr> <tr><td class="author-text" valign="top"><a name="refs.RFC1035">[5]</a></td> <td class="author-text">Mockapetris, P., “<a href="ftp://ftp.isi.edu/in-notes/rfc1035.txt">Domain Names - Implementation and Specifications</a>,” RFC 1035, November 1987.</td></tr> <tr><td class="author-text" valign="top"><a name="refs.RFC1591">[6]</a></td> <td class="author-text">Postel, J., “<a href="ftp://ftp.isi.edu/in-notes/rfc1591.txt">Domain Name System Structure and Delegation</a>,” RFC 1591, March 1994.</td></tr> <tr><td class="author-text" valign="top"><a name="refs.KATO-VIX">[7]</a></td> <td class="author-text">Kato, A. and P. Vixie, “<a href="http://www.ietf.org/proceedings/04aug/I-D/draft-ietf-dnsop-respsize-01.txt">DNS Response Size Issues</a>,” Internet Draft 01, July 2004.</td></tr> <tr><td class="author-text" valign="top"><a name="refs.NLNETLAB">[8]</a></td> <td class="author-text">van der Pol, R. and D. Karrenberg, “<a href="http://www.nlnetlabs.nl/ipv6/publications/v6rootglue.pdf">Adding IPv6 glue to the root zone</a>,” Draft 00, October 2003.</td></tr> <tr><td class="author-text" valign="top"><a name="refs.AFNIC">[9]</a></td> <td class="author-text">Souissi, M., “<a href="http://w6.nic.fr/dnsv6/resp-size.html">DNS Response Size and Name Compression</a>,” AFNIC D1.52, September 2004.</td></tr> <tr><td class="author-text" valign="top"><a name="refs.CRISPIN">[10]</a></td> <td class="author-text">Crispin, K., “<a href="http://www.centr.org/docs/2003/09/centr-ga19-crispin-iana.pdf">The IANA Workflow System</a>,” CENTR Presentation ga19-05, September 2003.</td></tr> <tr><td class="author-text" valign="top"><a name="refs.IANA">[11]</a></td> <td class="author-text">“<a href="http://www.iana.org/procedures/delegation-data.html">IANA Administrative Procedure for Root Zone Name Server Delegation and Glue Data</a>,” doc 00, July 2004.</td></tr> <tr><td class="author-text" valign="top"><a name="refs.SECSAC">[12]</a></td> <td class="author-text">Crocker, S., “<a href="http://www.icann.org/committees/security/dns-recommendation-01nov03.htm">DNS Infrastructure Recommendation Of the Security and Stability Advisory Committee</a>,” SAC 005, November 2003.</td></tr> </table> <a name="rfc.authors"></a><br /><hr /> <table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table> <h3>Author's Address</h3> <table width="99%" border="0" cellpadding="0" cellspacing="0"> <tr><td class="author-text"> </td> <td class="author-text">Olivier Guillard</td></tr> <tr><td class="author-text"> </td> <td class="author-text">AFNIC</td></tr> <tr><td class="author-text"> </td> <td class="author-text">Immeuble International</td></tr> <tr><td class="author-text"> </td> <td class="author-text">78181 Saint Quentin en Yvelines cedex</td></tr> <tr><td class="author-text"> </td> <td class="author-text">France</td></tr> <tr><td class="author" align="right">Phone: </td> <td class="author-text">+33 1 39 30 83 00</td></tr> <tr><td class="author" align="right">Fax: </td> <td class="author-text">+33 1 39 30 83 01</td></tr> <tr><td class="author" align="right">Email: </td> <td class="author-text"><a href="mailto:Olivier.Guillard@afnic.fr">Olivier.Guillard@afnic.fr</a></td></tr> <tr><td class="author" align="right">URI: </td> <td class="author-text"><a href="http://www.afnic.fr">http://www.afnic.fr</a></td></tr> </table> <a name="anchor10"></a><br /><hr /> <table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table> <a name="rfc.section.A"></a><h3>Appendix A. UPDATE SECTION (what's next after the 18th of may 2005)?</h3> <p> The previous sections were written the 18th of May. </p> <p> At the time this document is posted to related DNS fora, the situation has evolved and might change again over the next few weeks or months. As a new important update, IANA clarified to the RIPE DNS forum that "adding new host names for IP addresses of name servers that already existed in the root zone produced an unexpected result" but that "this issue was now permanently fixed". </p> <p> AFNIC also received a mail from IANA inviting us to "submit a new template at [our] convenience describing all of the changes [we] would like to make" since "the problem with multiple names with the same IP address has been resolved". </p> <p> These new information lead us to contact our secondary providers again, to explain them that the IANA policy has changed yet another time and that the dedicated IPv4 address for .fr that we were asking for is not a IANA requirement anymore. </p> <p> The IANA multi-naming is an ongoing issue that has already generated some exchanges. </p> <p> >From a technical point of view, it appears quite clearly that "multiple names for a single IP is a valid and widely accepted DNS configuration". </p> <p> However, the TLD management and operational matters triggered by this IANA policy change are still discussed : </p> <ol class="text"> <li>transparency : what is the nature of an issue when it raises? </li> <li>communication : how the DNS community is informed about it? </li> <li>documentation : where is the reference repository keeping track about all up to date IANA policies? </li> <li>and still valid : who to talk to when this kind of operational DNS management is raising? </li> </ol><p> </p></body></html> --+HP7ph2BbKc20aGI-- ]