Subject: Re: DNSEXT WGLC AXFR-02 SHORT last call

From: Paul A Vixie <[email-masked]>
Date: Wed, 04 Jul 2001 13:06:27 -0700

> ... Using your terminology, all of them are master.

No, using my terminology, all of them are authoritative.

> For bind yes, that would have been fine.   The redundancy helps detect
> broken configurations though (better human interface).

That was my view at the time I did it, but I'm less certain now.

> For other specs we (sometimes) need a way to categorise the status of a
> server for the zone however, so we do need terms.

A server does not have a type, other than "authoritative for zero zones"
vs. "authoritative for at least one zone".

A server's relationship to a zone does not have a type, it has attributes:

	either authoritative for a zone, or not

	if authoritative:

		gets its zone data through the DNS (AXFR/IXFR), or not

		allows other servers to get copies of the zone data
		through DNS (AXFR/IXFR), or not

> Nonsense - master==primary and slave==secondary - all that altered was
> the word being used.   There's no other distinction at all.

That was not my intent.  Referring to RFC 1996, some masters are also slaves,
because in RFC 1996 what's being described are roles taken during AXFR/IXFR,
which NOTIFY needed to stratify and declare.

Primary/Secondary was absolutely wrong.  Master/Slave is almost as wrong.

> And none of this explains how we need the redundant combination
> "primary master".

It's a master that is never a slave.  When DNS is being used (AXFR/IXFR) to
propagate zone data, you need a name for the server:zone relationship that
fetches the zone from outside the DNS, as for example a disk file or database.
When DNS is not being used (AXFR/IXFR) to propagate zone data, then all you
know about a server is that it is authoritative, since it is neither primary,
nor secondary, nor master, nor slave.  We all mistakenly call these "masters"
because we've fallen into the trap of using types to define relationships
between servers and zones, when we need to be using attributes.

> Apologies if it seemed to be that way - that wasn't what I intended.

Apology accepted, of course.

> All I intended was to point out that the advocate for using these terms
> has been you, all of this time.   It has not come from anywhere else.

Nevertheless I believed, until this week, that I had explained the issues
clearly and won general acceptance for "attributes rather than types" back
when RFC 1996 was being debated and prepared.

Servers, btw, don't have types either.  A server with zero authority zones
could be either recursive or not, and caching or not.  So could a server with
one or more authority zones.  We have got to stop thinking about servers
having types, or a server's relationships to its zones (if any) having types,
and start back in with attributes.

The only use of the type distinction { master, slave } is to talk about what
happens over an AXFR/IXFR transaction.  Whereas the type distinction between
{ primary, secondary } has broader meaning, both in RFC1034/5, and in the
field.  I'm ready to admit that both are confusing, that RFC 1996 should have
used terms like "transfer initiator" and "transfer responder", and that the
term "primary master" should have been written "non-DNS zone data origin".

But that's a far cry from "let's go back to primary/secondary", because those
terms are meaningless to the protocol, however useful you may find them over
in the dnsops wg or how useful we may find them in the field.

to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.

---

From: Robert Elz <[email-masked]>
Date: Thu, 05 Jul 2001 05:33:15 -0700

Date:        Wed, 04 Jul 2001 13:06:27 -0700
    From:        Paul A Vixie <[email-masked]>
    Message-ID:  <[email-masked]>

  | A server's relationship to a zone does not have a type, it has attributes:

The type is just an attribute.   In this case it is the attribute that
tells the server how it loads the zone.   We call it "primary" for the
zone if it loads the data from a file.  We call it "secondary" if it
loads the data via AXFR (or IXFR).

That's how it has been since forever.

  | That was not my intent.  Referring to RFC 1996, some masters are also slaves,
  | because in RFC 1996 what's being described are roles taken during AXFR/IXFR,
  | which NOTIFY needed to stratify and declare.

As Otha-san said in his reply to me, client/server is the standard
terminology to describe those roles.

We didn't need to invent new terminology for this.

  | It's a master that is never a slave.

That may have been useful in 1996 (though I'd have to think about it
a bit more to see if it really makes sense even there), but here in the
description of AXFR, it makes no sense at all - all that matters to this
doc are the two end points of one AXFR transaction.

  | When DNS is not being used (AXFR/IXFR) to propagate zone data, then all you
  | know about a server is that it is authoritative,

Yes - there's way to much demand for primary/secondary info which makes
no sense (including when domains are registered - all that the parent needs
to know is a list of servers, asking which server is primary is none of its
business).

  | since it is neither primary, nor secondary, nor master, nor slave.

But that's not right - it is primary or secondary - it fetched the data
from somewhere after all.   What isn't available is any way for any
outsider to discover that information.

  | Nevertheless I believed, until this week, that I had explained the issues
  | clearly and won general acceptance for "attributes rather than types" back
  | when RFC 1996 was being debated and prepared.

That battle would have made no sense, because the type just is one of
the attributes - that is, you're arguing for fruit rather than apples...

If the point had been that there are other attributes than the type,
then yes, that's correct, but that never seemed to really be it.

At the time (as best I remember it, which might not be all that good)
the point seemed to be that to call a server "primary" was wrong, what
it is is primary for some particular zone.

  | The only use of the type distinction { master, slave } is to talk about what
  | happens over an AXFR/IXFR transaction.

No it isn't.   That is one use - and for that one, client/server would
be better terms.   But there are also a whole bunch of operational issues
where the source of the data is important.   If I see two servers with
different SOA.serial values for a zone, I want to know the relationship
between the servers.  If the one with the larger serial is primary for the
zone, and the one with the smaller serial is secondary, then I go back to
sleep for a while, as this is a normal situation.  If they're both secondary,
then I see if I can find the primary, and repeat the test using it, with
each of the secondaries.   In other cases, there's a problem that needs to
be fixed.

  | But that's a far cry from "let's go back to primary/secondary",
  | because those terms are meaningless to the protocol,

Any term is meaningless to the protocol, which is just shovelling bits
from place to place.  For the spec of the protocol, any term would do
to describe anything that we want it to describe - we just define it.
But when doing that, it makes sense to use terms which have as many of
the following attributes as we can find (presented in no particular order,
which is more important will vary from case to case).   First, it helps
if they're easy to read, understand and remember.  Second it helps if
they naturally suggest the meaning defined for them.  Third it helps if
they're terms used for much the same function other places in the same
protocol set.  Fourth it helps if they're the same terms used for similar
operations in other protocols.

We could use primary/secondary, we could use client/server - each of those
meets some of the requirements.   Master/slave meets fewer - it is new
terminology to the DNS (it was anyway), it isn't used in other protocols,
and it would normally suggest that the master is in control, and the slave
is doing what it is told, whereas the way it is being used for AXFR, it is
the slave that initiates everything, the master just responds with the data
it has been told to send...

So, while we're not going to rewrite 1996 just now, to rid us of the
terms that should never have been used, there's no point continuing with
their usage in new docs.   Just use client/server to describe the roles
played in an AXFR transfer, it is much simpler.

kre

---

From: Kevin Darcy <[email-masked]>
Date: Thu, 05 Jul 2001 10:46:59 -0700

I think the terminology suffers from trying to straddle two different scopes at
once. When the scope is *transactional*, what matters is which node is the initiator
of the transaction, and which node is the responder. At a transactional scope,
I agree with Robert and Ohta-san that "client/server" is perfectly good terminology;
it's well understood and consistent with the terminology used in other protocols.

But DNS zone-data replication is more than just an episodic series of unrelated
transactions. When the scope of the terminology is to describe the role of a
particular nameserver in an *infrastructure*, something more descriptive than
"client" or "server" is called for. This is because the infrastructure may have a
multiple-level dependency graph, where a given node might be a "client" for the
transfer of a particular zone at one moment, and then the next moment turn around
and be the "server" for the transfer of that zone. And let's not foreclose the
possibility that a future extension of the protocol may allow a "master" server (to
use the BIND terminology) to *push* a zone transfer to a "slave" server. This
possibility makes the "client/server" terminology even less useful/desirable as a
way to label nodes in a DNS infrastructure.

>From an infrastructure or data-flow perspective, what is important is not which node
initiates any given transfer transaction, but where the data enters the system, and
where/how it gets replicated from there. Perhaps the optimal terms to use at this
scope are "origin" and "replica". In the case of a multiple-level dependency graph,
the replicas can be differentiated as "tier 1 replicas", "tier 2 replicas" and so
forth.

The "primary/secondary" terminology has proven to be confusing to novices. It seems
to imply a sequential ordering, and many novices take that to mean that, in the
context of NS selection, nameservers will attempt to contact the "primary" NS and
only if that fails, resort to contacting the "secondary" NS. Obviously, that's not
how it works in practice, but the terminology misleads some people into thinking
that. Moreover, sometimes "primary" and "secondary" are used to refer to the first-
and second-listed nameservers in a stub resolver configuration, thus muddying the
waters even more.

I agree that "master" and "slave" are also slightly misleading, because they imply
that one node -- the master -- exercises some form of direct control over another
node -- the slave -- with respect to replication, when in actual fact the "slave"
operates somewhat autonomously. It can ignore a NOTIFY if it wants to, or defer a
refresh if it happens to be overloaded. The coupling between authoritative servers
of a zone using AXFR/IXFR for replication, is perhaps too loose for the
"master/slave" terminology to be appropriate -- it perhaps implies a degree of
control that simply doesn't exist.

So, to summarize, while I'm not completely comfortable with the "master/slave"
terminology, I consider it preferable to "client/server" in general (perhaps because
I am an administrator I care more about describing DNS infrastructure than I do
about the minutiae of particular zone-transfer transactions), and far preferable to
"primary/secondary", which is just downright confusing and/or misleads many folks.

- Kevin