changing nameserver name and TTL

[Kevin Darcy]

LC's Nospam Newsreading account wrote:

> We are going to perform a two-step upgrade of our (Solaris 2.5, BIND 4.x)
> primary DNS and MX, a machine (say it's called A and has IP nn) which is
> also performing other functions.
>
>   - in the first step we will offload most of the non-DNS functions
>     to a Solaris 2.7 machine which will inherit the name A under a
>     different IP (pp).
>
>     At the same time the current DNS will retain its IP address nn,
>     but assume a new name B, and continue to function under Solaris 2.5
>     and BIND 4  as DNS and MX
>
>   - in the second step the DNS and MX machine will be upgraded to
>     BIND 8.x under Solaris 2.7 (with the same name B and IP nn)
>
> My present question is concerned ONLY with the first step under BIND 4.
>
> I know that in cases like these one should "gradually" decrease the TTL
> until the change of name, and then bring it back to normal afterwards.

The value of "gradual" TTL decreases is highly debatable, in my opinion.
Sure, it's the "friendly" thing to do, but it's also more work, and inserts
more points of failure into the process. If a decrement step is missed, with
the result that some caching servers still have stale records, there is
significant disruption and wasted resources as clients attempt to connect to
non-answering servers. This possibility seems to dwarf the benefits of
"gradual" TTL decreases. My preference, usually, is to just reduce the
TTL once before it's changed.

> But WHICH is the TTL to change ?
>
> We have a refresh, retry, expire and "default TTL" in the SOA record,
> another TTL in the NS record, another TTL in the MX record, and another
> one in the glue A record.

Refresh, retry and expire only affect slaves. If you have slaves without
NOTIFY capability and which you cannot arrange to *force* zone transfers
shortly after changes are made, then you may wish to reduce the refresh and
retry times to speed up master/slave replication.

The "default TTL" is just that -- a default. Any record with an
*explicit* TTL value overrides the default. You should reduce TTL's for
*all* records of all types that are going to be changing, in order to
temporarily defeat the caching of those records. Note that the "default
TTL" is specified differently in later versions of BIND 8 (in accordance
with RFC 2308, the last field of the SOA record is now interpreted as the
negative caching TTL rather than the default TTL -- therefore one must use
explicit TTL's or the $TTL master-file directive).

You mentioned a glue A record. Is this a glue A record for one of your own
subzones, or is it a glue A record held by the TLD servers (e.g. the "com"
servers) for one of your domains? You're not going to be able to change the
TTL of the glue A record in the TLD servers, and those TTL's are typically 2
days.

> Which are the ones to change, if all what I'm doing is changing the name
> of the primary DNS (and primary MX) keeping the same IP address ?

In that case, just the NS and MX records. If the server has been delegated
from a TLD server, then the delegation NS record will also have to be
changed through your registrar.


- Kevin