Mass DNS change - increment serial required?

[verdon]

Hi,

I need to do a mass update to all my zone files under /var/named. I understand that incrementing the serial number (by 1) is important, but I'm wondering if that is really required in this case? All I am changing in the zone files is the e-mail address in

@ IN SOA ns1.myhost.com. olduser.myhost.com. ( ...

Thanks,

 

[PWSowner]

I don't think it's necessary to increment the numbers, but I may be wrong. I think without incrementing the numbers, it may just take longer for the changes to be recorded elsewhere.

 

[brianoz]

The serial numbers are only used by secondary DNS servers when deciding whether to accept a zone update or not, as far as I remember.

If you make a mass change on the server, the simplest way to get named to digest it is just to stop and restart it with "service named restart" or just rebooting the server (which has the same effect).

 

[JC]

The serial numbers are only used by secondary DNS servers when deciding whether to accept a zone update or not, as far as I remember.

If you make a mass change on the server, the simplest way to get named to digest it is just to stop and restart it with "service named restart" or just rebooting the server (which has the same effect).

How about the DNS caching that ISP's all over the world do, used on their customers connections ... won't serials not changing affect them?

 

[brianoz]

DNS caching looks at TTL values and caches the values for TTL seconds; zone serial numbers don't affect that at all.

In other words, the caching is individual record based rather than being zone based. Secondaries cache whole zones therefore they use the zone serial number as a basis for working out whether the zone has changed since the last cached version. Same serial number = no need for updating the zone, in Bind/named's mind.

But don't forget to take into mind that some large ISPs use "dumb" DNS lookup accelerators that incorrectly cache values for up to 24 hours, completely ignoring TTL values specifying shorter cache timeouts. (eg: Bigpond in Australia has been one such ISP, I know there are several in the US).

 

[SageBrian]

Interesting.

What if you just had a script replace the serial number with a brand new number with todays date?

Or at least, run you mass update, then run a 'mass serial number' script.

I'm assuming you could probably just make something like this:

(Keep in mind, this is not a script, and I can't write one. But I can figure the logic)

Find "Serial #: 2004081401" # I guess you'd make this a wildcard search?

Replace with "Serial # 2006092901" simply using today's date with a 01

 

[freedog96150]

There is a great script for just this at cplicensing.net

I have use both the 'rebuildnamedzones' and the 'updateserial' scripts with great succes. Remember to backup all original files before you begin.

 

[verdon]

Thanks all for the tips and the link

 

[JC]

DNS caching looks at TTL values and caches the values for TTL seconds; zone serial numbers don't affect that at all.

In other words, the caching is individual record based rather than being zone based. Secondaries cache whole zones therefore they use the zone serial number as a basis for working out whether the zone has changed since the last cached version. Same serial number = no need for updating the zone, in Bind/named's mind.

But don't forget to take into mind that some large ISPs use "dumb" DNS lookup accelerators that incorrectly cache values for up to 24 hours, completely ignoring TTL values specifying shorter cache timeouts. (eg: Bigpond in Australia has been one such ISP, I know there are several in the US).

Thanks for this explanation .... makes sense