[ On Tuesday, February 19, 2002 at 10:43:58 (-0800), Jeremy C. Reed wrote: ]
> Subject: Re: dig and DNS authority
>
> Note that some DNS servers don't even have the concept of "primary" (or
> master) and "secondary" (or slave). (For example, rsync or other tools
> could be used to transfer the zone data.)

No proper conforming DNS server has any concept of "primary" or
"secondary".  Indeed there's no such thing as "a secondary" nameserver.
There is only the "primary" (and the authoriative servers).

Just because there's a "primary" of something doesn't mean there has to
be a "secondary"!  :=)

NS records are always (supposed) to be returned in round-robin fashion.

> The only thing that is important is if it is authoritative.

The servers declared by the NS records "MUST" be authoritative.

The primary nameserver is merely the host declared in the first
sub-field of the SOA record for the zone.  There is no such thing as a
"secondary".  The primary nameserver need not be listed in the NS
records (either within the zone itself, or in the parent zone, and note
that WHOIS simply reflects the parent zone's listings).

Ideally the primary nameserver will answer authoritatively for queries
within the zone, but in reality the primary nameserver need not even be
reachable from the public Internet.

(BTW, any server can also be authoritative too, even if it's not listed
in any of the NS records given by the parent zone or within the zone)


[ On Tuesday, February 19, 2002 at 14:23:45 (-0500), Bill Sommerfeld wrote: ]
> Subject: Re: dig and DNS authority 
>
> Only way to know for sure is to look at the /etc/named.conf file or
> its moral equivalent on each replica.

Well, yes, the primary nameserver is supposed to be the one into which
the original authoriative zone file has been loaded, but that's just a
guideline.  The declared primary nameserver can just as well be a slave,
though doing that while also declaring the nameserver which loads the
original master zone file in the public NS records would be, well,
misleading at best.

> The first name in the SOA record for the zone often names the primary
> server for the zone but is also often out of synch with reality.

Regardless, the "primary nameserver" _is_ the one listed in the SOA
record.  If that's wrong it doesn't really change anything -- it's still
the "primary", even if it's not authoritative for the zone!

The idea behind declaring a "primary" nameserver is so that any apparent
discrepancies can be resolved from afar (i.e. without having to contact
the zone owner, provided that it is publicly reachable and will answer
queries).  Eg. if two authoritative nameservers return different replies
the one(s) with a stale non-slave copy of the zone file can be
identified since the "primary" nameserver is supposed to be the sole
original authority for the zone.  However this is really only for
debugging purposes -- I don't know of any resolver code that actually
automatically queries the primary nameserver for records in a zone.

In general practice all the "slave" nameservers will usually sync from
the "primary", though that's not required either.  This is why early on
some folks started calling the slaves "secondary" servers (and thus why
the configuration "type" parameter identifying a slave zone in BIND-4's
named.boot file was given the value "secondary").  Thankfully BIND-8's
configuration file syntax eliminates this confusion again by using the
keywords "master" and "slave".

-- 
								Greg A. Woods

+1 416 218-0098;  <gwoods@acm.org>;  <g.a.woods@ieee.org>;  <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>