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