*** DNSmigration-ripe-dns.txt Mon Jun 9 13:55:21 2008 --- DNSmigration-ripe-dns-ms-20080609.txt Mon Jun 9 14:24:21 2008 *************** *** 27,32 **** --- 27,36 ---- depend on DNS service. This document is offers a step by step guide to system and network + ^^^^^^^^^^^^^^^^^^ + + ==> document offers + administrators, so they can have a problem free migration with full continuity of all services. *************** *** 48,55 **** The simplest form of name server migration is to move from one slave (secondary) server to another. In this case, the main effort is co-ordinating the reconfiguration of the name servers. For this ! example a new slave name server, ns1.example.com, is added for the ! example.com zone. 2.1 Make new server authoritative for the zone --- 52,62 ---- The simplest form of name server migration is to move from one slave (secondary) server to another. In this case, the main effort is co-ordinating the reconfiguration of the name servers. For this ! example a new slave name server, ns1.example.com, is added for the example.com zone. ! ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ! ! ==> rather "is going to replace slave.example.com" ! 2.1 Make new server authoritative for the zone *************** *** 102,108 **** --- 109,122 ---- example.com, this should be verified with a DNS query utility such as dig: % dig @10.9.8.7 example.com soa +norecurse + ^^^^^^^^ + + ==> 10.40.5.2 ? Which server is quried and which server is responding? + Update text below accordingly... + ; <<>> DiG 9.4.2 <<>> @10.40.5.2 www.example.com + ^^^^^^^^^ + ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26413 *************** *** 124,129 **** --- 138,144 ---- ;; Query time: 4 msec ;; SERVER: 10.9.8.7#53(10.40.5.2) + ^^^^^^^^ ^^^^^^^^^ ;; WHEN: Sun Mar 27 21:47:15 2007 ;; MSG SIZE rcvd: 131 *************** *** 137,142 **** --- 152,161 ---- "aa" entry in the flags header shown in the above output from dig. The +norecurse option is used to clear the RD bit (Recursion Denied) + ^^^^^^ + + ==> Desired + on the query. This shouldn't be necessary, especially when querying up-to-date name servers. However some DNS implementations such as BIND8 sometimes erroneously set the AA bit on answers. This may arise *************** *** 148,153 **** --- 167,176 ---- with authoritative data even when it is not. Querying the new server with the RD bit cleared should ensure that the AA bit is only set on responses from servers that geunuinely are authoritative. + ^^^^^^^^^^^^^^ + + ==> are genuinely + If possible, the next check would be to query the name name server from different locations on the network. This could identify any *************** *** 184,189 **** --- 207,215 ---- slave.example.com. IN A 10.11.12.13 After the update, the NS and glue records would look like: + ^^^^ + + ==> it is not "glue", it's in-zone data ! instead of "glue", rather "A/AAA" example.com. IN NS master.example.com. example.com. IN NS slave.example.com. *************** *** 210,217 **** zone. The logs should also indicate that it has sent out NOTIFY messages to the slave servers and that those slave servers have picked up the new version of the zone with a zone transfer. Ultra-cautious ! DNS administrators will use dig at this point to query the master ! server to ensure that the correct data is now being served: % dig @10.1.2.3 example.com ns --- 236,250 ---- zone. The logs should also indicate that it has sent out NOTIFY messages to the slave servers and that those slave servers have picked up the new version of the zone with a zone transfer. Ultra-cautious ! DNS administrators will use dig at this point to query the master server ! ^^^^^^^^^^^^^ ! ! ==> master and slave servers ! ! to ensure that the correct data is now being served: ! ^^ ! ! ==> "are" ? % dig @10.1.2.3 example.com ns *************** *** 271,278 **** --- 304,318 ---- to some web page and select the option that allows delegation information to be updated. At this point the name of the new server, ns1.example.com, is added. Its IP address will have to be added as a + ^^^^^^^ glue record too. The .com zone needs to advertise the IP address of + ^^^^^^ ns1.example.com even though this under the example.com zone cut. + ^^+is + + ==> Comment: if ns1.example.com. has got an IPv6 address, update the + paragraph above accordingly. + After the update has been entered into the registry database, the new DNS data get added to the parent zone and propagated to its name *************** *** 283,288 **** --- 323,331 ---- delays when moving name servers for a zone. 2.4 Delete the old slave server + ^^^^^^^^^^^^^^^^^^^^^^^^^^^ + + ==> I would suggest to rename this section as: "Remove the old slave server from the name servers list" Once the parent zone has been updated and the new delegation information propagated to its name servers, the old name server can be *************** *** 305,313 **** which points at the old IP address of the now long gone name server. 2.5 Switch off the old name server The final step of the process is to switch off the old name server or ! reconfigure it to stop serving the example.com zone. This should not be done immediately. First of all, other name servers may still be cacheing the old NS and address records for slave.example.com. These may not expire from the caches for some time: the TTL values in either --- 348,377 ---- which points at the old IP address of the now long gone name server. 2.5 Switch off the old name server + ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + + ==> Would suggest to rename this section as: "Stop serving the DNS zone on the old slave server" The final step of the process is to switch off the old name server or ! ^^^^^^^^^^^^^^^^ ! reconfigure it to stop serving the example.com zone. ! ! ------------------------------------------------------------------------ ! ==> Generally speaking, the real action is just "reconfiguring the old ! slave to stop serving the zone". Any further action (such as switching ! off the server) is specific to some contexts (for example, if the ! slave was serving only that zone... and not being used as a recurisve ! name server... And yes, even if such recursive functionality is ! discouraged on an authoritative nameserver, it is not forbidden). ! ! So I would rather prefer rewriting the sentence above as: ! ! "The final step of the process to reconfigure the old sevrer to stop ! serving the example.com zone. The server may even be switched off if ! it does not serve othe DNS zones." ! ------------------------------------------------------------------------ ! ! This should not be done immediately. First of all, other name servers may still be cacheing the old NS and address records for slave.example.com. These may not expire from the caches for some time: the TTL values in either *************** *** 315,327 **** --- 379,397 ---- It is possible of course to reduce these TTLs so that the old server can be switched off sooner. However this will require further changes + ^^^^^^^^^^^^ to the zone and its parent delegation: for instance to reduce the TTL for the NS and any address records for the old name server. This introduces extra steps into the migration process and may not be worth the effort. In the final analysis, the old name server shouldn't be switched off after the migration for at least the TTL value for the + ^^^^^^^^^^^^ server that may have been cached anywhere. + + ==> Same remarks as to "switch off" vs "stop serving the zone" + + Even after a reasonable transition period of a few days, it is always possible for the old name server to still receive queries for example.com. The most likely cause of this are forwarding name servers *************** *** 368,373 **** --- 438,447 ---- the new server to the zone's NS RRset. Further checks can then be made to ensure the server is properly handling queries from other name servers on the network. If anything goes wrong, the NS record can be + ^^^^^^^ + + ==> and clients... + removed. Everything then continues as normal on the existing DNS infrastructure for the zone. Once the new server is handling queries satisfactorily, the delegation information in the parent zone is *************** *** 382,388 **** --- 456,467 ---- its named.conf file once it is considered safe for the slave server to no longer serve that zone. Another approach might be to switch off the slave server, provided of course it is not serving other zones or + ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ being queried by stub resolvers. + ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + + ==> This remark is important, that's why I proposed to insert it + earlier (above) in the text. Although this procedure could be carried out in parallel whenever several slave servers have to be changed, this is probably unwise. It *************** *** 409,414 **** --- 488,497 ---- answering authoritatively for example.com and that it has the same data that is found on the existing master server for the zone. This cannot be one by transferring the zone from both servers and comparing + ^^^ + + ==> done + the zone files because there is no guarantee the two files will be identical. The files should of course have the same DNS data but there is no DNS protocol requirement for that data to be presented in a *************** *** 423,428 **** --- 506,514 ---- correctly and authoritatively for example.com. Zone transfers and EDNS0 queries should be used to ensure that there are no connectivity problems or access control lists which prevent the new server being + ^^^^^^ + ==> "from being"? + used. The checks illustrated in Section 2.2 can be applied here. Once the new server is running correctly, there is a potential *************** *** 522,529 **** With the slave servers now using the new master server, the zone file will probably have to be updated. If the zone's master server has been renamed, that should be shown in the SOA record's MNAME field. The ! zone's NS RRset may have to be updated too and any "glue" for the new ! master server added. In the example used for this document, the new master server retains the same name, master.example.com, but gets renumbered to a new IP --- 608,625 ---- With the slave servers now using the new master server, the zone file will probably have to be updated. If the zone's master server has been renamed, that should be shown in the SOA record's MNAME field. The ! zone's NS RRset may have to be updated too and any "glue" for the new master server added. ! ^^^^^ ! ------------------------------------------------------------------------ ! ==> once again, it is not "glue", it is in-zone data! If the new ! master was already published in the DNS zone, its IP address(es) will ! remain unchanged. Otherwise, (an) A/AAAA entr{y,ies} will be added. ! ! ! OTOH, I think you should mention as early as in the paragraph above, ! the "hidden master option", in which case, nothing would be updated in ! the SOA record. ! ------------------------------------------------------------------------ In the example used for this document, the new master server retains the same name, master.example.com, but gets renumbered to a new IP *************** *** 550,555 **** --- 646,658 ---- sure that the new zone propagates to the zone's slave servers. Stealth master servers are commonly used. These are master servers + ^^^^^^^ + + ==> AFAIK, it's the term "Hidden" which is rather used with + masters. For slaves, it is indeed "stealth" which is used. + see: http://www.oreillynet.com/pub/a/network/excerpt/dnsbindcook_ch07/ (search for "stealth") + + that are not listed in the zone's NS RRset or SOA record's MNAME field or in any parent zone's delegation information. This means the location of the master name server is not readily disclosed in the *************** *** 557,572 **** of that server is only known to the authoritative slave servers for the zone and any utilities that are permitted to send dynamic updates to the server. If a stealth master configuration is in place, there will be no need to update the zone's NS RRset or SOA MNAME field. 3.5 Update the delegation If the master server was part of the delegation information in the parent zone, that zone will need to be updated too. The name and ! address of the new master server will need to be in the parent ! zone. An outline of the procedure to be followed for updating the parent zone is given in Section 2.3.2. There is no need to update the delegation if a stealth master configuration is used: the name and address of the master server will not be in the parent zone and do not need to be added to it. --- 660,686 ---- of that server is only known to the authoritative slave servers for the zone and any utilities that are permitted to send dynamic updates to the server. If a stealth master configuration is in place, there + ^^^^^^^ + + ==> hidden + will be no need to update the zone's NS RRset or SOA MNAME field. 3.5 Update the delegation If the master server was part of the delegation information in the parent zone, that zone will need to be updated too. The name and ! address of the new master server will need to be in the parent zone. ! ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ! ==> Only in case of "glue" and that's not the general case. ! ! An outline of the procedure to be followed for updating the parent zone is given in Section 2.3.2. There is no need to update the delegation if a stealth master configuration is used: the name and + ^^^^^^^ + + ==> hidden + address of the master server will not be in the parent zone and do not need to be added to it. *************** *** 578,583 **** --- 692,701 ---- Clients which issue dynamic updates -- for example a DHCP server -- may need to be reconfigured to use the master server's new IP address. + ^^^^^^^^ + + ==> addresse(s). + However they may be able to find the new location of the master server from the MNAME field in the zone's SOA record. Dynamic update tools like nsupdate will do this automatically. *************** *** 665,671 **** --- 783,793 ---- modified, the zone's SOA record serial number should be updated according to local convention. In the example below, the updated MX and A records now have a TTL of 5 minutes. Not that no other data for + ^^^ + ==> Note + these records is changed + ^^are? example.com. 300 MX 10 oldbox.example.com. ... *************** *** 676,684 **** --- 798,812 ---- for example.com will only be cached for 5 minutes unless they'd already been cached from an earlier lookup. This means that there will probably be more DNS queries for example.com's MX records because this + ^^ese? + data does not get cached for as long as it used to. However within 25 + ^^^^do? ^^they? + hours of this zone update, no name server should be caching these MX records for longer than 5 minutes. Any data that was cached prior to + ^^^were? + the change should have expired from name server caches by then. This now means there is a 5 minute window for changing the mail server *************** *** 740,748 **** --- 868,883 ---- As with the forward zone, the reverse zone should be updated and propagated to its slave servers no later than 1 expire interval + the + ^^^^^^ + ==> refresh! + PTR TTL value before the new IP address is used. The SOA record for 16.172.in-addr.arpa is not shown here, but it can be assumed that its expire interval is 8 hours and the PTR record previously had a TTL of + ^^^^^^ + + ==> refresh + 1 hour. [There is no requirement for SOA timer values and TTLs in reverse zones to be identical to forward zones or vice versa.] *************** *** 801,806 **** --- 936,943 ---- have. If there are any delays or errors happen during the DNS change, the + ^ing + resulting problems may be severe. These changes of course tend to take place at weekends or other quiet periods when key technical staff may not be available. Minimising the number of parties in a given change