Masters, Slaves, and Serial Numbers

The serial number of the SOA record is very important to the correct operation of slave servers. Each time you edit your zone, the serial number must be increased so that the slave server can detect that the zone has been updated. Whenever the slave server notices that the serial number has changed, it performs a zone transfer and updates its cached zone file. In Chapter 3, you can find a discussion of how the SOA controls zone transfers and tips about how to plan changing zone data so server moves and similar changes can be done in a planned and orderly manner.

If some users are getting old data from DNS, the cause could be that one of your slave servers is still serving the old zone data because it has not seen that the master has been updated, or because it has failed to complete the zone transfer, for whatever reason. The problem that caused zone transfer failure might soon go away, but it might also be caused by misconfiguration of the slave or a firewall between the master and the slave preventing the zone transfer. You can easily check the SOA record on the slave servers with dig. If it keeps staying at an old serial number, you know you have a problem. If it takes too long to get updated zones, you might have a network problem.

If the slave-server is incapable of transferring the zone for the time set in the expire field of the SOA record, it expires the zone and stops serving data from it. Some sources recommend setting the expire value as high as four weeks. If the master server or the network stays down for a long time, the zone can be prevented from expiring by editing the file making the slave server think that the zone is fresher than it is. This is a rather desperate measure, but is sometimes required, especially when the expire time is only one week.

Manual editing of the serial number can result in mistakes, one of which is entering a serial number that's too small, causing the slave to think it is more up-to-date than the master. This is easily fixed by entering the correct, larger number. A mistake that takes a bit more work to correct is entering a serial number that is too large. When the slaves pick up the new zones, they will have this large serial number, and if you try to enter the correct, smaller serial number, the slaves won't want to update their zones. This is because, by serial number comparison, they know their zones to be newer than the one they see on the master server. This too can be solved.

This is the easy way: If you control all the slave servers, simply log into them, remove the slave zone files, and ndc restart the server this forces a retransfer of the slave zones.

This is the hard way: The DNS serial number is a 32-bit unsigned quantity, and because the DNS designers wanted to plan for the future, they designed the serial number mechanism in a tricky way. It is a bit difficult to follow if you're not familiar with two's complement binary arithmetic. If the new serial number (minus the old one), performed in signed 32-bit arithmetic with no overflow correction, is a positive number, a zone transfer is needed. That is a bit complicated, but the practical upshot is this (follow these steps):

1. Take your erroneous serial number and add 2,147,483,647 (2^31) to it.

2. If the result is larger than 4,294,967,296 (2^32), subtract 4,294,967,296 from it.

3. You now have a new, temporary serial number. It will either be numerically less than the correct serial number or much bigger. It will cause the slave servers to trigger a zone reload. Enter it in the zone file, and wait until all your slave servers have picked it up.

4. When you have ensured that all the slave servers have the temporary serial number, enter the correct serial number and your slaves will pick up the zones with the new, now correct serial number.

Another upshot of this is that you can change your zones often. If you keep your serial number in numeric form rather than the traditional YYYYMMDDNN form, you can make up to 4,294,967,296 zone changes in each expire period provided that the expire period is 4 weeks, the zone can be updated 887 times a second.

If you use DDNS, or something else that automatically manages your serial number, to maintain your zones, you won't ever run into this problem.