non-authoritative answer from master
Ronan Flood
ronan at noc.ulcc.ac.uk
Tue Aug 3 11:39:29 UTC 2004
John Beamon <jbeamon at franklinamerican.com> wrote:
> I have had a two-host DNS system up and running for months, and it
> recently developed a problem. The master is telling the slave it is not
> authoritative for any of the 10 or so domains for which it has zone
> files. They are all running BIND-9.2, 'type master' zones, served from
> files on the disk. None of them are slaved from outside our network.
> Each zone file has an SOA record. www.dnsreport.com's test of
> "franklinamerican.com" shows that my master (67.107.93.4) has become
> lame. Oddly enough, at the beginning of the day, both the master and
> slave were lame. I couldn't tell you what fixed the slave.
67.107.93.4 is still authoritative for the local zones "localhost"
and "0.0.127.in-addr.arpa", so maybe you could compare the setup of
those with the failing ones to see if there's any obvious difference.
Check your /var/log/named/default_log for error messages.
> The slave's zone files (named:named 0600) are about 10 days old, so
> these records finally just expired on me. Refreshing any zone from the
> slave gets me a "refresh: non-authoritative answer from master
> 67.107.93.4#53" error. I can dig axfr successfully, so it doesn't
> appear to be a network issue. The output of a host SOA check is below.
I presume from the slave you can't do
dig @67.107.93.4 franklinamerican.com. axfr
> All that appears to be correct. ns2 at least knows about the changes on
> ns1, but it's not seeing ns1 as authoritative. What could make a server
That would be odd, as ns2 claims to be authoritative for that zone;
where else could it have got an up-to-date copy of it?
> say it's no longer authoritative for ANY of its zones? Part of each
> named.conf is pasted below for your inspection. Thanks.
>
> ns1:/etc/named.conf
> include "/etc/rndc.key";
> acl WORLD { 0.0.0.0/0; 127.0.0.0/0; };
> acl LAN { 192.168.0.0/16; 127.0.0.0/0; };
> acl DMZ { 67.107.93.0/24; 67.107.79.0/24; };
> acl SLAVES { 67.107.79.4; };
> options { directory "/var/named";
> pid-file "/var/run/named/named.pid";
> allow-recursion { localhost; LAN; DMZ; SLAVES; };
One passing comment: I don't think your LAN acl is correct, as
your servers allow me to perform recursive queries. You probably
mean 127.0.0.0/8 on both servers, as /0 matches everything.
--
Ronan Flood <R.Flood at noc.ulcc.ac.uk>
working for but not speaking for
Network Services, University of London Computer Centre
(which means: don't bother ULCC if I've said something you don't like)
More information about the bind-users
mailing list