refresh: non-authoritative answer from master

[Mike Bloxham]

On 7/11/07, Mike Bloxham <bind.users at gmail.com> wrote:
>
> 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.users at gmail.com>
> Date: Jul 11, 2007 9:22 AM
> Subject: Re: refresh: non-authoritative answer from master
> To: Mark Andrews < Mark_Andrews at isc.org>
>
>
>
> On 7/11/07, Mark Andrews < Mark_Andrews at 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_Andrews at isc.org
> > > >
> > >
> > > Oh, and one more thing, wouldn't this affect the forward lookup files
> > 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_Andrews at isc.org
> >
>
> Yes, I have a axfr-internal view that this slave matches first.
>
> 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