From fgarcia at eurocomercial.es Mon May 2 14:58:27 2005 From: fgarcia at eurocomercial.es (fgarcia at eurocomercial.es) Date: Mon, 2 May 2005 14:58:27 +0200 (CEST) Subject: [dns-wg] Final version of the DNS Migration document Message-ID: <50514.193.0.8.191.1115038707.squirrel@www.eurocomercial.es> In RIPE 49 I introduced a draft version of a document oriented to provide guidelines to operators in the migration of their communications infrastructure, specially DNS servers, from one network to other. We agreed to create a small workgroup to improve the document and this group has worked to create this new version. Now I post to this list so everybody can read it before the WG on thursday. If there's no oposition we think this document can be approved as a official RIPE document and simultaneously I will start working in a second version with some improvements (IPv6 support and others provided by the audience). And now, the document: ----------------------------------------------------------------------------- F.Garcia, Eurocomercial Informatica y Comunicaciones October 2004 Version: 1.0 DNS recommendations and procedures during IP migration INDEX ----- 1 - Abstract 2 - Prerequisites 2.1 - Minimal DNS understanding 2.2 - Control over the new DNS servers 2.3 - Simultaneous addressing 2.4 ? Authorized contact at the related NIC 2.5 - Schedule on time 2.6 - Duplicate DNS HW vs double IP configuration 2.7 - Internet Services dedicated HW 2.8 - Coordination and cooperation between ISPs 3 - Scenario 3.1 - Starting situation 3.2 - Final situation 3.3 - Limitations 4 - Migration procedure 4.1 - Install a new DNS server 4.1.1 - Duplicate the information for the domain 4.1.2 - Modify the server?s own address 4.1.3 - Reduce the SOA times 4.2 - Check the new DNS server 4.3 - Create the new reverse resolution zone file 4.4 - Delegate the reverse resolution 4.5 - Change glue records in the parent DNS server 4.6 - Modify the secondary servers list 4.7 - Verify the secondaries 4.8 - Wait until changes are propagated 4.9 - Change servers? IP addresses 4.9.1 - Modify "IN A" resource records 4.10 - Wait for propagation 4.11 - Restore SOA Values 4.12 - Shutdown servers in the old IP range APPENDIX A - SOA Values APPENDIX B - Bibliography -- 1 - Abstract One of the most complex and problem prone situations which might happen when operating a DNS server -even more complex than its initial installation- is to perform all tasks involved in an IP space migration. (i.e. Move all the information services in use in an organisation which is using the IP space assigned by its original provider, to a new IP space assigned by a new provider). This migration implies an orderly sequence of changes in the information services under the organisation?s domain name (i.e. web, e-mail, ftp, ...). These changes basically involve updating the IP addresses of these services/servers in the primary DNS server for that domain. Since this is not a situation which network or systems administrators need to handle very often, it is common to make mistakes when undertaking the migration process, mistakes which might be fatal for the services depending on the DNS service. This document is intended to be a step by step guide to system and network administrators, so they can have a problem free migration with full continuity of all services. Procedures will be defined in the most generic way possible, so that this will be a useful tool for all administrators. 2 - Prerequisites To be able to do the migration process and avoid problems, the administrator must check in advance that all requirements needed for the migration are met. 2.1 - Minimal DNS understanding Although this procedure does not require in-depth knowledge of the DNS protocol and its implementations, it is necessary to have a minimal understanding of DNS fundamentals and the implementation used. (i.e. BIND, NSD, ADNS, dnscache, etc). The bibliography listed in appendix B should be useful for this purpose. 2.2 - Control over the new DNS servers The person in charge of the domain migration, or an operator under his/her supervision, must have control over the contents and operation of the DNS server that will contain the domain information at the end of the migration. 2.3 - Simultaneous addressing The procedure described in this document, requires that both ranges of IP addresses be simultaneously active during the migration. Therefore, the organisation must stay connected to both ISPs until the migration is complete. 2.4 - Authorised contact at the related NIC The person responsible for the migration must be registered with the NIC as the administrative and/or technical contact, with permission to make changes in the domain information, specifically the host name and IP address of the domain name servers. 2.5 - Schedule on time In order to avoid problems with time expiration and with incorrect cached data all the migration procedure must be scheduled with plenty of time. Two weeks should be safe if following the standard SOA values recommended by RIPE and/or the local NIC. 2.6 - Duplicate DNS HW vs double IP configuration This migration plan requires that the hardware used by the DNS servers is independent of the hardware used by the other servers and services to be transitioned, so that the change of network configuration on these servers can be made without impact on the other services. Also, to ensure the stability of the services, these DNS servers must be duplicated during the transition, so you need duplicate machines. It might also be possible in some situations to migrate from one IP space to a new one configuring the same server with different IP addresses so that the DNS server can listen on both of them. If using BIND 9 and you?re familiar with it, you can use the views mechanism to have different replies going out (the old and the new address ranges) depending on the interface and use only one server with dual IP. This is not always possible: If the network is migrated from one physical location to other while the addressing change takes place, you can't keep the server running with both IP addresses. Also, some NICs check thoroughly the DNS zone file before making the migration, and some inconsistencies, like having the IP address of the DNS server incorrectly stated in the zone file, can trigger alarms and abort the change. 2.7 - Duplicate Internet Services HW Duplicating the other Internet Services equipment will not only allow the domain to be visible at all times throughout the transition, but also to keep the services running during the entire process. The discussion about duplicate hardware vs double IP configuration also applies here. If you do not use duplicate servers or dual IP addressing in the machines, you will have to accept temporary lack of availability of services during the transition. 2.7 - Coordination and cooperation between ISPs This kind of transition frequently occurs because you are moving from one service provider to another. In these cases, you may not be able to get much assistance from the provider you are leaving, but this process is likely to be much more difficult without the help of both providers, so you must try all reasonable methods to get support from both providers. 3 - Scenario The proposed scenario is probably one of the most complex possible, but it's also one of the most generic, and can be tailored to other situations removing the extra procedures. All examples across the document use the RFC 1918 IP address ranges [1]. Obviously the addresses to use during a real migration should be the ones assigned to the organisation by the corresponding RIR/LIR. REMEMBER: The addresses used in this document are not valid addresses and you should replace them with your own addresses, so do not simply copy and paste these examples, and double check the information for correctness. Likewise, the domains and subdomains used in the examples are fictitious and use the standard "example.com"[2]. You should replace this fictitious domain with your assigned domain name. All examples in this document assume that your DNS servers use BIND 9.x running over some kind of Unix/Linux server. You should adapt these examples to your own DNS SW implementation. 3.1 - Starting situation Organisation X has registered the domain "example.com". This organisation X has Internet connectivity through Internet carrier A, which has assigned to organisation X the IP range 192.168.10.0/24 of its PA (provider aggregatable) addressing block. Organisation X also has a secondary DNS server hosted in an external network for purposes of DNS redundancy. The IP address of this server is 172.16.5.2 Using this range, the network administrator of the organisation X has inserted the following information in the glue records of the delegating zone: * Primary server of the domain "example.com": 192.168.10.2 * Secondary server of the domain "example.com": 172.16.5.2 The domain servers are configured consequently with these address and their DNS servers to translate their names to its IP address: * www.example.com translates to 192.168.10.10 * mail.example.com translates to 192.168.10.15 He also configured the mail server information for the domain: * The mail server for the domain example.com is mail.example.com with a preference of 10 The administrator of the network has configured the inverse resolution of the network in the name servers after delegating this inverse resolution in the RIR/LIR. The network administrator has configured the inverse resolution of the network in the name servers after getting the corresponding in-addr.arpa. domain delegated from the RIR/LIR. The zone configuration files should be as follows: (ripe-203 SOA values have been used) $ORIGIN example.com. ; @ IN SOA primary.example.com. hostmaster.example.com. ( 2001070401 ; serial based on "date+number" 86400 ; refresh, seconds 7200 ; retry, seconds 3600000 ; expire, seconds 172800 ) ; Minimum TT, seconds ; name servers IN NS primary.example.com. IN NS secondary.example.com. ; mail servers IN MX 10 mail.example.com. localhost IN A 127.0.0.1 www IN A 192.168.10.10 mail IN A 192.168.10.15 primary IN A 192.168.10.2 secondary IN A 172.16.5.2 The inverse resolution from IP to names -this resolution must be delegated from RIPE or the LIR- is as follows: $ORIGIN 10.168.192.IN-ADDR.ARPA. @ IN SOA primary.example.com. hostmaster.example.com. ( ; 2001070401 ; serial based on "date+number" 86400 ; refresh 7200 ; retry 3600000 ; expire 172800 ) ; minimum TTL ; name servers IN NS primary.example.com. IN NS secondary.example.com. ; host lists 2 IN PTR primary.example.com. 10 IN PTR www.example.com. 15 IN PTR mail.example.com. 3.2 Final situation After the migration is complete, the organisation "X" will be connected through carrier "B" and both organisations have agreed carrier "B" to assign to organisation "X" a new IP range, specifically 10.40.5.0/24. The new servers will have the following information: * Primary server for the domain "example.com": 10.40.5.2 * Secondary server for the domain "example.com" (it doesn't change): 172.16.5.2 The address for the associated servers should be set as follows: * www.example.com translates to 10.40.5.10 * mail.example.com translates to a 10.40.5.15 The mail server will be configured for the domain as follows: * The mail server for the domain example.com is mail.example.com with a * preference of 10 and no secondary mail server The reverse resolution for the new IP range will be delegated and configured correctly. The archive for the zone must eventually have this configuration: $ORIGIN example.com. ; @ IN SOA primary.example.com. hostmaster.example.com. ( 2001072001 ; serial based on "date+number" 86400 ; refresh, seconds 7200 ; retry, seconds 3600000 ; expire, seconds 172800 ) ; minimum TTL, seconds ; name servers IN NS primary.example.com. IN NS secondary.example.com. ; mail servers IN MX 10 mail.example.com. localhost IN A 127.0.0.1 www IN A 10.40.5.10 mail IN A 10.40.5.15 primary IN A 10.40.5.2 secondary IN A 172.16.5.2 And the DNS configuration for the new inverse resolution, that you should be delegated from the RIR/LIR, will be: $ORIGIN 5.40.10.IN-ADDR.ARPA. @ IN SOA primary.example.com. hostmaster.example.com. ( ; 2001072001 ; serial based on "date+number" 86400 ; refresh 7200 ; retry 2592000 ; expire 172800 ) ; minimum TTL ; name servers IN NS primary.example.com. IN NS secondary.example.com. ; hosts list 2 IN PTR primary.example.com. 10 IN PTR www.example.com. 15 IN PTR mail.example.com. 3.3 - Limitations Some of the procedures described in this work are specific of each NIC, mainly the administrative tasks and the forms to be submitted. In the following description the steps associated with the NIC are explained generically using the common subset. 4 - Migration procedure The underlying idea is to achieve the transition in a limited number of steps, and to complete each one of them, including the times required for the changes to get propagated, before starting the next step. 4.1 - Install a new DNS server As explained before, it is advisable to install a new primary DNS server with the new ISP's IP addresses, and otherwise the same information as the old DNS primary server. The steps to introduce new data in this machine are: 4.1.1 - Duplicate the information for the domain Once there is a new primary nameserver in the new ISP (i.e. either running BIND, dnscache, djbdns, nsd, etc) the configuration and zone files need to be the same as those in the nameservers hosted by the previous ISP (which are still up & running), except for minor changes. This can be achieved with a zone transfer (AXFR) from the old primary server to the new server. If running BIND, this can be achieved by running the following command: #dig @192.168.10.2 example.com. axfr in > /etc/example.db Once the zone is transferred, the domain name has to be added to the configuration file, usually called named.conf in BIND installations. It should look like this: zone "example.com." { type master; file example.db; }; It is essential to preserve the current addresses for the internet servers, so for instance our web server www.example.com must continue to have a "IN A" record with its original IP address: $ORIGIN <...> www IN A 192.168.10.10 4.1.2 Modify the primary DNS server's IP address It is also necessary to edit the zone file (example.db) to modify the "IN A" resource record of the DNS server to point to itself. From: primary IN A 192.168.10.2 To: primary IN A 10.40.5.2 The secondary servers only need to be modified if they are in the IP space of the previous ISP. However, remember that having all your name servers in the same subnetwork is not recommended. See section 3.1 of RFC 2182 [5] for an explanation. So far no changes have been made in the parent servers hosted by the corresponding NIC or registrar. This will be done after a few additional steps. 4.1.3 Reduce SOA times Once the described changes are done in the zone file, it is necessary to reduce the times expressed in the SOA header of the zone file "example.db". Originally, if RIPE recommendations are adopted, the SOA header will look like this: @ IN SOA primary.example.com. hostmaster.example.com. ( ; 2001072001 ; serial based on "date+number" 86400 ; refresh, seconds 7200 ; retry, seconds 2592000 ; expire, seconds 172800 ) ; TTL minimum, seconds It is recommended to take note of these values, in order to restore this configuration after the migration process is completed. Suggested values for this field depend of the load of the servers, how critical the services are, and if they can be duplicated. If some of them can be duplicated and/or are not critical, the values can be relaxed. Field Old value New value without dupl. New value with dupl. Serial number X X+1 X+1 Refresh 86400 300 14400 Retry 7200 150 (=)7200 Expire 2592000 (=)2592000 (=)2592000 TTL 172800 300 14400 - Fields marked with (=) do not need to be modified and can preserve their original values. - The field "serial" must be incremented with respect to the previous value of the same field. This is the only technical requirement of this field, but most organisations related to domain handling suggest that the serial number follows the format: YYYYMMDDNN, with YYYY being the year with four digits, MM the month with two digits, DD the day of the month with two digits and NN the change number inside that day and starting by one each day. - Refresh: as in the case where duplication of nameservers was possible, reducing this time to a lower value, makes the secondary servers transfer and update the zone file more often, so the duration of a possible blackout is reduced to that time (i.e. five minutes). Query rate will raise in the servers, as the information cached will last for only five minutes (i.e. due to the TTL value) and it will be queried much more frequently than usual, but still this is considered to be a safe value. In case most of the DNS traffic received by this organization comes from the same time zone, it is advisable to perform all these changes during the period of lower load on the services, usually by night (or during the weekend). After all these changes the file "example.db" will have the following data. Take into account that the only A resource records that have new values are the ones of the DNS servers themselves: @ IN SOA primary.example.com. hostmaster.example.com. ( ; 2001072002 ; serial based on "date+number" 300 ; refresh, seconds 150 ; retry, seconds 2592000 ; expire, seconds 300 ) ; minimum TTL, seconds ; name servers IN NS primary.example.com. IN NS secondary.example.com. ; mail servers IN MX 10 mail.example.com. localhost IN A 127.0.0.1 www IN A 192.168.10.10 mail IN A 192.168.10.15 primary IN A 10.40.5.2 secondary IN A 172.16.5.2 4.2 - Reload the DNS server Once the values in the SOA header have been updated and reduced, it is necessary to reload the zone and check that the server is operating as expected. In case BIND is in use, these commands can be used: To reload the server if using BIND 8: # ndc reload To reload the server if using BIND 9: # rndc reload To check that the server is running appropriately: # ndc status or with BIND 9: # rndc status If logging has been appropriately configured, it is advisable to check the logs and verify that the zone modified has loaded correctly. If using the NOTIFY feature, we could also see whether the server has "notified" the secondary servers about the changes. Finally, querying the server by using the "dig" tool is recommendable: $ dig @10.40.5.2 www.example.com ; <<>> DiG 9.2.2 <<>> @10.40.5.2 www.example.com ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26413 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1 ;; QUESTION SECTION: ;www.example.com. IN A ;; ANSWER SECTION: www.example.com. 300 IN A 192.168.10.10 ;; AUTHORITY SECTION: example.com. 300 IN NS primary.example.com. ;; ADDITIONAL SECTION: primary.example.com. 300 IN A 10.40.5.2 ;; Query time: 4 msec ;; SERVER: 10.40.5.2#53(10.40.5.2) ;; WHEN: Sun Mar 27 21:47:15 2005 ;; MSG SIZE rcvd: 81 4.3 - Create the new reverse resolution zone file The reverse mapping does not suffer from any race condition. You can safely set it up in advance for the new address space and take down the old addresses after the migration. There are also no glue records problems so this step can be taken even before installing any machine in the new range. You need to create a new domain configuration file for the reverse zones and add it to your DNS server configuration file. Reload the DNS server configuration after these changes so the new information is served. In the secondary server simply add the following lines to /etc/named.conf: Zone "5.40.10.in-addr.arpa." in { type slave; file "db.10.40.5"; masters { 10.40.5.2; }; }; Reload the DNS server configuration file after this configuration. 4.4 - Delegate the reverse resolution Request to your RIR/LIR the delegation of the "in-addr.arpa." zone corresponding to the new IP range. This delegation must be made pointing to the address of the new DNS servers (10.40.5.2 and 10.40.5.240) 4.5 - Modify glue records in the parent DNS server This is now possible. Requesting the change of the glue records for the zone we are migrating is a critical administrative process wich involves submitting the corresponding form. In this form, you need to request the change of IP address for the primary server of the zone, and also for the secondaries in case these were in the network of the previous ISP and will move to the new ISP network. Typically, ccTLD NICs have their own form, usually just in their local languages and sometimes in English as well. Using a local registrar entity could solve the possible language issue. The same applies basically for generic TLDs (.com, .org, .net, etc). The duration of this process absolutely depends on the NIC responsible for that domain and the period of time to wait until changes are alive, may go from hours to even weeks. NICs will normally have a mechanism to notify the domain owners that the changes have been applied, but it is recommended to verify this by following this procedure. Checking the information in the whois database: [localhost:~] fernando% whois example.com Whois Server Version 1.3 Domain names in the .com, .net, and .org domains can now be registered with many different competing registrars. Go to http://www.internic.net for detailed information. Domain Name: example.com Registrar: NETWORK SOLUTIONS, INC. Whois Server: whois.networksolutions.com Referral URL: http://www.networksolutions.com Name Server: PRIMARY.example.com Name Server: SECONDARY.example.com Updated Date: 03-may-2001 4.6 - Modify the secondary servers list Once the NIC has performed the requested changes in the WHOIS database and the DNS parent servers, and the changes have propagated, it is time to update the secondary servers. These servers should be in different networks and hence change requests will be sent to the corresponding administrators. The secondary nameserver administrators will have to change all possible references to the primary server IP address to the new IP address and reload their servers if possible so that changes become effective immediately. This change is made by modifying the following fields: For servers with versions 8.x or 9.x of BIND the file to be modified is /etc/named.conf and the change to be made is: Zone "example.com" in { Type slave; File "db.example"; Masters { 10.40.5.2; }; }; Where 10.40.5.2 is the IP address for the new primary nameserver of the domain. 4.7 - Verify the secondaries Once these changes are made, you must check the change using dig as in the following example: $ dig @ secondary.example.com example.com ; <<>> DiG 9.2.2 <<>> @secondary.example.com example.com ns ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22267 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; QUESTION SECTION: ;example.com. IN NS ;; ANSWER SECTION: example.com. 300 IN NS primary.example.com. example.com. 300 IN NS secondary.example.com. ;; ADDITIONAL SECTION: primary.example.com. 300 IN A 10.40.5.2 secondary.example.com. 300 IN A 172.16.5.2 ;; Query time: 71 msec ;; SERVER: 172.16.5.2#53(secondary.example.com) ;; WHEN: Sun Mar 27 21:58:41 2005 ;; MSG SIZE rcvd: 61 You must check the information of the primary server shown in the reply. The IP address associated to this must be the new one you have just set. If the address is the old one, then the change has not taken effect because the secondary server did not reload the data or it is incorrectly configured. 4.8 - Wait until changes are propagated Once all changes are done, it is necessary to wait until the new information is propagated. The minimum time for this to happen would be the "Expiration" time expressed in the SOA header. It is recommended to check the changes have propagated by querying other nameservers randomly chosen as in the previous step. When all these servers return (reply) the new information, it is possible to proceed with the next steps. 4.9 - Change servers IP addresses Next, it is necessary to change the Internet servers IP addresses. To migrate all the network it is necessary to modify all these "IN A" resource records so they make reference to the new IP addresses assigned to the organisation by the new ISP. This has to be coordinated with the configuration of the new systems with the new IP addresses, otherwise the DNS service will be pointing to non existing internet servers. Again, as it occurred with the DNS service migration, all this process will be much easier if duplication of servers is possible. 4.9.1 - Modify "IN A" RRs Once the servers are installed in the new IP range it is necessary to modify the "IN A" resource records so they point to the new servers. This means editing and modifying the zone file content. The servers must be changed in the example.db zone file from: www IN A 192.168.10.10 mail IN A 192.168.10.15 to: www IN A 10.40.5.10 mail IN A 10.40.5.15 4.10 - Wait for propagation Use the method described previously with the dig command to verify the redistribution of the changes. Use a randomly selected group of servers as a statistical measure of the change. 4.11 - Restore SOA values Just like we did for the DNS server changes, we will wait until the contents of the zone file get propagated, checking a list of random nameservers to verify this. SOA times have to remain low until all changes are done and the new information is propagated. Afterwards, the recommended values (v.g. RIPE recommended values) should be restored. 4.12 - Shutdown services in the old IP range Once the changes are done, all request are directed to the new servers and you can then shutdown all servers in the old IP range, both DNS and Internet services servers. -- APPENDIXES APPENDIX A. SOA values Beside the recommendations that RIPE and the local NIC made regarding the SOA values to be filled in the domain files for the second level domains, in order to know the expiration time of the IP addresses assigned to that domain, you must also know the SOA values of the TLD associated. You can then check the TTL field and know how long the old DNS server address will stay in the cache of the client resolvers. To discover these (sometimes unpublished) values, do the following: [localhost:~] fernando% dig es. ns ; <<>> DiG 9.2.2 <<>> es. ns ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56403 ;; flags: qr rd ra; QUERY: 1, ANSWER: 9, AUTHORITY: 0, ADDITIONAL: 1 ;; QUESTION SECTION: ;es. IN NS ;; ANSWER SECTION: es. 3571 IN NS munnari.oz.au. es. 3571 IN NS ns.uu.net. es. 3571 IN NS ns1.nic.es. es. 3571 IN NS ns1.cesca.es. es. 3571 IN NS ns2.nic.es. es. 3571 IN NS ns3.nic.fr. es. 3571 IN NS sun.rediris.es. es. 3571 IN NS ineco.nic.es. es. 3571 IN NS sunic.sunet.se. ;; ADDITIONAL SECTION: ineco.nic.es. 3571 IN A 194.69.254.2 ;; Query time: 5 msec ;; SERVER: 192.168.56.2#53(192.168.56.2) ;; WHEN: Sun Mar 27 22:51:01 2005 ;; MSG SIZE rcvd: 248 [localhost:~] fernando% dig @ns1.nic.es es. soa ; <<>> DiG 9.2.2 <<>> @ns1.nic.es es. soa ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13899 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 9, ADDITIONAL: 8 ;; QUESTION SECTION: ;es. IN SOA ;; ANSWER SECTION: es. 3600 IN SOA ns1.nic.es. hostmaster.nic.es. 2005032701 86400 7200 2592000 3600 ;; AUTHORITY SECTION: es. 3600 IN NS sunic.sunet.se. es. 3600 IN NS munnari.oz.au. es. 3600 IN NS ns.uu.net. es. 3600 IN NS ns1.nic.es. es. 3600 IN NS ns1.cesca.es. es. 3600 IN NS ns2.nic.es. es. 3600 IN NS ns3.nic.fr. es. 3600 IN NS sun.rediris.es. es. 3600 IN NS ineco.nic.es. ;; ADDITIONAL SECTION: ns1.nic.es. 3600 IN A 194.69.254.1 ns1.cesca.es. 4142 IN A 84.88.0.3 ns2.nic.es. 3600 IN A 194.69.254.38 ns3.nic.fr. 176944 IN AAAA 2001:660:3006:1::1:1 sun.rediris.es. 551 IN A 130.206.1.2 ineco.nic.es. 3600 IN A 194.69.254.2 munnari.oz.au. 115754 IN A 128.250.22.2 munnari.oz.au. 115754 IN A 128.250.1.21 ;; Query time: 69 msec ;; SERVER: 194.69.254.1#53(ns1.nic.es) ;; WHEN: Sun Mar 27 22:52:25 2005 ;; MSG SIZE rcvd: 419 Doing this operation for the parent zone associated to the domain one you are migrating, you can get the expiration and renewal times. i.e. If you are migrating the domain example.com.es you should discover the values for the zone com.es For the .es domain this values are (in seconds): Refresh 86400 Retry 7200 Expire 2592000 Minimum TTL 3600 For the .com, .net domain this values are: Refresh 1800 Retry 900 Expire 604800 Minimum TTL 900 For the .org domain this values are: Refresh 1800 Retry 900 Expire 604800 Minimum TTL 86400 APPENDIX B. References [1] RFC-1918 - Address Allocation for Private Internets, February, 1996 [2] RFC-2606 - Reserved Top Level DNS Names [3] ripe-203 - Recommendations for DNS SOA Values [4] ripe-114 - Taking Care of Your Domain [5] RFC-2182 - Selection and Operation of Secondary DNS Servers [6] "DNS & BIND 4th Edition" by Paul Albitz & Cricket Liu, O'Reilly & Associates Inc. [7] http://www.apache.org/ [8] D. Barr, RFC 1912, Common DNS Operational and Configuration Errors, 1 February, 1996 [9] P. Vixie, RFC 1996, A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY), August, 1996 From pk at DENIC.DE Wed May 4 23:55:03 2005 From: pk at DENIC.DE (Peter Koch) Date: Wed, 4 May 2005 23:55:03 +0200 Subject: [dns-wg] Action Item 48.1: Lame Delegations -- first draft Message-ID: <20050504215503.GA10642@denics7.denic.de> Dear all, here is a first draft addressing action item 48.1 on lame delegation problems on large scale name servers. It's a -00 kind of document mainly issuing the problem statement. Although there are some hours left, I don't expect anyone to have read it by the WG meeting. An HTML version may be made available later and depending on how the PDP evolves, we might want or need to inject it into the policy developing engine. Comments are welcome! -Peter -------------- next part -------------- RIPE DNS WG 48.1 P. Koch DENIC eG May 4, 2005 DNS lame delegations caused by AXFR source unavailability Abstract This document analyses causes for DNS lame delegations seen on large name servers and investigates and assesses countermeasures. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Signs of Lame Delegations . . . . . . . . . . . . . . . . . . 2 3. Problems on large name servers . . . . . . . . . . . . . . . . 3 4. Ways to deal with missing XFR source . . . . . . . . . . . . . 4 5. Proactive measures . . . . . . . . . . . . . . . . . . . . . . 5 6. Wishlist . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 7. Security Considerations . . . . . . . . . . . . . . . . . . . 5 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 9. Disclaimer . . . . . . . . . . . . . . . . . . . . . . . . . . 5 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 6 A. Copyright Statement . . . . . . . . . . . . . . . . . . . . . 6 Koch [Page 1] RIPE DNS WG DRAFT Large Scale DNS Lame Dels May 2005 1. Introduction This document analyses causes for DNS lame delegations seen on large (thousands of zones) name servers and investigates and assesses countermeasures. First we will define the term "lame delegation" and similar operational problems. In the third section we will address various reasons that lead to lame delegations. The fourth paragraph will summarize mechanisms server administrators currently do or could apply to lower the impact of lame delegations. 2. Signs of Lame Delegations A lame delegation is a DNS delegation where the target of the NS RR does not respond authoritatively to queries for the domain so delegated. Lame delegations show different symptoms, which are sometimes given separate names: 1. The server's responses do not have the AA bit set 2. The server responses with an (upward) referral 3. The server responses SERVFAIL 4. The server responses REFUSED 5. The server refuses the query packet (giving either ICMP port unreachable or TCP RST) 6. The server does not respond at all 7. The server's name does not exist (NXDOMAIN) 8. The server's name does not own any A (or AAAA) RRs Cases (1) and (2) above are classical signs of a zone that has been forgotten by its server, either by expiry or due to syntax errors. Cases (1) through (4) are common lame delegations, cases (5) and (6) often just appear as temporary operational problems and cases (7) and (8) are sometimes called stale delegations. The latter may result in a significant increase of the query volume at the servers serving the domain the non existing name server is expected to reside in. When all delegations for a domain are lame, the domain is delegated Koch [Page 2] RIPE DNS WG DRAFT Large Scale DNS Lame Dels May 2005 perfectly lame. While operational guidelines suggest that the NS RRSet of a zone and the corresponding delegation in the parent zone should match, there are sometimes inconsistencies. Without acknowledging or endorsing this practice the union of both NS RRSets shall be eligible for a lame delegation assessment. In other words, even an NS RR that is only present in the delegated (child) zone may constitute a lame delegation as well. 3. Problems on large name servers RFC 1034 [RFC1034] specifies the way and frequency the slave will check with the master for a zone change. Details are controlled by the "refresh", "retry" and "expire" timer values. A slave is expected to try checking a zone with its master (For the sake of simplicity we assume there is only a single master per slave) until it either succeeds or the "expire" timer is reached, after which the zone should be "discarded". Different software implementations handle this in different ways [[list to be added]]. Software implementations currently either apply hard coded upper and lower bounds to these timer values or allow for their manual configuration. This aids in preventing unjustified resource consumption by unfortunate configurations. While the (primary) master not necessarily needs to be delegated the zone (hidden or stealth master), it may become unresponsive or non- authoritative. As a consequence, the slave or slaves depending on this master will subsequently have to discard the zone and become lame themselves. Reasons may be one or more of: o The slave cannot connect to the master o SOA not available at master o SOA not authoritative at master o SOA OK, AXFR refused o AXFR breaks o Zone does not load If the SOA check or the subsequent AXFR between master and slave fails, there are multiple potential causes: Koch [Page 3] RIPE DNS WG DRAFT Large Scale DNS Lame Dels May 2005 o Syntax error in zone at master o CNAME sin (CNAME at zone apex) o SOA serial decremented o error in zone list at master (forgot zone) o Customer changed AXFR source o Customer applied (too strict) access control o Customer vanishes o Address space reassigned ("you are attacking me on port 53") o Software problem at master Name servers serving large numbers of slave zones, may thus face two different problems related to lameness: o Increased traffic, sometimes even query storms, due to lame delegations. This may be worse if the zone is delegated perfectly lame (master and all slaves are delegated lame. o A significant fraction of resources may be spent on the higher frequency retries caused by SOA check failures. This may decrease the servers' performance and degrade service for all other zones on that server. 4. Ways to deal with missing XFR source ignore This may result in a service degradation for all customers. call customer This is tedious, expensive and sometimes impossible, if there is no direct relationship between the name server operator and the zone maintainer. deconfigure zone The delegation will usually remain and queries will continue to arrive. substitute missing zone with last available copy Introduces (other type of) inconsistencies, may be difficult to get hands on "latest version" Koch [Page 4] RIPE DNS WG DRAFT Large Scale DNS Lame Dels May 2005 substitute missing zone with empty zone This is invasive, introduces hard failures and may thus increase load on the hotline. have delegation revoked The name service provider may not necessarily be able to authoritatively (pun intended) communicate with a registrar or a registry. 5. Proactive measures Logs on the slave should be inspected automatically for signs of AXFR source unavailability as an early warning measure. Zone maintainers, name server operators and registries can prevent certain problems by (more) careful tailoring of SOA timer parameters. 6. Wishlist From a name server operator's perspective it would be helpful if the operator could change or delete a delegation to his name server and could change the server's registered IP address, if any. There are two problems with this approach: authentication of the server operator and status of the domain should the number of active delegations fall below a required minimum. In the long run it may be useful to give the name server operator a dedicated role in the current concept of the "triple R trio". Software vendors could add logic to prefer sane zones' SOA checks over those for potentially abandoned ones, maybe by applying some (timer) penalty to zones that could not be verified with the master for a "long" time (for given "refresh", "retry" and "expire" values. 7. Security Considerations DNSSEC may introduce additional problems, when a slave has data with outdated sigantures only. In addition, substituting an expireed zone with an empty or the last available copy will no longer be feasible. 8. Acknowledgements Thanks to Andre Koopal from MCI NL for bringing this up at RIPE 48. 9. Disclaimer The measures are listed here for informational purposes only. None of them is yet recommended and they should be used after a careful risk/benefit assessment only. Koch [Page 5] RIPE DNS WG DRAFT Large Scale DNS Lame Dels May 2005 This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE REPRESENTS OR IS SPONSORED BY (IF ANY), DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Any position taken by the author reflects his personal views and does not constitute a policy statement of the sponsoring institution. 10. References [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. [RFC1912] Barr, D., "Common DNS Operational and Configuration Errors", RFC 1912, February 1996. [RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)", RFC 1996, August 1996. [RIPE203] Koch, P., "Recommendations for DNS SOA Values", RIPE 203, June 1999. Author's Address Peter Koch DENIC eG Wiesenhuttenplatz 26 Frankfurt 60329 DE Phone: +49 69 27235 0 Email: pk at DENIC.DE Appendix A. Copyright Statement Copyright (C) Peter Koch, DENIC eG (2005) Koch [Page 6] From Ed.Lewis at neustar.biz Thu May 5 11:54:39 2005 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Thu, 5 May 2005 11:54:39 +0200 Subject: [dns-wg] Action Item 48.1: Lame Delegations -- first draft In-Reply-To: <20050504215503.GA10642@denics7.denic.de> References: <20050504215503.GA10642@denics7.denic.de> Message-ID: At 23:55 +0200 5/4/05, Peter Koch wrote: >Dear all, > >here is a first draft addressing action item 48.1 on lame delegation problems >on large scale name servers. It's a -00 kind of document mainly issuing the >problem statement. Although there are some hours left, I don't expect >anyone to have read it by the WG meeting. An HTML version may be made >available later and depending on how the PDP evolves, we might want or need >to inject it into the policy developing engine. Comments are welcome! Okay, "comments are welcome." ;) Here they come... # RIPE DNS WG 48.1 P. Koch # DENIC eG # May 4, 2005 # # # DNS lame delegations caused by AXFR source unavailability ... # RIPE DNS WG DRAFT Large Scale DNS Lame Dels May 2005 # # # 1. Introduction # # This document analyses causes for DNS lame delegations seen on large # (thousands of zones) name servers and investigates and assesses # countermeasures. # # First we will define the term "lame delegation" and similar # operational problems. In the third section we will address various # reasons that lead to lame delegations. The fourth paragraph will # summarize mechanisms server administrators currently do or could # apply to lower the impact of lame delegations. # # 2. Signs of Lame Delegations Please, no more jokes about my picture appearing here. ;) # A lame delegation is a DNS delegation where the target of the NS RR # does not respond authoritatively to queries for the domain so # delegated. # # Lame delegations show different symptoms, which are sometimes given # separate names: # # 1. The server's responses do not have the AA bit set # # 2. The server responses with an (upward) referral # # 3. The server responses SERVFAIL # # 4. The server responses REFUSED # # 5. The server refuses the query packet (giving either ICMP port # unreachable or TCP RST) # # 6. The server does not respond at all # # 7. The server's name does not exist (NXDOMAIN) # # 8. The server's name does not own any A (or AAAA) RRs Some others... First, let's assume that the query is (akin to): dig soa +norec There can be "no error/no data" - a problem unique to the reverse map is that registrants who have a /17 worth of IPv4 address space might have mistakenly configured the entire /16 and not the 128 /24's they really have. (This is one of a few places were I can isolate an diagnosis from the symptoms that are observable.) Another failure scenario to consider is that, just like the query for the SOA, you can have no response for the address lookup for the domain name of the name server. I.e., akin to #7 and #8, there's a "name query is not answered." #6 is a problem. There is a name server implementation that will answer only for what it is authoritative for - and not answer at all for other queries. So, imagine a registrant has a /22 and reserves the first 256 addresses (a /24) for later use. The registrant may not configure the zone because it's not being used - meaning the first zone goes response-less on the server, but the other 24's are good. (This assumes you group the zones by some registration record.) I believe it would be good to document the query you will use and what the set of acceptable answers will be. I considered the return code, authority bit, answer and authority counts. (An answer count of 1 and authority records could indicate a CNAME in the answer and a referral to another server. Yes, it happens.) # Cases (1) and (2) above are classical signs of a zone that has been # forgotten by its server, either by expiry or due to syntax errors. # # Cases (1) through (4) are common lame delegations, cases (5) and (6) # often just appear as temporary operational problems and cases (7) and # (8) are sometimes called stale delegations. The latter may result in # a significant increase of the query volume at the servers serving the # domain the non existing name server is expected to reside in. Okay, now I'm going to start down a path that may lead to a rathole. (Just a warning to regular participants of mailing lists.) First, trying to guess the reason for symptoms is a slippery slope. Over the years I have found such a divergence in operational practices that diving what's in the configuration file via the network protocol is nearly impossible. There are some common meltdowns - like configuring the /16 instead of 128 /24's for a /17 - but there aren't enough "common" meltdowns to say that we can efficiently send diagnosis to all the problem cases. I no longer have an idea of numbers, but I think that something like 10-30% of problems (depending on how you count problems) fall into easy to diagnose, the remaining majority quickly falls into "other problems." Second, to begin the pathway to the home of the rat, you have to ask "what do you want to do here?" What is a lame delegation? A lame server is defined a few times in RFCs. Is the purpose to prune off lame servers or clean up DNS operations? E.g., what if you see a server answering correctly for a zone and the other server is running recursively and answers non-authoritatively. This could be because the second server has learned the answer from the first via something like forwarding. In this case, both servers answer correctly and won't cause an operational problem (which is where the 'problem' of lame delegations originated). However, such a configuration could be considered a problem registration (not truly meeting the need for 2+ servers), and may even be an indication of subscriber (registrant) fraud. (I.e., hijacking by changing the name server registrations, etc.) The rathole is "what's the target of stamping out lame delegations?" My work in the field (no longer being pursued, at least by me) resulted in just stating "observations." I.e., no diagnosis, just a report. Servers that did not answer gave "never heard from" or "last heard from" dates. The cautionary tale here is that - because you need to repeat tests (I'm just stipulating that here) to properly test non-answering servers, sometimes a server that passed a test will slip into a failure mode. My tests ignored "once good" results, meaning fat fingering post haste could introduce lameness. (No test can really stop that.) But the test code has to be able to "deal with it." # While operational guidelines suggest that the NS RRSet of a zone and # the corresponding delegation in the parent zone should match, there # are sometimes inconsistencies. Without acknowledging or endorsing # this practice the union of both NS RRSets shall be eligible for a # lame delegation assessment. In other words, even an NS RR that is # only present in the delegated (child) zone may constitute a lame # delegation as well. I firmly believe that you cannot require that the parent copy of the NS set be the same as the child NS set. The parent copy should be a subset (improper or proper) at all times. As a lame tester, you should be testing against the parent set only - as that's the data registered. I'll stop with just comments on lame delegations for now. One thing to keep in mind is how to discuss this. It would be good to document the testing done to explore the situation. It would be good to document the symptoms observed. It is also good to document diagnosis, and also remediation. I "repeat" that because "good to document" depends on the purpose of the document. A tool to perform the testing ought not get caught up in diagnosis, I found having it just "log" symptoms much more useful that having it try to "think" about the cause. Remediation is tool dependent, so a "parent" trying to help the "children" needs to judge if it is willing to handhold completely, for preferred DNS implementations, or be fair by not offering the teaching service at all. (Not helpful, but unbiased on tool choice.) PS - There was some other rathole I wanted to step in, but I've forgotten it. ;) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. From Ed.Lewis at neustar.biz Thu May 5 12:14:12 2005 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Thu, 5 May 2005 12:14:12 +0200 Subject: [dns-wg] WG Agenda for RIPE50 In-Reply-To: <19907.1111598125@shaun.rfc1035.com> References: <19907.1111598125@shaun.rfc1035.com> Message-ID: There's an item on the agenda that I'd like to potentially add to... # H. Using In-Bailiwick Nameservers in .ARPA: # Improving Reverse DNS Lookup Performance # Masato Minda, JPRS # # In June 2004, the JP TLD carried out a change in handling of the way glue # records. Although this change was technically correct, some domains # encountered difficulties in name resolution. # # This presentation explains the problem with old BIND implementations and # suggests recommended way to configure nameservers in .ARPA domain. This # configuration of DNS will improve reverse DNS lookup performance. I have seen this presentation in January at a NANOG (or at least an earlier version of it) and commented then that there is some good reason for this, even if it costs the RIRs the need to support glue data. For one - it makes the reverse map lookup path a bit more direct. However, the benefit isn't overwhelming because of short cuts taken when looking up the "slash-8".in-addr.arpa zones. E.g., if you tcpdump the DNS queries from an empty caching server, you might see this when you omit repeated queries, formerr's, etc: dig +norec -x 209.173.57.182 @l.root-servers.net dig +norec chia.arin.net @i.root-servers.net dig +norec chia.arin.net @i.gtld-servers.net The first is the query, with a referral to the 209.in-addr.arpa zone. The second is the attempt to get the address for chia, one of the servers. The third is a query to .net, and you get back a hybrid answer... ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8051 ;; flags: qr; QUERY: 1, ANSWER: 1, AUTHORITY: 8, ADDITIONAL: 8 ;; QUESTION SECTION: ;chia.arin.net. IN A ;; ANSWER SECTION: chia.arin.net. 172800 IN A 192.5.6.32 ;; AUTHORITY SECTION: the rest is a normal referral... This is a good crutch - and is a counter to "in-baliwick" server requirements. This crutch comes at a price though - the A record here is obtained from the host objects registered, not via DNS. (It looks like a cached answer, but it's not really.) That's all good, no "flash point problem." Until we get to DNSSEC though. This answer will be RRSIG-less. I suspect that this might become an issue. Maybe? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. From roy at dnss.ec Thu May 5 12:27:16 2005 From: roy at dnss.ec (Roy Arends) Date: Thu, 5 May 2005 12:27:16 +0200 (CEST) Subject: [dns-wg] WG Agenda for RIPE50 In-Reply-To: References: <19907.1111598125@shaun.rfc1035.com> Message-ID: On Thu, 5 May 2005, Edward Lewis wrote: > There's an item on the agenda that I'd like to potentially add to... > The third is a query to .net, and you get back a hybrid > answer... > > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8051 > ;; flags: qr; QUERY: 1, ANSWER: 1, AUTHORITY: 8, ADDITIONAL: 8 > ;; QUESTION SECTION: > ;chia.arin.net. IN A > ;; ANSWER SECTION: > chia.arin.net. 172800 IN A 192.5.6.32 > ;; AUTHORITY SECTION: > the rest is a normal referral... > > This is a good crutch - and is a counter to "in-baliwick" server > requirements. This crutch comes at a price though - the A record > here is obtained from the host objects registered, not via DNS. (It > looks like a cached answer, but it's not really.) > > That's all good, no "flash point problem." > > Until we get to DNSSEC though. This answer will be RRSIG-less. I > suspect that this might become an issue. Maybe? It will become an issue, unless resolvers understand that referrals with glue in answer section are exactly that: referrals, and not answers. Roy From roy at dnss.ec Thu May 5 12:39:23 2005 From: roy at dnss.ec (Roy Arends) Date: Thu, 5 May 2005 12:39:23 +0200 (CEST) Subject: [dns-wg] WG Agenda for RIPE50 In-Reply-To: References: <19907.1111598125@shaun.rfc1035.com> Message-ID: On Thu, 5 May 2005, Roy Arends wrote: > On Thu, 5 May 2005, Edward Lewis wrote: > > > There's an item on the agenda that I'd like to potentially add to... > > > > > The third is a query to .net, and you get back a hybrid > > answer... > > > > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8051 > > ;; flags: qr; QUERY: 1, ANSWER: 1, AUTHORITY: 8, ADDITIONAL: 8 > > ;; QUESTION SECTION: > > ;chia.arin.net. IN A > > ;; ANSWER SECTION: > > chia.arin.net. 172800 IN A 192.5.6.32 > > ;; AUTHORITY SECTION: > > the rest is a normal referral... > > > > This is a good crutch - and is a counter to "in-baliwick" server > > requirements. This crutch comes at a price though - the A record > > here is obtained from the host objects registered, not via DNS. (It > > looks like a cached answer, but it's not really.) > > > > That's all good, no "flash point problem." > > > > Until we get to DNSSEC though. This answer will be RRSIG-less. I > > suspect that this might become an issue. Maybe? > > It will become an issue, unless resolvers understand that referrals with > glue in answer section are exactly that: referrals, and not answers. Might be a topic for ietf dnsop or dnsext: Convince authoritative name server vendors to put glue where glue belongs: additional section. There is also the problem of combined server-resolver installations, that have out-of-bailiwick glue cached, and respond with that glue in the answer section. Roy From pk at DENIC.DE Thu May 5 14:07:26 2005 From: pk at DENIC.DE (Peter Koch) Date: Thu, 5 May 2005 14:07:26 +0200 Subject: [dns-wg] WG Agenda for RIPE50 In-Reply-To: References: <19907.1111598125@shaun.rfc1035.com> Message-ID: <20050505120726.GA18970@denics7.denic.de> Roy Arends wrote: > Convince authoritative name server vendors to put glue where glue belongs: > additional section. > > There is also the problem of combined server-resolver installations, that > have out-of-bailiwick glue cached, and respond with that glue in the > answer section. if it originates from the cache, it's not glue. Glue is what is maintained in the context of the delegating zone. Apart from that: yes. -Peter From roy at dnss.ec Thu May 5 14:40:43 2005 From: roy at dnss.ec (Roy Arends) Date: Thu, 5 May 2005 14:40:43 +0200 (CEST) Subject: [dns-wg] WG Agenda for RIPE50 In-Reply-To: <20050505120726.GA18970@denics7.denic.de> References: <19907.1111598125@shaun.rfc1035.com> <20050505120726.GA18970@denics7.denic.de> Message-ID: On Thu, 5 May 2005, Peter Koch wrote: > Roy Arends wrote: > > > Convince authoritative name server vendors to put glue where glue belongs: > > additional section. > > > > There is also the problem of combined server-resolver installations, that > > have out-of-bailiwick glue cached, and respond with that glue in the > > answer section. > > if it originates from the cache, it's not glue. Glue is what is maintained > in the context of the delegating zone. Apart from that: yes. concur roy From roy at dnss.ec Thu May 5 17:18:16 2005 From: roy at dnss.ec (Roy Arends) Date: Thu, 5 May 2005 17:18:16 +0200 (CEST) Subject: [dns-wg] WG Agenda for RIPE50 In-Reply-To: References: <19907.1111598125@shaun.rfc1035.com> Message-ID: On Thu, 5 May 2005, Roy Arends wrote: > There is also the problem of combined server-resolver installations, that > have out-of-bailiwick glue cached, and respond with that glue in the > answer section. There is no such thing as in-bailiwick glue or out of bailiwick glue. The term "GLUE RECORDS" is defined in rfc-1033 (yeah, dusted off): If the name server host for a particular domain is itself inside the domain, then a 'glue' record will be needed. A glue record is an A (address) RR that specifies the address of the server. Glue records are only needed in the server delegating the domain, not in the domain itself. in-bailiwick glue is a pleonasm while out-of-bailiwick glue is an oxymoron. Roy From Ed.Lewis at neustar.biz Thu May 5 17:46:57 2005 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Thu, 5 May 2005 17:46:57 +0200 Subject: [dns-wg] WG Agenda for RIPE50 In-Reply-To: References: <19907.1111598125@shaun.rfc1035.com> Message-ID: At 17:18 +0200 5/5/05, Roy Arends wrote: > Before this spins into a debate on the correctness of the answers (I privately label them "hybrid" cache/referrals), I want to make two points: 1) This action may or may not be completely compliant with the protocol but it has been an operational boon. Don't get me wrong - the messages are valid with respect to the protocol. The way in which the data is obtained may not be what is expected, but is fully compliant with the protocol. I.e., the answer comes back with the AA bit off and the RA bit is also off. DNS does not define what that "means" - it could be that the server is recursive, but recursion is not available to the querier. (It could be ACL'd out by IP address, for example.) Defining the answers as "in-baliwick" is hard. The servers in this example are authoritative for .com and .net. To the server, the baliwick is any domain under .com and .net, regardless of the query. OTOH, the only queries that fall into this category are asking for names in .com and .net. I.e., you don't see a .biz name here - for many reasons. Keep in mind that just because the IETF has defined it, doesn't mean it's operationally valid. The IETF tries, but sometimes misses the mark. Without this crutch, no BIND prior to 8.something would have worked (getting lost in reverse map queries) and the number of queries sent would have been much higher. 2) This is another case of DNSSEC exposing corner cases that DNS was able to live with. Like "* NS", until DNSSEC, these cases could exist without heartburn, but when push comes to shove in the "signed by the authorized party" era, we find that these cases exist. ("* DNAME" isn't in this category for other reasons, even in non DNSSEC is causes heartburn. Sorry - that's a different discussion on another list.) I may be painting this scenario in an unfair light calling it a "corner case" but it qualifies because this is "ersatz caching." It works now because as long as the host objects are in line with what's really in DNS, it's okay. Problems don't pop up until the DNS is changed and the registration isn't. This will happen when the zone gets signed. Retrieval of the RRSIG's for all registered host objects is probably not going to happen. I'm sure there is a way "out" of this. For one, without DNSSEC, the answer coming from a non-authoritative server is lower in credibility than an answer from an authoritative one. Perhaps a validator can recognize hybrid answers and realize not to "panic" when it lacks the RRSIG, instead "following" the referral half of the message. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. From pk at DENIC.DE Thu May 5 18:30:23 2005 From: pk at DENIC.DE (Peter Koch) Date: Thu, 5 May 2005 18:30:23 +0200 Subject: [dns-wg] WG Agenda for RIPE50 In-Reply-To: References: <19907.1111598125@shaun.rfc1035.com> Message-ID: <20050505163023.GA22213@denics7.denic.de> Roy Arends wrote: > > There is no such thing as in-bailiwick glue or out of bailiwick glue. > > The term "GLUE RECORDS" is defined in rfc-1033 (yeah, dusted off): That's probably using illegal evidence, 1033 has no formal status. > If the name server host for a particular domain is itself inside the > domain, then a 'glue' record will be needed. A glue record is an A > (address) RR that specifies the address of the server. Glue records > are only needed in the server delegating the domain, not in the > domain itself. > > in-bailiwick glue is a pleonasm while out-of-bailiwick glue is an > oxymoron. There are different glue policies in place. DE is using a strict one (matching your definition above), while COM/NET apply a less strict (in fact IIRC even a combined one). The paragraph cited above is correct, but it doesn't limit glue to that case. But this is all only about differentiating between servers below the delegating or the delegated domain. The presentation is in fact about "trustworthy additional information". But let's wait until tomorrow ... -Peter From jim at rfc1035.com Fri May 6 09:39:25 2005 From: jim at rfc1035.com (Jim Reid) Date: Fri, 06 May 2005 08:39:25 +0100 Subject: [dns-wg] WG Agenda for RIPE50 In-Reply-To: Message from Roy Arends of "Thu, 05 May 2005 17:18:16 +0200." Message-ID: <5975.1115365165@shaun.rfc1035.com> >>>>> "Roy" == Roy Arends writes: Roy> The term "GLUE RECORDS" is defined in rfc-1033 (yeah, dusted Roy> off): Roy> If the name server host for a particular domain is itself Roy> inside the domain, then a 'glue' record will be needed. A Roy> glue record is an A (address) RR that specifies the address Roy> of the server. Glue records are only needed in the server Roy> delegating the domain, not in the domain itself. As well as being illegal evidence -- thanks Peter! -- the last sentence above is ambiguous. It can be interpreted as implying the glue record in the parent means the child doesn't have to have an A (or AAAA) record for the name server. Roy> in-bailiwick glue is a pleonasm while out-of-bailiwick glue Roy> is an oxymoron. The terminology may not be defined clearly. However the concept of out-of-bailiwick glue is something we all understand. From roy at dnss.ec Fri May 6 11:46:46 2005 From: roy at dnss.ec (Roy Arends) Date: Fri, 6 May 2005 11:46:46 +0200 (CEST) Subject: [dns-wg] WG Agenda for RIPE50 In-Reply-To: <5975.1115365165@shaun.rfc1035.com> References: <5975.1115365165@shaun.rfc1035.com> Message-ID: On Fri, 6 May 2005, Jim Reid wrote: > >>>>> "Roy" == Roy Arends writes: > > Roy> The term "GLUE RECORDS" is defined in rfc-1033 (yeah, dusted > Roy> off): > > Roy> If the name server host for a particular domain is itself > Roy> inside the domain, then a 'glue' record will be needed. A > Roy> glue record is an A (address) RR that specifies the address > Roy> of the server. Glue records are only needed in the server > Roy> delegating the domain, not in the domain itself. > > As well as being illegal evidence -- thanks Peter! -- the last > sentence above is ambiguous. It can be interpreted as implying the > glue record in the parent means the child doesn't have to have an > A (or AAAA) record for the name server. I don't think it is illegal evidence, even though it has not an official status. It is referenced by 1034, etc,etc. The address record in the domain itself is not glue. It is authoritative data. > Roy> in-bailiwick glue is a pleonasm while out-of-bailiwick glue > Roy> is an oxymoron. > > The terminology may not be defined clearly. However the concept of > out-of-bailiwick glue is something we all understand. We think we understand, though we need better clarification about the glue concept, so we can agree we understand the same concept. Roy From jim at rfc1035.com Fri May 13 15:50:00 2005 From: jim at rfc1035.com (Jim Reid) Date: Fri, 13 May 2005 14:50:00 +0100 Subject: [dns-wg] IANA TLD delegation issue Message-ID: <5d2ce05b7c73da1a4679b190af4d6603@rfc1035.com> 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 From mansaxel at sunet.se Sat May 14 09:05:26 2005 From: mansaxel at sunet.se (=?ISO-8859-1?Q?M=E5ns_Nilsson?=) Date: Sat, 14 May 2005 09:05:26 +0200 Subject: [dns-wg] IANA TLD delegation issue In-Reply-To: <5d2ce05b7c73da1a4679b190af4d6603@rfc1035.com> References: <5d2ce05b7c73da1a4679b190af4d6603@rfc1035.com> Message-ID: <39F96F4B120FFE103404AC11@E3993D2B0BE66833664712A4> --On fredag 13 maj 2005 14.50 +0100 Jim Reid wrote: > 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. Well written! -- M?ns Nilsson Systems Specialist +46 70 681 7204 KTHNOC MN1334-RIPE -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From jose.a.campos at exxonmobil.com Sat May 14 12:34:23 2005 From: jose.a.campos at exxonmobil.com (jose.a.campos at exxonmobil.com) Date: Sat, 14 May 2005 05:34:23 -0500 Subject: [dns-wg] Jose A Campos is out of the office. Message-ID: I will be out of the office starting 05/09/2005 and will not return until 05/16/2005. For emergencies, please call Network Operations (713-656-1548). From jim at rfc1035.com Sat May 21 19:47:43 2005 From: jim at rfc1035.com (Jim Reid) Date: Sat, 21 May 2005 18:47:43 +0100 Subject: [dns-wg] Fwd: Questions on IANA TLD Operations Message-ID: <117b587c4a5fd9d3e3f19ae44da079f1@rfc1035.com> Here is the response we received from Doug Barton to the questions that we asked. I'm still confused. It's not clear to me what problem has been fixed or if IANA will now permit TLD delegations to include hostnames that have the same IP address as existing hostnames in the root zone. I've asked Doug for clarification: a clear statement whether this is or isn't permitted. I'll keep you informed of developments. Stay tuned.... Begin forwarded message: > From: Doug Barton > Date: May 21, 2005 04:09:03 BST > To: Jim Reid > Cc: Barbara Roseman , iana at iana.org, Daniel > , Mohsen Souissi , Jaap Akkerhuis > , "Olaf M. Kolkman" , Lars-Johan > Liman , Peter Koch , Olivier > Guillard , philippe.lubrano at nic.fr > Subject: Re: Questions on IANA TLD Operations > > Jim, > > Thank you for raising this issue, my response is below. Please let me > know if you intend to forward this to the WG. Otherwise I am happy to > do so. > > In November of 2004 IANA received a request from AFNIC to add new > hostnames > for IP addresses of name servers that already existed in the root zone. > While there were a few examples of this already in the zone, this type > of > request is rare, and produced an unexpected result. ICANN has been > informed that this problem is now permanently fixed. > > Because at the time AFNIC submitted the recent request for > modifications to the RE ccTLD IANA had not yet been informed that the > problem was fixed, we asked them to choose a method of reaching their > operational goals other than adding new instances of the hostnames > that resolve to the same IP address. Because the problem is now fixed, > this will not be necessary in the future. > > I'm sorry that I did not get a chance to discuss these issues with you > in > person at the Stockholm meeting, as you noted I was called home > suddenly for > personal reasons. I do appreciate this opportunity to explain the > issues > involved, and I look forward to discussing it with you further if you > so > desire. > > Kind Regards, > > Doug > > -- > Doug Barton > General Manager, The Internet Assigned Numbers Authority > > > Jim Reid wrote: >> Apologies in advance for the cast of thousands on this message... >> I'm sending this on behalf of the co-chairs of the RIPE DNS Working >> Group in response to a discussion during RIPE50 last week. >> 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 > From jim at rfc1035.com Sat May 21 22:08:04 2005 From: jim at rfc1035.com (Jim Reid) Date: Sat, 21 May 2005 21:08:04 +0100 Subject: [dns-wg] Fwd: Questions on IANA TLD Operations Message-ID: <3d2d5ee7d9c404518a7262e847bd0879@rfc1035.com> Here's the latest response from Doug. He confirms that IANA does permit multiple names for the same IP address for delegations in the root zone. I trust we can now consider this matter closed. Begin forwarded message: > From: Doug Barton > Date: May 21, 2005 20:53:13 BST > To: Jim Reid > Cc: iana at iana.org, Daniel , Mohsen Souissi > , Jaap Akkerhuis , "Olaf M. > Kolkman" , Lars-Johan Liman , > Barbara Roseman , Peter Koch , > Olivier Guillard , philippe.lubrano at nic.fr > Subject: Re: Questions on IANA TLD Operations > > On Sat, 21 May 2005, Jim Reid wrote: > >> On May 21, 2005, at 04:09, Doug Barton wrote: >> >>> Thank you for raising this issue, my response is below. Please let >>> me know if you intend to forward this to the WG. Otherwise I am >>> happy to do so. >> >> Doug, many thanks for the timely reply. It was unfortunate that you >> were unable to be in Stockholm when this issue was raised at the WG. >> >> However I have to say that your reply leaves me as confused as I was >> when we sent the email to yourself and Barbara. Perhaps I've not had >> enough caffeine today to get the neurons firing. Your mail says "the >> problem is now fixed" without clarifying which problem you are >> referring to. One interpretation of your remarks could be that the >> problem with the .fr delegation has been resolved because AFNIC has >> applied the workaround you suggested. That interpretation of course >> leaves the questions we asked unanswered. Could you please give me a >> clear and unequivocal answer to this question: "Are TLDs permitted to >> register a hostname for their delegation when there is another >> hostname in the root zone for the same IP address?" Thanks. > > Yes. I do not know how to make it more unequivocal than that. :) > > I'm sorry that you found my answer confusing. One of the reasons it > took so long to produce (in addition to the fact that until Monday I > am technically still on leave) is that I had several people review it > to make sure that it was clear. I am sensitive to your point that > English is not the first language for many of the RIPE community, and > I appreciate your asking for clarification. > >> As far as forwarding your reply to the WG list is concerned, I think >> this should be my responsibility. > > That's totally appropriate, and I see that you have already done that, > thank you. My only concern is that given the fact that this issue was > raised in the WG, I want to be sure that they are informed of the > response. > > Regards, > > Doug > > -- > Doug Barton > General Manager, The Internet Assigned Numbers Authority > From jim at rfc1035.com Tue May 24 12:47:04 2005 From: jim at rfc1035.com (Jim Reid) Date: Tue, 24 May 2005 11:47:04 +0100 Subject: [dns-wg] Followup to IANA TLD delegation problem Message-ID: <26836.1116931624@shaun.rfc1035.com> You'll all have seen the response from Doug Barton confirming that the technical problem has been fixed. It is now permitted to have multiple names for the same IP address in a TLD delegation from the root. That particular aspect of the discussion should be considered closed IMO because the problem has been resolved. However, there are some other things that I'd like the WG to consider and discuss. These concern the process and transparency issues that have been highlighted by this problem. I wonder if the WG would like to pursue these? In particular, I'd like the WG to consider if we should pursue answers to the following questions: [1] What was the nature of the technical problem that prevented multiple names in for an IP address and how was it resolved? [2] Why was there no announcement that this problem existed? [3] Are safeguards now in place to prevent this sort of problem recurring? [4] What procedures does IANA (or ICANN?) have to make sure that changes to the TLD delegation process or problems with that process are properly communicated to its stakeholders? [5] Were those procedures followed for this incident? If not, why not? If anyone here has more questions about this incident, please post them. If there's consensus in the WG that this matter needs further action, then we need to decide what the next steps, if any, should be. I'd welcome a discussion and comments. It's now over to you, the list members.... From Ed.Lewis at neustar.biz Thu May 26 16:28:38 2005 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Thu, 26 May 2005 10:28:38 -0400 Subject: [dns-wg] Followup to IANA TLD delegation problem In-Reply-To: <26836.1116931624@shaun.rfc1035.com> References: <26836.1116931624@shaun.rfc1035.com> Message-ID: At 11:47 +0100 5/24/05, Jim Reid wrote: >I wonder if the WG would like to pursue these? I don't think this would be energy well spent. Has there been a tangible loss (or unrecoverable [cost])? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. From niall.oreilly at ucd.ie Thu May 26 23:45:14 2005 From: niall.oreilly at ucd.ie (Niall O'Reilly) Date: Thu, 26 May 2005 22:45:14 +0100 Subject: [dns-wg] Followup to IANA TLD delegation problem In-Reply-To: <26836.1116931624@shaun.rfc1035.com> References: <26836.1116931624@shaun.rfc1035.com> Message-ID: <3173d46ba23eb6b853155657ace091f4@ucd.ie> On 24 May 2005, at 11:47, Jim Reid wrote: > If there's consensus in the WG that this matter needs further > action, Yes. It's not good enough to declare the problem fixed and just brush the procedural issues under the carpet. /Niall From brettcarr at ripe.net Fri May 27 10:25:18 2005 From: brettcarr at ripe.net (Brett Carr) Date: Fri, 27 May 2005 10:25:18 +0200 (CEST) Subject: [dns-wg] Followup to IANA TLD delegation problem In-Reply-To: References: <26836.1116931624@shaun.rfc1035.com> Message-ID: On Thu, 26 May 2005, Edward Lewis wrote: > At 11:47 +0100 5/24/05, Jim Reid wrote: > > >I wonder if the WG would like to pursue these? > > I don't think this would be energy well spent. Has there been a > tangible loss (or unrecoverable [cost])? > Yes but surely we should be concerned that they are using acceptable procedures to ensure that more serious problems/losses will not occur in the future. Brett -- Brett Carr Ripe Network Coordination Centre System Engineer -- Operations Group Singel 258 Amsterdam NL From jay at nominet.org.uk Fri May 27 10:27:21 2005 From: jay at nominet.org.uk (Jay Daley) Date: Fri, 27 May 2005 09:27:21 +0100 Subject: [dns-wg] Followup to IANA TLD delegation problem In-Reply-To: <3173d46ba23eb6b853155657ace091f4@ucd.ie> Message-ID: Jim dns-wg-admin at ripe.net wrote on 26/05/2005 22:45:14: > > On 24 May 2005, at 11:47, Jim Reid wrote: > > > If there's consensus in the WG that this matter needs further > > action, > > Yes. It's not good enough to declare the problem fixed and just > brush the procedural issues under the carpet. I agree. Unfortunately there is the possibility that this an indicator of serious underlying problems in the way IANA operates, and so it needs to be pursued. Jay From doug.barton at icann.org Sat May 28 00:18:53 2005 From: doug.barton at icann.org (Doug Barton) Date: Fri, 27 May 2005 15:18:53 -0700 Subject: [dns-wg] Followup to IANA TLD delegation problem In-Reply-To: <26836.1116931624@shaun.rfc1035.com> References: <26836.1116931624@shaun.rfc1035.com> Message-ID: <42979CCD.5000602@icann.org> Jim, We're happy to provide answers to these questions. Given that Monday is a holiday in the US, may I suggest that we will provide answers to the questions listed on Tuesday 31 May unless you or the WG indicate that more time is needed for you to formulate the list? Regards, Doug -- Doug Barton General Manager, The Internet Assigned Numbers Authority Jim Reid wrote: > You'll all have seen the response from Doug Barton confirming that the > technical problem has been fixed. It is now permitted to have multiple > names for the same IP address in a TLD delegation from the root. That > particular aspect of the discussion should be considered closed IMO > because the problem has been resolved. However, there are some other > things that I'd like the WG to consider and discuss. These concern the > process and transparency issues that have been highlighted by this > problem. > > I wonder if the WG would like to pursue these? > > In particular, I'd like the WG to consider if we should pursue answers > to the following questions: > > [1] What was the nature of the technical problem that prevented > multiple names in for an IP address and how was it resolved? > > [2] Why was there no announcement that this problem existed? > > [3] Are safeguards now in place to prevent this sort of problem > recurring? > > [4] What procedures does IANA (or ICANN?) have to make sure that > changes to the TLD delegation process or problems with that process > are properly communicated to its stakeholders? > > [5] Were those procedures followed for this incident? If not, why not? > > If anyone here has more questions about this incident, please post > them. If there's consensus in the WG that this matter needs further > action, then we need to decide what the next steps, if any, should be. > I'd welcome a discussion and comments. > > It's now over to you, the list members.... From Olivier.Guillard at nic.fr Mon May 30 10:51:02 2005 From: Olivier.Guillard at nic.fr (Olivier Guillard / AFNIC) Date: Mon, 30 May 2005 10:51:02 +0200 Subject: [dns-wg] Followup to IANA TLD delegation problem In-Reply-To: <26836.1116931624@shaun.rfc1035.com> References: <26836.1116931624@shaun.rfc1035.com> Message-ID: <20050530085102.GA20150@james.nic.fr> Dear Jim, as one of those that was looking for a path to operationaly circumvent this new IANA policy, may I thank the dns-wg that have clearly stated with others that "there is no technical reason in the DNS protocols preventing this practice (aka: "use different [NS] names for the same address"). The questions you raise now are very valid : > [1] What was the nature of the technical problem that prevented > multiple names in for an IP address and how was it resolved? > > [2] Why was there no announcement that this problem existed? > > [3] Are safeguards now in place to prevent this sort of problem > recurring? > > [4] What procedures does IANA (or ICANN?) have to make sure that > changes to the TLD delegation process or problems with that process > are properly communicated to its stakeholders? > > [5] Were those procedures followed for this incident? If not, why not? BTW, above the specific multinamming issue, they are now among the core ones that need to be taken seriously by the DNS community in my view. I have looked in the dns-wg charter : http://www.ripe.net/ripe/wg/dns/index.html It is not perfectly clear for me what kind of contribution you are waiting for to help moving forward, and the kind of actions you see as conceivable to be undertaken by the dns-wg ? Thanks, Olivier le mardi 24 mai ? 11 H 47 , Jim Reid a ecrit : > You'll all have seen the response from Doug Barton confirming that the > technical problem has been fixed. It is now permitted to have multiple > names for the same IP address in a TLD delegation from the root. That > particular aspect of the discussion should be considered closed IMO > because the problem has been resolved. However, there are some other > things that I'd like the WG to consider and discuss. These concern the > process and transparency issues that have been highlighted by this > problem. > > I wonder if the WG would like to pursue these? > > In particular, I'd like the WG to consider if we should pursue answers > to the following questions: > > [1] What was the nature of the technical problem that prevented > multiple names in for an IP address and how was it resolved? > > [2] Why was there no announcement that this problem existed? > > [3] Are safeguards now in place to prevent this sort of problem > recurring? > > [4] What procedures does IANA (or ICANN?) have to make sure that > changes to the TLD delegation process or problems with that process > are properly communicated to its stakeholders? > > [5] Were those procedures followed for this incident? If not, why not? > > If anyone here has more questions about this incident, please post > them. If there's consensus in the WG that this matter needs further > action, then we need to decide what the next steps, if any, should be. > I'd welcome a discussion and comments. > > It's now over to you, the list members.... -- Olivier From schneider at switch.ch Mon May 30 11:54:55 2005 From: schneider at switch.ch (Marcel Schneider) Date: Mon, 30 May 2005 11:54:55 +0200 Subject: [dns-wg] Followup to IANA TLD delegation problem In-Reply-To: Message from Olivier Guillard / AFNIC of "Mon, 30 May 2005 10:51:02 +0200." <20050530085102.GA20150@james.nic.fr> References: <20050530085102.GA20150@james.nic.fr> <26836.1116931624@shaun.rfc1035.com> Message-ID: <24332.1117446895@switch.ch> On Monday, 30 May 2005, Olivier Guillard / AFNIC writes: Dear all > as one of those that was looking for a path to operationaly > circumvent this new IANA policy, may I thank the dns-wg that > have clearly stated with others that "there is no technical > reason in the DNS protocols preventing this practice (aka: > "use different [NS] names for the same address"). To support Olivier's point: we also were relieved to hear from Doug Barton that no such policy was introduced. My question to Jim and maybe Jaap is: how did you became aware that ICANN/ IANA would or already has introduced such measures ? Unfortunately we at SWITCH do not hear the grass growing and were catched by surprise. It is important that we all fully understand the issue to learn from it. Marcel > The questions you raise now are very valid : >> [1] What was the nature of the technical problem that prevented >> multiple names in for an IP address and how was it resolved? >> >> [2] Why was there no announcement that this problem existed? >> >> [3] Are safeguards now in place to prevent this sort of problem >> recurring? >> >> [4] What procedures does IANA (or ICANN?) have to make sure that >> changes to the TLD delegation process or problems with that process >> are properly communicated to its stakeholders? >> >> [5] Were those procedures followed for this incident? If not, why not? > BTW, above the specific multinamming issue, they are now among the > core ones that need to be taken seriously by the DNS community in > my view. > I have looked in the dns-wg charter : > http://www.ripe.net/ripe/wg/dns/index.html > It is not perfectly clear for me what kind of contribution you are > waiting for to help moving forward, and the kind of actions you see > as conceivable to be undertaken by the dns-wg ? > Thanks, > Olivier > le mardi 24 mai ? 11 H 47 , Jim Reid a ecrit : >> You'll all have seen the response from Doug Barton confirming that the >> technical problem has been fixed. It is now permitted to have multiple >> names for the same IP address in a TLD delegation from the root. That >> particular aspect of the discussion should be considered closed IMO >> because the problem has been resolved. However, there are some other >> things that I'd like the WG to consider and discuss. These concern the >> process and transparency issues that have been highlighted by this >> problem. >> >> I wonder if the WG would like to pursue these? >> >> In particular, I'd like the WG to consider if we should pursue answers >> to the following questions: >> >> [1] What was the nature of the technical problem that prevented >> multiple names in for an IP address and how was it resolved? >> >> [2] Why was there no announcement that this problem existed? >> >> [3] Are safeguards now in place to prevent this sort of problem >> recurring? >> >> [4] What procedures does IANA (or ICANN?) have to make sure that >> changes to the TLD delegation process or problems with that process >> are properly communicated to its stakeholders? >> >> [5] Were those procedures followed for this incident? If not, why not? >> >> If anyone here has more questions about this incident, please post >> them. If there's consensus in the WG that this matter needs further >> action, then we need to decide what the next steps, if any, should be. >> I'd welcome a discussion and comments. >> >> It's now over to you, the list members.... > -- > Olivier From jim at rfc1035.com Mon May 30 12:18:46 2005 From: jim at rfc1035.com (Jim Reid) Date: Mon, 30 May 2005 11:18:46 +0100 Subject: [dns-wg] Followup to IANA TLD delegation problem In-Reply-To: Message from Olivier Guillard / AFNIC of "Mon, 30 May 2005 10:51:02 +0200." <20050530085102.GA20150@james.nic.fr> Message-ID: <29011.1117448326@shaun.rfc1035.com> >>>>> "Olivier" == Olivier Guillard / AFNIC writes: Olivier> It is not perfectly clear for me what kind of Olivier> contribution you are waiting for to help moving forward, Olivier> and the kind of actions you see as conceivable to be Olivier> undertaken by the dns-wg ? My apologies for any confusion Olivier. My earlier mail was intended to provoke a discussion on the list. This discussion would hopefully allow the WG to reach consensus on: (a) if there were outstanding issues along the lines of the questions I posed; and (b) what the WG felt the next steps to resolve those issues could be. The response so far seems to be that further clarification is required but it's not critical. So if that's the consensus of the WG, the promised response from Doug could well be enough to close this issue. It's really up to the WG to decide what happens. If nobody cares, we just let things drop. If it's felt to be *really* important, then the WG could make another formal communication to ICANN/IANA. If the consensus is somewhere in between these two extremes, it may well be enough to wait for Doug's reply to my questions. As WG chair, I'd just like to find out what the WG's position is. From jefsey at jefsey.com Tue May 31 02:21:12 2005 From: jefsey at jefsey.com (JFC (Jefsey) Morfin) Date: Tue, 31 May 2005 02:21:12 +0200 Subject: [dns-wg] Followup to IANA TLD delegation problem In-Reply-To: <29011.1117448326@shaun.rfc1035.com> References: <29011.1117448326@shaun.rfc1035.com> Message-ID: <6.2.1.2.2.20050531021505.03dff7c0@mail.jefsey.com> Jim, what we might also want to know is the complete time table of the problem. And how the initial information came. As I maintain a daily report on the top zone, I am interested to know if this kind a problem can be watched for and how. thank you. jfc At 12:18 30/05/2005, Jim Reid wrote: > >>>>> "Olivier" == Olivier Guillard / AFNIC writes: > > Olivier> It is not perfectly clear for me what kind of > Olivier> contribution you are waiting for to help moving forward, > Olivier> and the kind of actions you see as conceivable to be > Olivier> undertaken by the dns-wg ? > >My apologies for any confusion Olivier. My earlier mail was intended >to provoke a discussion on the list. This discussion would hopefully >allow the WG to reach consensus on: (a) if there were outstanding >issues along the lines of the questions I posed; and (b) what the WG >felt the next steps to resolve those issues could be. The response so >far seems to be that further clarification is required but it's not >critical. So if that's the consensus of the WG, the promised response >from Doug could well be enough to close this issue. > >It's really up to the WG to decide what happens. If nobody cares, we >just let things drop. If it's felt to be *really* important, then the >WG could make another formal communication to ICANN/IANA. If the >consensus is somewhere in between these two extremes, it may well be >enough to wait for Doug's reply to my questions. As WG chair, I'd just >like to find out what the WG's position is.