[Fwd: Re: non-authoritative answer from master [SOLVED]]

...... and I hate when mailing lists put senders in the Reply field
instead of the list. :-P

-j

-------- Original Message --------
Subject: Re: non-authoritative answer from master [SOLVED]
Date: Tue, 03 Aug 2004 11:07:20 -0500
From: John Beamon <jbeamon@franklinamerican.com>
To: Ronan Flood <ronan@noc.ulcc.ac.uk>


Ronan Flood wrote:
> John Beamon <jbeamon@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.
>

Thanks for that tip. Those have never worked for me, and I think you
might have hit the nail on the head.

We finally found something. Last night, I found that I could run
natural slave-master axfrs from within the LAN, within the DMZ, or from
outside the DMZ to the public internet. I could not run an axfr through
the firewall. I could run a dig type axfr, but not a slave-expiring,
natural, refresh axfr. I brought the slave up with the master's config
and zone files, as a "master" itself, and it was immediately
"authoritative" at dnsreport.com. The problem was not the configs or
the zone files.

Our IP space changed a few months ago, and we had aliased IP addresses
on our firewall for the old 63. network. Between the last successful
AXFR and the 7d expiry, we removed the old 63. alias' rules from our
firewall config, using a gui tool called "firewall builder"
(fwbuilder.org, this is still an excellent product). What we didn't
know was that the GUI created a fallback rule to proxy traffic formerly
handled by that alias through the firewall's existing external IP, which
runs a resolver. We were transparently resolving A/PTR/TXT requests
directed AT the name server from WITHIN the firewall's resolver. SOA
records can't be cached by non-authoritative resolvers, so axfrs were
failing to find the answering server "authoritative". Our master
immediately appeared "non-authoritative" to the world. Our slave was
authoritative until its 7d expiry ran out, at which point we suddenly
had no authoritative name servers. The slave wouldn't load its expired
zones and couldn't retrieve new ones because of the proxy rule. We
removed that fallback rule from the firewall, and the problem solved
itself. (At this exact time, I'm still using funky forward zones
instead of the more streamlined NS records I used to have, but I can run
axfrs of fake domains back and forth without errors.)

My thanks to those who contributed, especially since I had so little of
the actual picture to provide you. This is almost a journal article in
the making, except that it makes me out to look like a real numbnuts.
I'll think about it. The good news is that our expiry was set to only a
week instead of any longer. If it had been a month, our slave would
have answered "authoritative" through the next three weeks without a
transfer from the master, and we've have been up poop creek without a
clue when it finally died.

--
John Beamon
Systems Administrator
Franklin American Mortgage Co.
em: jbeamon@franklinamerican.com