one zone where master answers but slave doesn't

[Mark Andrews]

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

	It's still well past its "use by" date.  Why do people assume
	security issues are the only reason for updating.  There
	have been hundreds of bugs fixed since BIND 9.2.2.  Go read
	the CHANGES log for BIND 9.3.1.  Just about every [bug]
	listed there and not listed in the BIND 9.2.2 CHANGES will
	apply to BIND 9.2.2.

	We release maintenance releases (bug fixes only) because
	people have asked for them.  Maintenance releases are
	designed to be drop in replacements for earlier releases
	in the same series.

	Feature releases on the other hand may require minor changes
	to configuration and/or applications linked against the
	libraries.  We try to minimise this and make them drop in
	replacements but we don't guarantee it.   BIND 9.3. wasn't
	completely drop in and BIND 9.4 won't be either.

	Note some bugs can only be fixed by adding new features so
	one should plan on moving to the next feature release series
	as soon as possible to get all the bug fixes.

> >>
> >> ; <<>> 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".
> 
> 
> 
> 
> 
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org