Re: [DNSOP] Question regarding RFC 8499

[Joe Abley <[e-mail]>]

On 23 Jul 2020, at 13:24, Robert Edmonds <[e-mail]> wrote:

> 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.

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