one zone where master answers but slave doesn't

[Mark Andrews]

> Hi all!
> I have something curious here and I'm not sure how to track it down.  
> I have set up two named servers to resolve internal addresses which  
> seem to be working fine, except for one zone. Nothing in the log  
> files on either server seem to indicate any trouble.
> 
> The master for this particular zone is running on an AIX 5.1 box  
> named "rusty" and runs BIND 9.3.1. Dig reports the following:
> 
> 
> myprecious:~ DWS$ dig @rusty aquaflo.com
> 
> ; <<>> DiG 9.2.2 <<>> @rusty aquaflo.com
> ;; global options:  printcmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52838
> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1
> 
> ;; QUESTION SECTION:
> ;aquaflo.com.                   IN      A
> 
> ;; ANSWER SECTION:
> aquaflo.com.            259200  IN      A       192.168.12.230
> 
> ;; AUTHORITY SECTION:
> aquaflo.com.            259200  IN      NS      rusty.aquaflo.com.
> 
> ;; ADDITIONAL SECTION:
> rusty.aquaflo.com.      259200  IN      A       192.168.12.200
> 
> ;; Query time: 11 msec
> ;; SERVER: 192.168.12.200#53(rusty)
> ;; WHEN: Mon Aug 15 12:22:08 2005
> ;; MSG SIZE  rcvd: 81
> 
> myprecious:~ DWS$
> 
> 
> Looks fine. Now the same query through a slave server for this zone,  
> which is running on an OSX 10.3.9 box named "diags" (a Mac Mini, if  
> it matters) and running BIND 9.2.2 (outdated I know, but not by that  
> much right? Besides, this is only for internal use:):

	BIND 9.2.2 is well past its "use by" date.
 
> myprecious:~ DWS$ dig @diags aquaflo.com
> 
> ; <<>> DiG 9.2.2 <<>> @diags aquaflo.com
> ;; global options:  printcmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46540
> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
> 
> ;; QUESTION SECTION:
> ;aquaflo.com.                   IN      A
> 
> ;; AUTHORITY SECTION:
> aquaflo.com.            86400   IN      SOA     rusty.aquaflo.com.  
> dstewart.aquaflo.com. 1 43200 3600 1209600 86400
> 
> ;; Query time: 1 msec
> ;; SERVER: 192.168.12.25#53(diags)
> ;; WHEN: Mon Aug 15 12:22:03 2005
> ;; MSG SIZE  rcvd: 80
> 
> myprecious:~ DWS$
> 
> 
> Note that I have a number of other zones that resolve perfectly  
> through both servers (including "www.aquaflo.com"), it's just this  
> one ("aquaflo.com") that seems to have issues. Logging on both  
> servers is currently at severity "info" and a bunch of categories  
> turned on (config, lame-servers, queries, xfer-in, xfer-out, client,  
> and general on "diags" specifically). I've tried restarting named on  
> both machines (figuring I could track the issue down faster if I had  
> shorter log files to weed through), but nothing has changed and  
> nothing in the logs indicate a problem at all. I have even cranked up  
> the logging on "diags" to include everything at severity "debug 10",  
> but still nothing indicating a problem.
> 
> Ideas? Thoughts? Suggestions? Before I spend too much more time  
> trying to track this down, does anyone have an idea where I should  
> start looking for the problem?
> 
> 
> 
> 
> Dave Stewart
> Aqua~Flo Supply (Goleta CA)
> dstewart at aquaflo dot com
> 
> The human mind ordinarily operates at only ten percent of its
> capacity -- the rest is overhead for the operating system.

	Add a NS record for the slave and *increase* the serial number
	in the SOA record.  I suspect you failed to increase the
	serial number after the last change as it is still 1 on diags
	or you have not waited long enough for the change to propogate.
	
	Note as you don't have diags list as a nameserver it can't
	take advantage of NOTIFY and is using the SOA timer values
	to poll the master for changes.  With the current values this
	could take 12 hours (43200).

	Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org