Re: Bogus nic.fr behavior

[Robert Elz <kre@munnari.OZ.AU>]

    Date:        Wed, 07 Feb 2001 09:54:35 +1100
    From:        Mark.Andrews@nominum.com
    Message-ID:  <200102062254.f16MsZN94314@drugs.dv.isc.org>

  | 	Robert you are reading more into the statement than was there.

No, I know exactly what you were saying.

  | 	I am not saying

But you should be, because with one addition, this is the right
way to do it...

  | 	Parent old  Child old
  | 		new servers commissioned
  | 	Parent old  Child new	*** broken zone ***
  | 		inform parent
  | 	Parent new  Child new
  | 		ttls expired, old servers de-commissioned

If this becomes

	Parent old  Child old
		new servers commissioned
	Parent old  Child old & new (both) carrying only the new NS RRset
		inform parent
	Parent new  Child new
		ttls expired, old servers de-commissioned

then you have a perfect delegation change - while the parent still
has the old data, queries will keep going to the old servers, but
they will answer with data from the new zone file (including the new
NS record set).   That the parent is (for a whort while) still giving
out the old NS records is just yet another example of the DNS having
a time lag before old data shifts to become new data (it causes no
operational problems if planned for).

Of course, this can't always be accomplished, sometimes the old servers
are decommissioned before anyone (even the operators of the old servers
sometimes...) gets to know about it...   But that's not a problem that
can be solved by changing the order or content of NS updates.

With your scheme, everything that this scheme requires still needs to be
done, the new and old servers still need to be synchronised (for you,
with both of them having the combined NS record set) - except that for
my scheme, once the parent is updated, and time allowed for TTLs to
expire, the old servers simply become irrelevant to everyone, no more
updates need be made anyway.

In any case, you can guarantee that for all delegations I do, I *always*
copy the NS record set (and glue) from the authoritative servers, I use
the info that people send me only to find those servers in the first
place.   If they include 17 servers in their NS RRset, then all 17 of
them go in the parent zone, regardless of how many they told me about
on the form (which I think only has space for 3 or 4 anyway).

From the point of view of validating that the servers being delegated to
contain data that makes sense, this is the only way, as you're not
relying on the operators of the servers making additional changes after
the delegation change at the parent (and then doing it correctly, making
sure the SOA.serial gets updated, etc).

kre