Difference between secondary and slave dns servers

[Sam Wilson]

In article <eji1i0$24hq$1 at sf1.isc.org>,
 "voipfc" <voipfc at googlemail.com> wrote:

> Do I take it that the additional servers that you register for your
> domain with your domain registrar are also considered authoritative for
> the domain?

They certainly are.

> That is the distinction I want to make. I understand that records can
> be updated from one master which will update the records to the slaves
> for the sake of convenience, or that the slaves are updated with the
> master's whole database through some replication mechanism.

The replication is done per zone (zone transfer or AXFR) or per change 
within a zone (incremental, IXFR).

> If for instance records are created via a tool that updates all the
> servers listed simultaneously without any of the servers getting
> updated with other servers records via notify, would there still be a
> master/slave relationship between the servers themselves or would that
> notion only exist with the domain registrars records.

If you use a non-DNS protocol to update then all servers are, in DNS 
terms, masters even though the authoritative data source - the real 
"master" - is external to the DNS.  If you do things this way then you 
can't do dynamic DNS sensibly since that relies on updating a master 
server which can then propagate changes to the slaves.

> Does this mean that the slaves have the zones as master zone, only the
> SOA still refers to a single master?

If you use the external non-DNS master model then the SOAs don't matter 
so much, but if you make them different you're liable to confuse people 
who might want to debug things.  There are people here (I think) who use 
that model and may offer different advice.

FWIW to confuse things a little more there are several sets of servers 
we could be discussing here.  There's the set in the registrar's 
records.  This should be the same as the set in the delegation in the 
parent domain (because, we hope, that's how the delegation NS records 
are generated).  Then there's the set in the zone itself.  These ought 
to be kept in step with the ones in the parent domain, i.e. you ought to 
keep them in step - there is no automatic mechanism to do it for you.  
This set is authoritative - the ones in the parent domain are hints to 
let resolvers find the authoritative ones.  Then the list of servers in 
the zone may not be the only servers which serve the zone - you can have 
stealth servers which your clients can use but aren't advertised to the 
rest of the world in NS records (and this is a recommended 
configuration).  In fact the primary master server may not be named in 
an NS record (stealth master) but it ought to be in the SOA record.

Does that help?

Sam