[dns-wg] DNS Migration document

Jim Reid <jim at rfc1035.com> writes:
> At long last, there is progress on AP49.1. I have revised the  
> document that Fernando presented to the WG. It's attached below.  
> Comments and feedback are welcome.
Some comments below:
[ ... ]
> 2.2 Check the new server is authoritative for the zone
> 
> Once the new slave server is answering authoritatively for
> example.com, this should be verified with a DNS query utility such as
> dig:
> 	% dig @10.9.8.7 example.com soa
[ ... ]
> It is also important to check that the AA (Authoritative
> Answer) bit is set in the response from the new slave
> server. This is indicated by the "aa" entry in the flags header
> shown in the above output from dig.
Some name servers, e.g. older versions of BIND, will, if also
acting as resolvers, pass on the AA flag from a remote,
authoritative server, even if not authoritative itself.  This can
lead the operator to assume that the new slave server is
correctly configured with authoritative data even when it is
not.  The query should be sent without the RD (Recursion Desired)
flag set, i.e. the command should be:
% dig +norecurse @10.9.8.7 example.com soa

I think this change should also be applied to most other
occurances of dig query commands in this document.

[ ... ]
> 2.3.1 Updating the zone
> 
> This is straightforward. An NS record for the new slave server is
> added to the example.com zone. If glue is needed, this would be added
> at this point. This would be required for the case of ns1.example.com
> because this name lives in the example.com. [Technically speaking,
> ns1.example.com lives under the example.com zone cut so an A or AAAA
> record for ns1.example.com needs to be added as "glue".]
The data in the example in this section does not correspond to the
definition of "glue" in rfc1034.  The A RRs for the example.com
domain within the example.com zone are authoritative data (unless
of course there exist further delegations not shown in the example).

Suggested new text:
This is straightforward. An NS record for the new slave server is
added to the example.com zone. Do also ensure that there exists
at least one address record (A or AAAA) for the new slave server.
If the RR set for the new slave server name is managed within the
example.com zone, the required address records must be added to
the example.com zone.

[ ... ]

> 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
> the example.com or .com zones for slave.example.com.
This transition period can be controlled by the name server
operator and registry by adjusting the TTLs for the relevant RR
sets.  Even if no adjusting takes place, at least the duration of
the actual transition period can be deduced from the published
TTL values.  Should the document cover this?

[ ... ]

> 3 Moving a master server
I find the described procedure unnecessarily cumbersome.  What I
would normally do is (rough outline):
o Prepare the necessary infrastructure on the new master server
o Prohibit further updates on the old master server; freeze the
  zone if it's being dynamically updated; transfer zone file to
  new master and add it to the active configuration.
o Re-configure the old master as a slave server, slaving the zone
  file from the new master.  Add also-notify directives to both
  the new and old master if desired.
o Enable updates on the new master server.
o Notify slave server operators, and ask that the zone be slaved
  directly from the new master.  The step of slaving from a
  dual master setup may possibly be skipped, although following
  the two step slave configuration procedure may guard against
  some configuration errors and inadequate testing.

The considerations regarding the SOA values as well as the
procedures for updating the delegations etc. from the original
text still applies.

Would the document benefit from having a more detailed
description of this procedure in addition to or instead of the
current text?  Also, although the procedure above has worked fine
for my master changes, maybe it has flaws that my operational
environment hasn't triggered?
[ ... ]

As a registry operator, there is one additional topic that I
think the document should cover.  The most severe problems in
association with name servers changes occur when the registrant
closely links significant changes to his service infrastructure
(web, mail ...)  with a full change of the domain delegation/name
servers.  I.e. the brand new web shop will not be available to
the customers until the change in the DNS _delegation_ has taken
effect.  This put the registrant at the mercy of several external
parties (old and new DNS operators, registrars, registry), over
whose systems he may have limited direct control.  If there are
any delays, or errors happen during the DNS change, the resulting
problems will be severe (and these changes of course always take
place during the weekend, when delays and errors are more likely
to occur...).  My advice is that, to the extent possible, changes
to the DNS delegation should be performed separately from changes
to the other service infrastructure.  Then, for the service
infrastructure changes, the zone administrator is free to manage
the zone contents without being dependent on other parties.

Does anyone else think we should add text to the document to
address this problem?  Or is it beyond the scope (in its current
form, it mostly covers changing one server at a time)?

					-jarle
-- 
"There's too much blood in my caffeine system."