Changing... serial number back in the past.

[Chris Thompson]

On Oct 5 2006, Dan Mahoney, System Admin wrote:

>On Thu, 5 Oct 2006, Kevin Darcy wrote:
>
>> aad wrote:
[...]
>>> Or, if you don't want to have to stop the slave servers, you could
>>> simply set the serial number to 0 on the master server and wait for
>>> all the slaves to pick it up. Then, reset the serial on the master to
>>> the desired value.
>>>
>> Bad advice. Unless the slaves see the master's serial number as "higher"
>> than their own, they'll never transfer the zone. One could wait for that
>> replication indefinitely.
>>
>> Read RFC 1982 to see how serial number arithmetic really works. A
>> "reset" is possible, but setting the serial to 0 isn't always the way to
>> accomplish it.
>
>The method in rfc1982 is especially useful when you DO NOT have control of 
>one or more of the slave servers.

Note that should include stealth slaves as well as official ones.

>                                  I've found it to be excessive to have 
>to wait for the zones to retransfer when you can do "plan b":
>
>In cases where I do have control of ALL the slaves -- I usually update the 
>master, with reload, then delete the zonefiles from the slaves, and then 
>*completely stop* and restart bind.  Reloading, refreshing, HUP'ing, none 
>of that is enough to make that slave server forget the serial number it's 
>got cached, but if bind starts up with no zonefile, it will start fresh.

If you are running BIND 9.3.x

   rndc retransfer [zone]

will cause it to forget all about its current copy of the zone, including
the SOA serial, and refetch it from the master(s). In particular, it will
always do an AXFR, not an IXFR.

-- 
Chris Thompson
Email: cet1 at cam.ac.uk