Re: Upcoming change to SOA values in .com and .net zones

[Paul Vixie]

> > | but isn't 2004010101 (today) > 1076370400 (9 Feb 2004)?

yup.

> ...
> The way BIND/etc determine when a new zone file has been issued is by
> seeing if it has a higher SN than the currently caches zone.
> 
> Frank's question is that when view simply as 10 digit integers (which is
> how BIND uses them) 2004010801 is a larger integer than 1076370400.

yup.

> This might cause problems with cached zones and other such staleness, so
> it does seem a valid concern.

it'll be fine.  this protocol detail only matters between master and slave
servers having an AXFR or IXFR relationship.  since verisign runs all of the
authority servers for COM and NET, they can manage the serial number "rollback"
as a strictly internal matter.

it's only if the master is run by one party and the slave(s) are run by other
parties that serial number arithmetic comes into play.  since these servers
are all run by one party (that is, verisign itself), they can work privately
to ensure that "less" does not mean "backward" in this transition.

in the past, when COM and NET were served by the root name servers, verisign
would have had to coordinate a change like this according to the rules of DNS,
implementation-specific rules of BIND and whatever else was running then, and
the group's coordination and monitoring rules.

those days are gone.  verisign isn't doing anything wrong in this change, and
it's probably going to work out just fine.
-- 
Paul Vixie