- dns-wg - mailman.ripe.net

IANA TLD delegation issue
by Jim Reid 14 May '05

14 May '05

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

2 1

Re: [dns-wg] WG Agenda for RIPE50
by Jim Reid 06 May '05

06 May '05

>>>>> "Roy" == Roy Arends <roy(a)dnss.ec> 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.

2 1

WG Agenda for RIPE50
by Jim Reid 05 May '05

05 May '05

The WG Agenda for RIPE50 is now being compiled. Please send details of any suggestions or contributions to the WG chairs: dns-wg-chair(a)ripe.net. Thanks. Note that a new structure for RIPE meetings will be tried in Stockholm. Reports from other meetings -- eg IETF, CENTR -- are supposed to now go in the extended plenary at the start of the week. Detailed technical and policy discussions are intended for the WG sessions at the end of the week. At this time it's too early to say when the WG will meet and for how long. The meeting plan won't be finalised until there's a better idea of what's on the agendas of each WG. So it will help us to help you by letting us know what should be on the WG agenda in Stockholm.

4 8

Action Item 48.1: Lame Delegations -- first draft
by Peter Koch 05 May '05

05 May '05

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

2 1

Final version of the DNS Migration document
by fgarcia＠eurocomercial.es 02 May '05

02 May '05

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 servers 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 organisations 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 youre 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

1 0

Comparison of Delegation Checker (v 2.0 and v 2.1)
by Olaf M. Kolkman 20 Apr '05

20 Apr '05

Dear Colleagues, This message is about the DNS delegation checks performed when you update DOMAIN objects by requesting the updating of a delegation in the reverse address trees. We have recently updated the web interface to use version 2.1 of the back-end library (Net::DelCheck) while the whois database still uses version 2.0. We would like to ask the DNS Working Group to provide feedback on the version that is now available through the web interface. After considering the feedback, we plan to install the module for use with the whois database. We plan to do this after RIPE 50 (May 2 - 6) as part of a regular whois database upgrade. You can find the delegation checker web interface at: http://www.ripe.net/cgi-bin/delcheck/delcheck2.cgi You can find a list of the error codes returned by version 2.1 of the delegation checker at: http://www.ripe.net/rs/reverse/delcheck/delchecker_descr.html Detailed explanations of the most important differences between the tests that are currently running on the whois database (v 2.0) and those available through the web interface (v 2.1) can be found at: http://www.ripe.net/rs/reverse/changes.html This message relates to an earlier message to this list [1] and action item 48.2 [2]. Regards, Olaf M. Kolkman RIPE NCC [1] http://www.ripe.net/ripe/maillists/archives/dns-wg/2004/msg00172.html [2] http://www.ripe.net/ripe/wg/dns/dns-actions.html

1 0

Re: [dns-wg] Changes to RIPE DNS Infrastructure
by Jim Reid 18 Apr '05

18 Apr '05

Thanks for this announcement. However I'm surprised and disappointed that the NCC didn't discuss the reorganisation with the DNS WG. Where will the ENUM zones that are/were on ns.ripe.net live once these changes have been done?

3 2

Changes to RIPE DNS Infrastructure
by RIPE NCC Operations 15 Apr '05

15 Apr '05

Apologies for duplicate messages Dear Colleagues As part of our ongoing preparations for DNSSEC deployment., we have recently made some changes to the RIPE NCC DNS Server infrastructure. Our main DNS server (ns.ripe.net) held a significant amount of primary in-addr.arpa zones and secondary copies of many zones on behalf of other parties. We have split this into several servers as follows. · ns.ripe.net This contains no primary, but many secondary zones. · ns-pri.ripe.net This contains all zones for which RIPE is primary. · ns-[CountryCode].ripe.net This contains all Country Code Top level Domain (CCTLD) zones for which RIPE is secondary. · ns-sec.ripe.net We will deploy this server soon, it currently contains no zones. We are working towards the following: · ns.ripe.net - This will contain /16 IPv4 reverse and /32 IPv6 secondary reverse zones. · ns-pri.ripe.net - This will contain all zones for which RIPE is primary. · ns-[CountryCode].ripe.net - This will contain ccTLD zones for which RIPE is secondary. · ns-sec.ripe.net - This will contain all zones for which RIPE is secondary (excluding those on ns andns-tld). We will soon contact users to arrange moving zones from ns to ns-sec. This information was correct on 12 April 2005. Regards Brett Carr System Engineer RIPE NCC

1 0

(Open) DNS WG Action Items
by Peter Koch 13 Apr '05

13 Apr '05

Dear All, the list of action items at <http://www.ripe.net/ripe/wg/dns/dns-actions.html> has been updated. As agreed upon at RIPE 49, item 48.3 (pointer to the list of reverse delegation checks) is marked "done", since there was no discussion after Olaf had sent the information. As always, the topic may be subject to discussion again in the future should anyone feel the need and propose changes. During the WG meeting in Stockholm there will be presentations and/or progress reports on the remaining items. Please review the list and send questions and contributions to the identified action item owner or to this list. -Peter

1 0

ETSI ENUM Plugtest Announcement
by Jim Reid 08 Apr '05

08 Apr '05

I'm forwarding the announcement below on behalf of the ETSI Plugtest Secretariat. Any questions about the event should be sent to the address below. Apologies to those of you who've already seen this in the ENUM WG or IETF mailing lists. Dear All, We are pleased to invite you to the ENUM interoperability event, 30th May to 3rd June 2005 at ETSI Headquarters, Sophia Antipolis, France. The emerging technology of ENUM is attracting a lot of interest. By mapping telephone numbers to domain names, and from those to URLs, ENUM will be a key driver for the increasing convergence between the internet and telephony worlds. The ETSI ENUM Plugtests event will provide a vendor-neutral setting for equipment manufacturers, operators, ISPs, registries, software companies and system integrators to carry out controlled interoperability and conformance testing. It is a chance to discover ENUM system behaviour with misconfigured clients, servers, and intermediaries, so that they can explore the symptoms of such problems before their customers. For further details and to register, please visit our web site at the following URL: http://www.etsi.org/plugtests/ENUM.htm, the registration deadline is 16th May 2005. Please, show your interest by registering as soon as possible, but payment is not due before 23rd May 2005. Upon registration, you will be provided with ETSI's preferential rates for hotels and car rental. This invitation is open to anyone who may be interested so please feel free to forward it. To promote, boost or expand your image and products a wide range of sponsorship opportunities are available at: http://www.etsi.org/plugtests/sponsorus.htm We are looking forward to welcoming you in the South of France. Best regards, ETSI Plugtests TM Service Email: plugtests(a)etsi.org

1 0