Subject: [DNSOP] Question regarding RFC 8499

From: Michael De Roover <[email-masked]>
Date: Wed, 22 Jul 2020 01:00:43 +0200

Hello,

I've read through RFC 8499, and found some things I considered odd. 
Particularly page 14 and 19 which describe the "master files" and the 
"primary" and "secondary" servers.

In most of the DNS-related documentation I've read so far, the "master 
files" are often called zone files. I find it strange that in the RFC 
this is only acknowledged, rather than defined into its own term and 
prioritized.

Regarding the primary and secondary servers, it's a fair euphemism but 
this among further fracturing of nomenclature in other projects makes 
this definition very fragmented (master/slave is now primary/secondary, 
main, parent/child, etc). This is something I find unnecessary and 
harmful, as it creates confusion while merely redefining the same. It 
also unnecessarily obsoletes older documentation. Newcomers to the DNS 
could become confused. I was very confused when I recently built my own 
DNS server infrastructure.

The discussion regarding these tends to get emotional and political, but 
I feel like these should be kept outside of standards bodies. Just like 
we are still stuck with 29.97 Hz refresh rates on televisions from 
implementations half a century ago, these changes could also affect 
those half a century from now on.

-- 
Met vriendelijke groet / Best regards,
Michael De Roover

---

From: "libor.peltan" <[email-masked]>
Date: Thu, 23 Jul 2020 10:47:42 +0200

Hi,

just a factual comment.

While primary/secondary = master/slave is indeed a recent transition of 
terms among DNS community, and I agree that this should be handled 
carefully when writing new RFCs,

parent/child is a different relation: `com.` domain is the parent of 
`example.com.`.

I haven't heard about "main".

BR,

Libor

Dne 22.07.20 v 01:00 Michael De Roover napsal(a):
> this definition very fragmented (master/slave is now 
> primary/secondary, main, parent/child, etc). This is something I find 
> unnecessary and harmful, as it creates confusion while merely 
> redefining the same. It also unnecessarily obsoletes older 
> documentation. Newcomers to the DNS could become confused. I was very 
> confused when I recently built my own DNS server infrastructure.
>
> The discussion regarding these tends to get emotional and political, 
> but I feel like these should be kept outside of standards bodies. Just 
> like we are still stuck with 29.97 Hz refresh rates on televisions 
> from implementations half a century ago, these changes could also 
> affect those half a century from now on.
>

---

From: Paul Vixie <[email-masked]>
Date: Thu, 23 Jul 2020 08:50:06 +0000

> carefully when writing new RFCs,

i introduced the master/slave terminology in rfc 2136, because i needed names 
for the roles in an AXFR/IXFR transaction, and the zone transfer hierarchy 
could be more than one layer deep, such that a server might initiate some 
AXFR/IXFR's to the "primary master" but then respond to AXFR/IXFR's from other 
servers. in retrospect i should have chosen the terms, "transfer initiator" 
and "transfer responder". however, the hydraulic brake and clutch systems in 
my car had "master cylinders" and "slave cylinders", and so i did not think i 
was either inventing a new use for the words "master" and "slave", or that my 
use of them for this purpose would be controversial. i was naive, and i 
suggest that we revisit the terminology we use in all our distributed systems, 
starting with DNS zone transfer roles.

> ...

-- 
Paul

---

From: tjw ietf <[email-masked]>
Date: Thu, 23 Jul 2020 05:09:52 -0400

I’ve had several conversations with one of the 8499 authors a few months back and said that we need to adjust this. I let it drop but the topic was going to be part two f our chairs slides next week. 

The chairs did some reviewing of all Currently adopted documents as well. 

Thanks 
Tim 

Sent from my iPhone

> On Jul 23, 2020, at 05:02, Paul Vixie <[email-masked]> wrote:
> 
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Robert Edmonds <[email-masked]>
Date: Thu, 23 Jul 2020 13:24:49 -0400

Michael De Roover wrote:
> Regarding the primary and secondary servers, it's a fair euphemism but this
> among further fracturing of nomenclature in other projects makes this
> definition very fragmented (master/slave is now primary/secondary, main,
> parent/child, etc). This is something I find unnecessary and harmful, as it
> creates confusion while merely redefining the same.

"Primary" and "secondary" are not euphemisms or later re-definitions.
They appear extensively throughout STD 13 and appear to be the preferred
nomenclature, e.g. in the below description of zone transfers from RFC
1034. "Slave" does not appear anywhere in STD 13 to the best of my
knowledge; the closest reference is to "non-master" servers.

Mockapetris                                                    [Page 27]

RFC 1034             Domain Concepts and Facilities        November 1987

4.3.5. Zone maintenance and transfers

Part of the job of a zone administrator is to maintain the zones at all
of the name servers which are authoritative for the zone.  When the
inevitable changes are made, they must be distributed to all of the name
servers.  While this distribution can be accomplished using FTP or some
other ad hoc procedure, the preferred method is the zone transfer part
of the DNS protocol.

The general model of automatic zone transfer or refreshing is that one
of the name servers is the master or primary for the zone.  Changes are
coordinated at the primary, typically by editing a master file for the
zone.  After editing, the administrator signals the master server to
load the new zone.  The other non-master or secondary servers for the
zone periodically check for changes (at a selectable interval) and
obtain new zone copies when changes have been made.

To detect changes, secondaries just check the SERIAL field of the SOA
for the zone.  In addition to whatever other changes are made, the
SERIAL field in the SOA of the zone is always advanced whenever any
change is made to the zone.  The advancing can be a simple increment, or
could be based on the write date and time of the master file, etc.  The
purpose is to make it possible to determine which of two copies of a
zone is more recent by comparing serial numbers.  Serial number advances
and comparisons use sequence space arithmetic, so there is a theoretic
limit on how fast a zone can be updated, basically that old copies must
die out before the serial number covers half of its 32 bit range.  In
practice, the only concern is that the compare operation deals properly
with comparisons around the boundary between the most positive and most
negative 32 bit numbers.

The periodic polling of the secondary servers is controlled by
parameters in the SOA RR for the zone, which set the minimum acceptable
polling intervals.  The parameters are called REFRESH, RETRY, and
EXPIRE.  Whenever a new zone is loaded in a secondary, the secondary
waits REFRESH seconds before checking with the primary for a new serial.
If this check cannot be completed, new checks are started every RETRY
seconds.  The check is a simple query to the primary for the SOA RR of
the zone.  If the serial field in the secondary's zone copy is equal to
the serial returned by the primary, then no changes have occurred, and
the REFRESH interval wait is restarted.  If the secondary finds it
impossible to perform a serial check for the EXPIRE interval, it must
assume that its copy of the zone is obsolete an discard it.

When the poll shows that the zone has changed, then the secondary server
must request a zone transfer via an AXFR request for the zone.  The AXFR
may cause an error, such as refused, but normally is answered by a
sequence of response messages.  The first and last messages must contain

Mockapetris                                                    [Page 28]

RFC 1034             Domain Concepts and Facilities        November 1987

the data for the top authoritative node of the zone.  Intermediate
messages carry all of the other RRs from the zone, including both
authoritative and non-authoritative RRs.  The stream of messages allows
the secondary to construct a copy of the zone.  Because accuracy is
essential, TCP or some other reliable protocol must be used for AXFR
requests.

Each secondary server is required to perform the following operations
against the master, but may also optionally perform these operations
against other secondary servers.  This strategy can improve the transfer
process when the primary is unavailable due to host downtime or network
problems, or when a secondary server has better network access to an
"intermediate" secondary than to the primary.

-- 
Robert Edmonds

---

From: Joe Abley <[email-masked]>
Date: Thu, 23 Jul 2020 13:38:58 -0400

> knowledge; the closest reference is to "non-master" servers.

I don't think primary/secondary are exact substitutes for master/slave in the way that those four terms are commonly used today.

STD 13 assumes a model where there is a single authoritative nameserver which acts as a source of truth for zone data ("primary"), from which other nameservers retrieve data and also make it available ("secondary"). As such they describe the whole of a simple directed graph of zone transfers.

In my experience, in common usage today, master and slave describe functions along a single edge of such a graph. A single piece of software might act as a master server on one edge, and a slave on another. As such those terms can be used to describe more complicated graphs than the particular topology imagined in STD 13.

Adding further complication, there are many deployments in which there is no single "primary" source of data as far as the zone transfer graph is concerned; the source of truth might be a different type of database altogether with its own replication schemes, and the zone transfer graph might distribute data from two or more known-consistent zone transfer sources.

I do appreciate that STD 13 mentions "master" in some cases as a synonym for "primary"; however, it doesn't mention them in a couple with "slave" and I think this is an example of where low-numbered RFCs sometimes need to be read in their historical context rather than with slavish (ho ho) devotion to individual words. I realise that RFC 8499 does the same. I think common usage is usefully different, however (e.g. see various implementations' configuration syntax).

If we are looking for alternative terminology to master/slave (which I am not against, because change is a constant and inclusiveness and awareness amongst all industries is surely to be supported and encouraged) in my opinion we should find new words and not redefine or overload the common meaning of primary and secondary.

Joe

---

From: Tim Wicinski <[email-masked]>
Date: Thu, 23 Jul 2020 13:44:17 -0400

On Thu, Jul 23, 2020 at 1:39 PM Joe Abley <[email-masked]> wrote:

>
> If we are looking for alternative terminology to master/slave (which I am
> not against, because change is a constant and inclusiveness and awareness
> amongst all industries is surely to be supported and encouraged) in my
> opinion we should find new words and not redefine or overload the common
> meaning of primary and secondary.
>
>
Actually, that does make sense. Though we also have to expect that these
existing terminology will not be replaced in the lexicon overnight.

The Chairs plan on having a few slides on this whole topic, as we've been
thinking about it for some time.

tim

---

From: Michael StJohns <[email-masked]>
Date: Thu, 23 Jul 2020 13:53:59 -0400

> If we are looking for alternative terminology to master/slave (which I am not against, because change is a constant and inclusiveness and awareness amongst all industries is surely to be supported…

One of the alternate meanings for "master" is "authoritative" (e.g. 
"master reference", "zone master file", "master recording").   
Unfortunately, that would have us end up with "the authoritative 
authoritative server" which contains the authoritative copy of the zone 
data.

I think we can find alternatives for "master/slave", I'm not sure we can 
find a good alternative to "master" in isolation nor in reference to the 
data sources.

Mike

---

From: Joe Abley <[email-masked]>
Date: Thu, 23 Jul 2020 13:55:44 -0400

On 23 Jul 2020, at 13:44, Tim Wicinski <[email-masked]> wrote:

> On Thu, Jul 23, 2020 at 1:39 PM Joe Abley <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Actually, that does make sense. Though we also have to expect that these existing terminology will not be replaced in the lexicon overnight.
> 
> The Chairs plan on having a few slides on this whole topic, as we've been thinking about it for some time. 

Allow me to preempt the inevitable infinite descent into the infinite rabbit bikeshed of naming and suggest upstream and downstream for master and slave. I feel like the DNS needs more fish analogies, even as I appreciate that we need to turn a blind eye to the shenanigans of frisky salmon as we firmly imagine data flowing only from the former to the latter.

Joe

---

From: Robert Edmonds <[email-masked]>
Date: Thu, 23 Jul 2020 14:23:06 -0400

> In my experience, in common usage today, master and slave describe functions along a single edge of such a graph. A single piece of software might act as a master server on one edge, and a slave on…

It's not the case that you can only build simple directed graph XFR
topologies using the STD 13 model. RFC 1034 describes an "intermediate
secondary" which seems to be exactly what you described, a server that
performs both XFR-in and XFR-out.

-- 
Robert Edmonds

---

From: Evan Hunt <[email-masked]>
Date: Thu, 23 Jul 2020 18:34:07 +0000

On Thu, Jul 23, 2020 at 01:38:58PM -0400, Joe Abley wrote:
> I don't think primary/secondary are exact substitutes for master/slave in
> the way that those four terms are commonly used today.
[...]
> meaning of primary and secondary.

I share the desire for perfection, but IMHO the transition from "master"
to "primary" and "slave" to "secondary" is far enough under way and well
enough understood at this point that I suspect it would be easier to add
modifiers when necessary than to try to deploy new vocabulary entirely.

-- 
Evan Hunt -- [email-masked]
Internet Systems Consortium, Inc.

---

From: Joe Abley <[email-masked]>
Date: Thu, 23 Jul 2020 14:36:42 -0400

Hi Evan,

> modifiers when necessary than to try to deploy new vocabulary entirely.

Oh, that's something I wasn't aware of. Do you have any examples of people moving from master/slave to primary/secondary?

Joe

---

From: Evan Hunt <[email-masked]>
Date: Thu, 23 Jul 2020 19:24:10 +0000

On Thu, Jul 23, 2020 at 02:36:42PM -0400, Joe Abley wrote:
> Oh, that's something I wasn't aware of. Do you have any examples of
> people moving from master/slave to primary/secondary?

Aside from RFC 8499:

| Slave server:  See "Secondary server".
|
| Master server:  See "Primary server".

... BIND added primary/secondary as synonyms for master/slave in our
configuration syntax several years ago and have been progressively updating
our documentation to prefer those terms ever since.  The upcoming release
pretty much completes that process.

---

From: Paul Vixie <[email-masked]>
Date: Thu, 23 Jul 2020 19:40:25 +0000

> modifiers when necessary than to try to deploy new vocabulary entirely.

-1. there are zones lacking primaries, and a secondary which can also talk to 
other secondaries gives a second role to those other secondaries. we must not 
simply revert to the STD 13 terminology. the role of an authority server 
depends on what zone we're talking about and what other server they're talking 
to. that's why i've recommended we stop talking about "primary servers" or 
"secondary servers", and instead talk about "transfer initiators" and 
"transfer responders", where the transfer pertains to a zone and the initiator 
or responder is a server's role with respect to that zone and that transfer.

-- 
Paul

---

From: Tony Finch <[email-masked]>
Date: Thu, 23 Jul 2020 20:59:17 +0100

Joe Abley <[email-masked]> wrote:
>
> in my opinion we should find new words and not redefine or
> overload the common meaning of primary and secondary.

Yes. I don't really like primary/secondary because it implies there are
only two categories when there aren't.

For zone transfers, each server can (and often does) have both upstreams
and downstreams, so the topology has multiple layers. Using "primary" and
"secondary" in this context often implies things that aren't true.

>From the outside point of view, an authoritative server can be used for
several functions (public auth server listed in NS records, zone transfer
server, update server, etc.) and whether it is primary or not is mostly
irrelevant.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Faeroes: Southerly or southeasterly 2 to 4, occasionally 5 in west, becoming
variable 3 or 4 later. Slight or moderate. Occasional rain. Moderate or good,
occasionally poor later.

---

From: Tony Finch <[email-masked]>
Date: Thu, 23 Jul 2020 21:10:49 +0100

Paul Vixie <[email-masked]> wrote:
>
> that's why i've recommended we stop talking about "primary servers" or
> "transfer responders"

Agreed, except that if you include notify as part of the zone transfer
machinery, the question of who is the initiator gets murky. (An upstream
starts a zone transfer process by notifying a downstream that it might
want to make a transfer request... who is taking the initiative here?)
So I prefer upstream and downstream, to match the flow of zone data.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Great Orme Head to the Mull of Galloway: West or northwest 3 or 4,
occasionally 5 near Mull of Galloway, becoming variable 3 or less later
backing south 4 or 5 later. Smooth or slight. Mainly fair. Mainly good.

---

From: Paul Vixie <[email-masked]>
Date: Thu, 23 Jul 2020 21:28:13 +0000

> So I prefer upstream and downstream, to match the flow of zone data.

notify just accelerates the schedule of the next transfer, which begins with 
an SOA check. so the fact that the notify initiator is also the transfer 
initiator is interesting, but not confusing. upness and downness are 
subjective; initiation and response are not.

-- 
Paul

---

From: Evan Hunt <[email-masked]>
Date: Thu, 23 Jul 2020 21:31:49 +0000

On Thu, Jul 23, 2020 at 07:40:25PM +0000, Paul Vixie wrote:
> -1. there are zones lacking primaries, and a secondary which can also
> talk to other secondaries gives a second role to those other secondaries.
> we must not simply revert to the STD 13 terminology. the role of an
> authority server depends on what zone we're talking about and what other
> server they're talking to. that's why i've recommended we stop talking
> about "primary servers" or "secondary servers", and instead talk about
> "transfer initiators" and "transfer responders", where the transfer
> pertains to a zone and the initiator or responder is a server's role with
> respect to that zone and that transfer.

I am visualizing a newly-hired and inexperienced administrator being
shown the ropes, and told:

- "this server is the master and that one is the slave",
- "this server is the primary and that one is the secondary", or
- "this server is the responder and that one is the initiator"

...and I think either of the first two versions would be clearer and
more informative to them than the third.

Within the specific context of discussing a zone transfer operation,
"initiator" and "responder" are clear enough, but in the broader context of
servers, service providers, and zone configurations, I don't see it as an
improvement.  (Come to think of it, even in that specific context, there's
potential confusion in the fact that a primary server could meaningfully be
said to "initiate" a transfer operation when it sends a NOTIFY.)

On the other hand, you can say "server A acts as primary for server B",
and it's fairly easy to understand even if technically neither one of
them is *the* primary.

---

From: Warren Kumari <[email-masked]>
Date: Thu, 23 Jul 2020 17:37:44 -0400

Hi all,

I wanted to point at a recently published (today!) IESG statement --
https://www.ietf.org/about/groups/iesg/statements/statement-on-oppressive-exclusionary-language/
which contains:
"We wanted to highlight that initial discussions about this topic are
taking place in the general area (a draft is slated for discussion in
GENDISPATCH at IETF 108)."

If you are interested in the topic, please attend the GENDISPATCH session...

W

On Thu, Jul 23, 2020 at 5:32 PM Evan Hunt <[email-masked]> wrote:
> ....and I think either of the first two versions would be clearer and

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Ray Bellis <[email-masked]>
Date: Fri, 24 Jul 2020 09:51:57 +0100

> been thinking about it for some time. 

Could I please throw into the mix a requirement that whatever terms we
come up with are also usable as verbs.

"master" and "slave" are both nouns and verbs.   It's very common to say
"this zone is slaved from <hostname>" and it's completely gramatically
correct.

I have been trying to avoid those words in my own language recently, but
using "primary" and "secondary" ends up creating some very awkward
language constructs because those are only adjectives and nouns and
there's no such word as "secondaried".

Ray

---

From: Martin Hoffmann <[email-masked]>
Date: Fri, 24 Jul 2020 11:28:56 +0200

Paul Vixie wrote:
> > I share the desire for perfection, but IMHO the transition from
> > "master" to "primary" and "slave" to "secondary" is far enough
> > under way and well enough understood at this point that I suspect
> > it would be easier to add modifiers when necessary than to try to
> > deploy new vocabulary entirely.

I have to agree: Primary and secondary are now used fairly consistently
in software documentation. They are about as expressive and lacking in
precision as the previous terms.

> talk to other secondaries gives a second role to those other
> secondaries. we must not simply revert to the STD 13 terminology. the
> role of an authority server depends on what zone we're talking about
> and what other server they're talking to. that's why i've recommended
> we stop talking about "primary servers" or "secondary servers", and
> instead talk about "transfer initiators" and "transfer responders",
> where the transfer pertains to a zone and the initiator or responder
> is a server's role with respect to that zone and that transfer.

The problem with this is that the initiation of a transfer and data
flow are opposite which makes this all very confusing. Reading
"initiator" and "responder", I have to stop and think "Wait, how did
XFR work again?"

Whereas primary and secondary describe the data flow in a rather
natural way. If I hear these terms, I know immediately who has which
role in this particular exchange.

The terms may not be perfect and may not precisely describe any
possible arrangement of servers one can come up with, but unless we
switch to German-style descriptive terms, we’ll always fall short. And
those descriptive terms tend to then turn into acronyms which is a
straight road into undecipherable jargon.

Side note: Whenever using "upstream" and "downstream", I’ve pretty much
always first had a half-hour discussion what each means and still later
ran into issues a la "What was downstream again?"

Kind regards,
Martin

---

From: Ray Bellis <[email-masked]>
Date: Fri, 24 Jul 2020 10:44:46 +0100

> ran into issues a la "What was downstream again?"

Upstream is "towards the source".  This works both for rivers, and for
AXFRs.

Ray

---

From: Paul Wouters <[email-masked]>
Date: Fri, 24 Jul 2020 13:48:15 -0400 (EDT)

> there's no such word as "secondaried".

This zone is replicated from <hostname>

Although replicator and replicatee does not really work :)

Maybe we can Original Server and Copy Cat :)

Paul