[CLUE-Tech] bind madness

[Jim Ockers]

Mike:

> Alright, I'm going crazy here - I have 3 dns servers, all running bind 
> 9.2.1-X.  I have a zone file that's master server is an ip like this:
> 
> 10.0.0.11
> 
> The serial number used to be some outrageously high number, like 
> 275638326327.  The old admin here gave it that high of a number, and I 

I would recommend using a serial number in the following format:

YYYYMMDDNN where the data is obvious and NN is a 2 digit number like 01.
In some older versions of BIND that is the longest number you can use
for a serial number, so it's a good idea.

> don't know why.  So, I shrank it down to 80... and I did this by 
> stopping bind on all 3 servers, and setting it the same on all of them, 
> and then restarting bind.  I then made an update to the 10.0.0.11 server 
> with that zone file.  I updated the serial number to 81, and restarted 
> bind there first, and then next on the other servers.  The problem I'm 

If you put the following in your named.conf in the zone definition you 
might not have to restart your other servers if their IPs are reachable 
from your master server: 

	also-notify { x.x.x.x; y.y.y.y; };

With that directive the secondaries will be notified if there is a
change to the zone, regardless of whether or not they are listed
as NSes or if they've done a zone transfer already or not.

> now having is that I see this in my logs on the slave servers:
> 
> Jun 20 12:00:08 fimble named[23817]: zone somedomain.com/IN: sending 
> notifies (serial 80)
> Jun 20 12:00:09 fimble named[23817]: zone somedomain.com/IN: transfered 
> serial 275638326327
> Jun 20 12:00:09 fimble named[23817]: transfer of 'somedomain.com/IN' 
> from 10.0.0.11#53: end of transfer
> Jun 20 12:00:09 fimble named[23817]: zone somedomain.com/IN: sending 
> notifies (serial 275638326327)
> 
> What gives? Is there some kind of cache somewhere, and keeps old 
> serials in a database somewhere that I'm unaware of??  I would think 
> that since I updated all 3 servers, that the serial number 275638326327 
> should not exist anymore.

Your problem is that you THINK you've updated them all but you may not
have.  It happened recently that a server was swapped out and the DNS
data was copied over, and a symlink got copied into a plain file.  Now
instead of two filenames pointing to the same file, there were two files.
The DNS administator edits one of the files, assuming that the sym-
link still exists.  named.conf uses the other filename.  The edit has no
effect because named is using the other filename, and they are no longer
the same file because the symlink is gone.

You will need to do some detective work and grepping perhaps, to find out
where the offending serial number is coming from.

dig @master.dns.server. zone.to.query. soa
dig @slave1.dns.server. zone.to.query. soa
dig @slave2.dns.server. zone.to.query. soa

and so forth, until you've identified the source of the bad serial number.
(It would seem logical to assume that it'd be on the master, but I don't
know your setup, so I can't say for sure where it is.)

Let me encourage you to use the SOA for the zone to contain the name of
the DNS server that is the master.  This is a major pet peeve of mine:
the SOA should contain the name of the DNS server for the zone master,
and the e-mail address of the person or group which administers that DNS
server.  With that information, the SOA record becomes very useful at
identifying DNS problems and analyzing the structure of a DNS tree.

So you would have in your zone file:
@		86400	IN SOA	master.dns.server.fqdn. staver.fimble.com. {
		and so forth }

Anyway the above DiG commands will tell you who has the big bad serial
number, and if your SOA shows the FQDN of the zone master, you'll know
what host has the zone file you need to fix.

Hope this helps.

-- 
Jim Ockers, P.Eng. (ockers at ockers.net)
Contact info: please see http://www.ockers.net/