Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 12 Mar 2002 11:52:28 +0200
From:      "Patrick O'Reilly" <peri@perimeter.co.za>
To:        "Kevin Oberman" <oberman@es.net>
Cc:        "FreeBSD Question List" <freebsd-questions@freebsd.org>
Subject:   Re: Authoritative vs. non-Authoritative DNS ?  Solved.
Message-ID:  <008101c1c9ab$a39e0f80$b50d030a@patrick>
References:  <20020311233936.70D7E5D07@ptavv.es.net>

next in thread | previous in thread | raw e-mail | index | archive | help
----- Original Message -----
From: "Kevin Oberman" <oberman@es.net>


> > From: "Patrick O'Reilly" <bsd@perimeter.co.za>
> >
> > Hi all.
> >
> > What determines whether a DNS server will answer a query
> > authoritatively, or not?
> >
> > I have two DNS servers on private networks serving their private
domains
> > as "master" servers according the named.conf.  One responds
> > authoritatively within its own domain, and the other always responds
> > with this warning line:
> > ------------------------------
> > Non-authoritative answer:
> > Name:    www.domain.com
> > Address:  aaa.bbb.ccc.ddd
> > ------------------------------
> > I cannot see what I have done differently!
>
> The difference between an authoritative an a non-authoritative
> response is whether the information comes DIRECTLY from an
> authoritative server or from data cached in a non-authoritative
> server. It has nothing to do with the query, itself.
>
> If you have a server that is supposed to be authoritative for your
> private domain and it is responding as non-authoritative, it is
> broken. It is quite possible. You need to look for named messages in
> your messages file (assuming you have not adjusted syslogd to log
> elsewhere.)
>
> You say that you have two "master" servers? This is not a normal
> operation as it requires the zone files for the authoritative zones on
> the two systems to be kept in sync. The normal procedure is to have
> one system act as a master and the other as a slave, transferring the
> data from the master.
>
> R. Kevin Oberman, Network Engineer
> Energy Sciences Network (ESnet)
> Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
> E-mail: oberman@es.net Phone: +1 510 486-8634
>
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-questions" in the body of the message

Kevin,

Thanks for taking the time to repond to my question.

I hang my head in shame - I checked /var/log/messages and found that
there was a syntax error in the zone file which caused it to be rejected
(one of the IP addresses was missing an octet).  D'oh - should have
checked that before emailing the list!

For the information of anyone following this thread, I'd like to point
out that the authoritative response seems to be decided on any one of:
 (a) the "type master" directive in named.conf,
 (b) the SOA record, or
 (c) the 'NS' records in the zone file.

Here's why I say this:

I am running what my ISP likes to call a "shadow master" DNS server.  I
have the zone files for domains I control on this server.  My named.conf
defines the zone entries as "type master", but the various SOA records
and NS records refer to two DNS servers at my ISP, and NOT my own
server.  Yet, when I perform nslookup on my shadow master it answers
authoritatively.  I can also perform nslookup against the DNS servers at
the ISP, and they too answer authoritatively.

In summary:
 (a) my server is "type master", but NOT in the SOA or NS records
 (b) the ISP's primary DNS server is "type slave", but IS in SOA and NS
records
 (c) the ISP's secondary DNS server is "type slave", but IS in NS
records
and all of these servers answer authoritatively.

Thanks to all who responded for your help.

Regards,
Patrick O'Reilly.
---
Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming, or what?"


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?008101c1c9ab$a39e0f80$b50d030a>