one zone where master answers but slave doesn't
Mark Andrews
Mark_Andrews at isc.org
Tue Aug 16 23:52:57 UTC 2005
> 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
More information about the bind-users
mailing list