Fwd: refresh: non-authoritative answer from master

Mike Bloxham bind.users at gmail.com
Wed Jul 11 14:36:16 UTC 2007


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




More information about the bind-users mailing list