Updating bind serial numbers automatically
We'll go through the steps here in case you weren't the one to set up those files or if you'd just like a checklist to follow.
Make these changes to your The primary master name server will load the new zone data.
The next modification that day would change the serial number to 1997011501. It also has the advantage of leaving you an indication in the zone data file of when you last incremented the serial number.
What do you do if the serial number on one of your zones accidentally becomes very large and you want to change it back to a more reasonable value?
Something is always changing on your network -- new workstations arrive, you finally retire or sell the relic, or you move a host to a different network. First we'll discuss how to make the changes manually. Actually, we recommend that you use a tool to create the zone data files -- we were kidding about that wimp stuff, okay?
Each change means that zone data files must be modified. Or at least use a tool to increment the serial number for you.
Slave name servers will load this new data sometime within the time interval defined in the SOA record for refreshing their data.
Sometimes your users won't want to wait for the slaves to pick up the new zone data -- they'll want it available right away.
Log onto one of your slave name server hosts and kill the ) and start up your slave name server.The syntax of zone data files lends itself to making mistakes.It doesn't help that the address and pointer records are in different files, which must agree with each other.There is a way that works with all versions of BIND, a way that works with Version 4.8.1 and later, and one that works with 4.9 and later.
The way that always works with all versions is to purge your slaves of any knowledge of the old serial number.
(Are you wincing or nodding knowingly as you read this?