You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Regarding the DNS, I think it's worth pointing out that the old
terminology is actively misleading, because the upstream side of a zone
transfer is unable to command the downstream side to do anything: all zone
transfers are demanded by the downstream side. The downstream doesn't have
to refuse the upstream, it can just do nothing.
Re. your suggested alternatives, it's useful to point out that it is often
a mistake to lazily use a binary classification. For instance it's common
to have multiple layers of replication, in which case terms like upstream
/ downstream or source / sink work better, because they don't imply a
single layer in the way other suggestions often do.
There are frequenly more than two roles, for example a database system
might have a single writable primary, readable replicas, standby replicas,
point-in-time recovery replicas, etc.
For a long time primary/secondary has been a very bad model for SMTP MX
servers, and it's a very bad model for the DNS. In the mail world it's
more common now to use more specific terms like submission agent, delivery
agent, relay server, MX server, etc., and in the DNS it's similarly more
helpful to talk about update servers, signing servers, zone transfer
servers, public authoritative servers, etc.
In general it seems to be easier to come up with better (more descriptive)
terms by discarding the binary model first, rather than trying to fit
better terms into an incorrect model.
Regarding exception lists, I like denylist rather than blocklist :-) I
have heard of cases where a system configuration has got into a horrible
tangle when they only have a notion of "blacklist" as a set of special
cases; if that is then used for exemptions to a default-deny policy then
the blacklist is an allowlist (?!?!). The metaphor was too weak to support
the functionality it was supposed to describe, so it caused confusion.
The text was updated successfully, but these errors were encountered:
Regarding the DNS, I think it's worth pointing out that the old
terminology is actively misleading, because the upstream side of a zone
transfer is unable to command the downstream side to do anything: all zone
transfers are demanded by the downstream side. The downstream doesn't have
to refuse the upstream, it can just do nothing.
Re. your suggested alternatives, it's useful to point out that it is often
a mistake to lazily use a binary classification. For instance it's common
to have multiple layers of replication, in which case terms like upstream
/ downstream or source / sink work better, because they don't imply a
single layer in the way other suggestions often do.
There are frequenly more than two roles, for example a database system
might have a single writable primary, readable replicas, standby replicas,
point-in-time recovery replicas, etc.
For a long time primary/secondary has been a very bad model for SMTP MX
servers, and it's a very bad model for the DNS. In the mail world it's
more common now to use more specific terms like submission agent, delivery
agent, relay server, MX server, etc., and in the DNS it's similarly more
helpful to talk about update servers, signing servers, zone transfer
servers, public authoritative servers, etc.
In general it seems to be easier to come up with better (more descriptive)
terms by discarding the binary model first, rather than trying to fit
better terms into an incorrect model.
Regarding exception lists, I like denylist rather than blocklist :-) I
have heard of cases where a system configuration has got into a horrible
tangle when they only have a notion of "blacklist" as a set of special
cases; if that is then used for exemptions to a default-deny policy then
the blacklist is an allowlist (?!?!). The metaphor was too weak to support
the functionality it was supposed to describe, so it caused confusion.
The text was updated successfully, but these errors were encountered: