|I l@ve RuBoard|
2.17 Moving a Host
At least one TTL before the move, reduce the TTL on the host's A record and PTR record to a low number, like 60 seconds. For example, say you're planning on moving the host z.foo.example. If its current A record looks like this:
z.foo.example. 86400 IN A 192.168.0.254
Reduce the TTL at least a day (86,400 seconds) ahead of time, like this:
z.foo.example. 60 IN A 192.168.0.254
254.0.168.192.in-addr.arpa. 60 IN PTR z.foo.example.
Then, after you've moved the host, change the A record to reflect the host's new address and restore the TTL:
z.foo.example. 86400 IN A 10.0.0.254
Delete the old PTR record and add one (to the appropriate zone data file!) for the new address:
254.0.0.10.in-addr.arpa. 86400 IN PTR z.foo.example.
You need to reduce the TTL on the old records ahead of time to keep name servers from caching them just before the move. If you left the TTL alone, a remote name server could cache the old address just before you made the change, and it would take some time for that record to time out. If you don't use NOTIFY, you should also add in the refresh time of the zones the records are in, since it could take that long for the lower TTL records to make it out to all of your slaves.
This technique applies to more than just A and PTR records, of course. You could just as easily use it to change MX records or any other record type. If it's a name server you're moving, however, or you need to change your zone's NS records, see Recipes Section 6.7 and Section 6.8.
Notice that the new PTR record may well belong in a different zone data file than the old one.
2.17.4 See Also
Section 2.10, for an explanation how to reduce the TTL on a single record; Recipes Section 6.7 and Section 6.8, for moving a name server and changing all of a zone's name servers; and "Changing TTLs" in Chapter 8 of DNS and BIND.
|I l@ve RuBoard|