Re: [cobalt-users] How to move RAQ to new IP addresses

["E.B. Dreger" <eddy+public+spam@xxxxxxxxxxxxxxxxx>]

SW> Date: Fri, 27 Dec 2002 10:10:00 -0500
SW> From: Steve Werby


SW> You could be right, but that shouldn't be an issue since the
SW> glue record points the name server hostname to the IP and any
SW> zones (domains) which use the name server should point to the
SW> name server hostname, not an IP address.

Correct.


SW> In any case, doing this type of migration is an issue if
SW> there's ever the possibility that *all* reachable
SW> authoritative name servers will point to invalid IPs.  If

True, although one might question _why_ anyone would be in that
scenario.  People should use off-site secondary DNS, anyhow, in
which case one does not encounter the "match the moving glue NS
RRs" scenario -- at least not on all DNS servers.


SW> this is a possibility, it can be preferable to change their
SW> IPs one at a time so you know there's at least one that's
SW> accurate since machines will cycle through your listed
SW> authoritative name servers until one that's reachable is
SW> located.

I disagree.  Change the NS glue records first.  Once the new NS
is squared away, one is ready to renumber safely.  There are a
few right ways, and probably several wrong ways, to do this:

* Put a new box in the new network, and slave zones to the new
  machine.

* Use someone else for DNS; perhaps permanently, perhaps only
  during the renumber.  We've had clients move all DNS to us
  while renumbering, then take primary back when done.

* DO NOT serve primary DNS records on both the new and old
  boxen.  The serial numbers in the SOA RR will get out of whack.
  Cobalts hide the serial numbers from you, but they still
  require respect.  The results can be interesting if the serial
  numbers are widely divergent; see RFC1982 for information on
  this.

In any case, one should decrease the TTL to minimize caching
effects.  I don't know any specifics, but I've heard rumors of
broken resolvers that dislike a 0 TTL; however, who would notice
the difference between no caching and a 1-second TTL, anyhow? ;-)

Note, too, that one can use "also-notify" in BIND config to force
sending of zones to another DNS server by IP address.  One must
still configure the slave's zone list manually, but also-notify
will make the master send zones to another NS that isn't on the
authority list.  (This requires editting the Cobalt's Perl CGIs,
but I've done it successfully.)  It really isn't needed often,
though it's useful now and then. :-)


Eddy
--
Brotsman & Dreger, Inc. - EverQuick Internet Division
Bandwidth, consulting, e-commerce, hosting, and network building
Phone: +1 (785) 865-5885 Lawrence and [inter]national
Phone: +1 (316) 794-8922 Wichita

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Date: Mon, 21 May 2001 11:23:58 +0000 (GMT)
From: A Trap <blacklist@xxxxxxxxx>
To: blacklist@xxxxxxxxx
Subject: Please ignore this portion of my mail signature.

These last few lines are a trap for address-harvesting spambots.
Do NOT send mail to <blacklist@xxxxxxxxx>, or you are likely to
be blocked.