starred/hickory-dns

Fork 0

mirror of https://github.com/hickory-dns/hickory-dns.git synced 2026-04-25 11:15:54 +03:00

[GH-ISSUE #572] Discussion: replace all master/slave references in docs and code #242

New issue

Closed

opened 2026-03-07 22:58:04 +03:00 by kerem · 7 comments

kerem commented

2026-03-07 22:58:04 +03:00

Owner

Originally created by @bluejekyll on GitHub (Oct 7, 2018).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/572

As we get closer to working on substantive pieces related to primary and secondary instances, with some acting as sources of truth, and others as caching or backup systems, I think this is a good time to discuss naming options.

I know this is contentious, but what I want is both something techinically clear and yet also not reminiscent of oppressive concepts. We will remove all mention of ‘slave’ and possibly ‘master’, with one exception and that’s for backward and cross compatibility with other systems (ie read from configs and accept ‘slave’, but translate to the new replacement term). Should we also replace ‘master’ there will be one exception to where it won’t be replaced, and that’s “master files”, referring to the zone configuration files, as that is out of scope. We can also change it, but that would be a separate discussion.

This follows on from a whimsical idea I had in #570, of using ‘queen’/‘drone’, but even that was pointed out as having potential of not referring to bees and the hive queen.

As ideas are put forward, I’ll capture them here (order does not imply importance). As we think through names, remember that we may have scenarios where there are multiple primaries (active/active) configurations:

‘leader’/‘follower’
‘primary’/‘secondary’
‘teacher’/‘learner’

Originally created by @bluejekyll on GitHub (Oct 7, 2018). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/572 As we get closer to working on substantive pieces related to primary and secondary instances, with some acting as sources of truth, and others as caching or backup systems, I think this is a good time to discuss naming options. I know this is contentious, but what I want is both something techinically clear and yet also not reminiscent of oppressive concepts. We will remove all mention of ‘slave’ and possibly ‘master’, with one exception and that’s for backward and cross compatibility with other systems (ie read from configs and accept ‘slave’, but translate to the new replacement term). Should we also replace ‘master’ there will be one exception to where it won’t be replaced, and that’s “master files”, referring to the zone configuration files, as that is out of scope. We can also change it, but that would be a separate discussion. This follows on from a whimsical idea I had in #570, of using ‘queen’/‘drone’, but even that was pointed out as having potential of not referring to bees and the hive queen. As ideas are put forward, I’ll capture them here (order does not imply importance). As we think through names, remember that we may have scenarios where there are multiple primaries (active/active) configurations: ‘leader’/‘follower’ ‘primary’/‘secondary’ ‘teacher’/‘learner’

kerem

2026-03-07 22:58:04 +03:00

closed this issue
added the
question
label

kerem commented

2026-03-07 22:58:20 +03:00

Author

Owner

@moonshiner commented on GitHub (Oct 7, 2018):

I've been known to run some DNS Infrastructure, and I never used master/slave, always primary/secondary. But I've been hammering on the DNS s/w vendors for a few years now that the "1 primary/1 secondary" server configuration that is every deployment document is quaint and outdated.

There is this other term "hidden master" which I don't like also. In reality what one has is a key-value data store (not really a database) that is replicated across more than 1 servers. Maybe we're viewing this through the lens of history ?

I'll get off my soapbox.

@moonshiner commented on GitHub (Oct 7, 2018): I've been known to run some DNS Infrastructure, and I never used master/slave, always primary/secondary. But I've been hammering on the DNS s/w vendors for a few years now that the "1 primary/1 secondary" server configuration that is every deployment document is quaint and outdated. There is this other term "hidden master" which I don't like also. In reality what one has is a key-value data store (not really a database) that is replicated across more than 1 servers. Maybe we're viewing this through the lens of history ? I'll get off my soapbox.

kerem commented

2026-03-07 22:58:25 +03:00

Author

Owner

@bluejekyll commented on GitHub (Oct 7, 2018):

I think you’re right about the historical context.

I want to enable active/active scenarios, across highly latent areas (how, I don’t know yet exactly). In that scenario there isn’t really even a ‘secondary’ so to speak.

@bluejekyll commented on GitHub (Oct 7, 2018): I think you’re right about the historical context. I want to enable active/active scenarios, across highly latent areas (how, I don’t know yet exactly). In that scenario there isn’t really even a ‘secondary’ so to speak.

kerem commented

2026-03-07 22:58:30 +03:00

Author

Owner

@hawkw commented on GitHub (Oct 16, 2018):

Personally, I think "primary"/"secondary" is the clearest language in this case --- I think "leader"/"follower" more accurately reflects a scenario where one component in a system drives or controls the operation of another; when the "secondary" component is acting in a backup role, I think "primary"/"backup" or "active"/"standby" also works.

IMO the use of "master" without a counterpart to refer to an authoritative copy or source of truth for a piece of data reflects the use of "masters" in the audio industry to refer to the authoritative copies of an audio recording. AFAIK this usage, such as in "master files", is not considered offensive, but I defer to someone with more knowledge to confirm that.

@hawkw commented on GitHub (Oct 16, 2018): Personally, I think "primary"/"secondary" is the clearest language in this case --- I think "leader"/"follower" more accurately reflects a scenario where one component in a system drives or controls the operation of another; when the "secondary" component is acting in a backup role, I think "primary"/"backup" or "active"/"standby" also works. IMO the use of "master" without a counterpart to refer to an authoritative copy or source of truth for a piece of data reflects the use of "masters" in the audio industry to refer to the authoritative copies of an audio recording. AFAIK this usage, such as in "master files", is not considered offensive, but I defer to someone with more knowledge to confirm that.

kerem commented

2026-03-07 22:58:35 +03:00

Author

Owner

@tarqd commented on GitHub (Dec 8, 2018):

I've always been a fan of primary/replica or master/replica myself. For DNS specifically authority/replica might be a better way to describe the relationship

@tarqd commented on GitHub (Dec 8, 2018): I've always been a fan of primary/replica or master/replica myself. For DNS specifically authority/replica might be a better way to describe the relationship

kerem commented

2026-03-07 22:58:40 +03:00

Author

Owner

@vorner commented on GitHub (Jan 14, 2021):

❓ Looking at this… should this get resolved on some globalish DNS-standards mailing list first, so everyone has the same ones instead of each implementation coming up with independent names to describe it? What do the RFCs use? Should any changes start there?

@vorner commented on GitHub (Jan 14, 2021): :question: Looking at this… should this get resolved on some globalish DNS-standards mailing list first, so everyone has the same ones instead of each implementation coming up with independent names to describe it? What do the RFCs use? Should any changes start there?

kerem commented

2026-03-07 22:58:45 +03:00

Author

Owner

@moonshiner commented on GitHub (Jan 14, 2021):

We're currently updating RFC8499 https://www.rfc-editor.org/rfc/rfc8499.html to address the language and add a few teams like DoH (DNS-over-HTTPS), DoT (DNS-over-TLS), etc.

https://tools.ietf.org/html/draft-ietf-dnsop-rfc8499bis-01

Folks are more than welcome to weigh in, offer opinions, etc.!
tim
(co-chair DNS OPerataions)

@moonshiner commented on GitHub (Jan 14, 2021): We're currently updating RFC8499 https://www.rfc-editor.org/rfc/rfc8499.html to address the language and add a few teams like DoH (DNS-over-HTTPS), DoT (DNS-over-TLS), etc. https://tools.ietf.org/html/draft-ietf-dnsop-rfc8499bis-01 Folks are more than welcome to weigh in, offer opinions, etc.! tim (co-chair DNS OPerataions)

kerem commented

2026-03-07 22:58:51 +03:00

Author

Owner

@bluejekyll commented on GitHub (Jan 14, 2021):

Ugh, I never connected this to the PR that resolved this: #1141

We changed to primary/secondary, but allow for backward compatibility.

@moonshiner, Thanks for pushing this forward!

@bluejekyll commented on GitHub (Jan 14, 2021): Ugh, I never connected this to the PR that resolved this: #1141 We changed to `primary`/`secondary`, but allow for backward compatibility. @moonshiner, Thanks for pushing this forward!

kerem referenced this issue

2026-03-16 01:59:59 +03:00

[PR #242] [CLOSED] Allow resolver to be used without openssl. #1320