refresh: non-authoritative answer from master
Mike Bloxham
I am getting the following when attempting to do reverse-ip zone transfers:
Jul 10 10:01:18 dns3 named[4402]: zone 1.10.IN-ADDR-ARPA/IN/internal: refres
h: non-authoritative answer from master nnn.nnn.nn.nn#53 (source 0.0.0.0#0)
Jul 10 10:01:40 dns3 named[4402]: zone nn.nnn.nnn.IN-ADDR-ARPA/IN/internal:
refresh: non-authoritative answer from master nnn.nnn.nn.nn#53 (source
0.0.0.0#0
)
My configuration has dns1 and dns2 in a DMZ. These 2 servers transfer my
reverse zone with no problems. But, my 3rd server, dns3, is behind a
firewall to serve the internal network, and can only transfer the forward
zones, not the reverse zones.
The reverse zones are both real IP-zones, and rfc1918 zones (10.1, 10.2,
etc.). I placed NS records in the reverse zone files on the master server
(dns1), thinking maybe the master (dns1) did not think that the slave (dns3)
was authoritative.
I thought maybe it was a delagation problem, but what about the 10.x zones?
The slave dns2 has no problems transfering these zones from the master dns1.
The config files between the slaves are pretty much the same.
thanks,
mike
Mark Andrews
The message means "aa" was not set in the response to the
SOA query.
The usual causes are
1. the zone is not loaded on the master.
2. you have the wrong IP address in the masters clause.
3. there is a "transparent" DNS cache intercepting the SOA
queries.
Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: Mark_A...@isc.org
Mike Bloxham
>
> I just noticed I was replying directly to Mark instead of to the
> bind-users list. Here is what I sent to Mark:
>
> ---------- Forwarded message ----------
> From: Mike Bloxham <bind....@gmail.com>
> Date: Jul 11, 2007 9:22 AM
> Subject: Re: refresh: non-authoritative answer from master
> To: Mark Andrews < Mark_A...@isc.org>
>
>
>
> On 7/11/07, Mark Andrews < Mark_A...@isc.org> wrote:
> >
> >
> > > ------=_Part_4103_15994599.1184157235153
> > > Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> > > Content-Transfer-Encoding: 7bit
> > > Content-Disposition: inline
> > >
> > > The message means "aa" was not set in the response to the
> > > > SOA query.
> > > >
> > > > The usual causes are
> > > >
> > > > 1. the zone is not loaded on the master.
> > > > 2. you have the wrong IP address in the masters clause.
> > > > 3. there is a "transparent" DNS cache intercepting the SOA
> > > > queries.
> > > >
> > > > Mark
> > > > --
> > > > Mark Andrews, ISC
> > > > 1 Seymour St., Dundas Valley, NSW 2117, Australia
> > > > PHONE: +61 2 9871 4742 INTERNET:
> > Mark_A...@isc.org
> > > >
> > >
> > as
> > > well? The forward files transfer without a problem... and this slave
> > is not
> > > even listed in the SOA as a nameserver.
> > >
> > > -mike
> >
> > Are you talking to the view you think you are?
> > --
> > Mark Andrews, ISC
> > 1 Seymour St., Dundas Valley, NSW 2117, Australia
> > PHONE: +61 2 9871 4742 INTERNET: Mark_A...@isc.org
> >
>
>
> A little more troubleshooting. I did:
> ================================
> # dig soa 1.10.IN-ADDR.ARPA @nnn.nnn.96.10
>
> ; <<>> DiG 9.3.3rc2 <<>> soa 1.10.IN-ADDR.ARPA @nnn.nnn.96.10
> ; (1 server found)
> ;; global options: printcmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29069
> ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 7, ADDITIONAL: 7
>
> ;; QUESTION SECTION:
> ;1.10.IN-ADDR.ARPA. IN SOA
>
> ;; ANSWER SECTION:
> 1.10.IN-ADDR.ARPA. 86400 IN SOA master.domain.com.
> dnsadmin.domain.com. 2007071102 36000 30 604800 86400
> <cut>
> =====================================
> By this, I see that I get an aa in the 'flags:' field. So then I did:
>
> =====================================
> # dig axfr 1.10.IN-ADDR.ARPA @nnn.nnn.96.10
>
> ; <<>> DiG 9.3.3rc2 <<>> axfr 1.10.IN-ADDR.ARPA @nnn.nnn.96.10
> ; (1 server found)
> ;; global options: printcmd
> 1.10.IN-ADDR.ARPA. 86400 IN SOA master.domain.com.
> dnsadmin.domain.com. 2007071102 36000 30 604800 86400
> 1.10.IN-ADDR.ARPA. 86400 IN NS master.domain.com.
> 1.10.IN-ADDR.ARPA. 86400 IN NS slave1.domain.com.
> 1.10.IN-ADDR.ARPA . 86400 IN NS slave2.domain.com .
> 1.10.IN-ADDR.ARPA. 86400 IN NS slave3.domain.com.
> <cut>
> ======================================
>
> So I see that from the slave, I can manually get an authoritative
> response, and a zone transfer from my master server. This would lead me to
> believe that either my configuration on the slave is wrong, or bind is
> bugged.
>
> Again, the forward zone 'domain.com' transfers, but the reverse zone does
> not.
>
> My config on the SLAVE:
>
> SLAVE Named.conf:
>
> //==========================================================
> // Named.conf
> options
> {
> query-source port 53;
> notify no;
> directory "/var/named";
> dump-file "data/cache_dump.db";
> statistics-file "data/named_stats.txt";
> memstatistics-file "data/named_mem_stats.txt";
> };
>
> logging
> {
> channel default_debug {
> file "data/named.run";
> severity dynamic;
> };
> };
>
> view "internal"
> {
> match-clients { any; };
> recursion yes;
>
> include "/etc/named.root.hints";
>
> zone "domain.com" {
> type slave;
> allow-notify { nnn.nnn.96.10 ; };
> masters { nnn.nnn.96.10; };
> file "slaves/db.int.domain.com";
>
> zone "1.10.IN-ADDR-ARPA" {
> type slave;
> allow-notify { nnn.nnn.96.10; };
> masters { nnn.nnn.96.10; };
> file "slaves/db.int.10.1";
> };
> //=======================================================
>
> My axfer-internal view on the Master:
>
> //=======================================================
> view "axfr-internal"
> {
> match-clients { nnn.nnn.96.111; };
> match-recursive-only no;
> allow-recursion { none; };
> allow-query { nnn.nnn.96.111; };
> allow-transfer { nnn.nnn.96.111; };
> notify explicit;
> also-notify { nnn.nnn.96.111; };
>
> ## Master zones
> # Forward zones
> zone " domain.com" {
> type master;
> file "db.int.domain.com";
> };
> # Reverse zones
> zone " 1.10.IN-ADDR.ARPA" {
> type master;
> file " db.10.1";
> };
> //==============================================================
>
> -mike
>
Resolved.
Reverse zones in the slave config had typos... so it was requesting
non-existent zones from the master.
1.10.IN-ADDR-ARPA was wrong
1.10.IN-ADDR.ARPA is right
-mike