one zone where master answers but slave doesn't

[Dave Stewart]

On Aug 15, 2005, at 5:48 PM, Mark Andrews offered this insight:
>
>> 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.

Not as well past as the 8.2.4 version I replaced on "rusty". That one  
was flat out curdled and smelled bad.

;-)

This is only for internal company use, they aren't even visible to  
the outside world (or shouldn't be if I did it right). Assuming it's  
safe from attack, any issues with 9.2.2 that could bite me in the  
end? I don't mind updating, but if I'm not gaining anything important  
to me from the update ...

>> 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.

Sweet - this fixed my issue of course (adding the NS record - we  
haven't had many changes since I set this up as you can tell by the  
serial number). Many thanks!

>
>     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).

Sounds like I need to make this change (adding a NS record for the  
"other server") to all my zones (each zone currently has only the NS  
record for the server it's on; some are mastered on "rusty" and  
others are mastered on "diags"). Interesting that none of the other  
zones seem to show any issues at all though.

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



Dave Stewart
Aqua~Flo Supply (Goleta CA)
dstewart at aquaflo dot com

The box said 'Requires Windows 95, NT, or better,' so I installed Mac  
OSX "Tiger".