[CLUE-Tech] bind madness

[Jim Ockers]

Mike:

> >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.)
> >
> >  
> >
> Well, believe it or not, I was in fact updating all dns servers, and I 
> even shut down the one slave I wasn't working with.  So, I just had 2 to 
> worry about.  I got it fixed... and all I did was reboot the master DNS 
> server, which had an uptime of 89 days or something like that.  Before 
> the reboot, I ran that dig command just like you said against the 
> master, and was getting the right output.  Even with that being the 
> case, my slave was *still* getting the wrong serial everytime I reloaded 

You can also test what the slave is getting by pretending to be a slave
DNS server and doing a zone transfer:

dig @master.dns.server. zone.file.name. axfr

It is impossible that a slave DNS server would get something from the master
DNS server via zone transfer that you would not see when doing a test zone
transfer using a DiG command like the one above.

You may have to look very carefully to identify the source of the problem,
but zone problems will always be evident if you do a zone transfer.  Using
a zone transfer, you can see exactly what the DNS server thinks is in the 
zone, and it may be different from the contents of the zone file if there
are errors in the zone file.

I suppose it's possible that a SOA query would generate different results
than an AXFR query would show for the SOA value, but I find this to be a
very unlikely situation.

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