DNS Recursive Operators: Please enable QNAME minimization (RFC7816) for the enhanced privacy of your users

Jan Schaumann jschauma at netmeister.org
Thu Mar 12 02:25:26 UTC 2020


Owen DeLong <owen at delong.com> wrote:

> DOH isn?t inherently bad, but every implementation
> of DOH that I am aware of involves depriving the
> user of choice and/or control

I don't think that's quite correct.

There is an unfortunate and persistent conflation of
"DoH" with "DoH to a centralized third-party
resolver"; that is largely Mozilla's fault, but even
for Firefox the argument can be made that that is not
_depriving_ the user of choice, but enabling their
choice.  (Defaults being seen as no-choice seems a
stretch, even if we know the majority of users will
not (know how to) change the defaults.)

Google, for example, has noted that they have no plans
to follow Mozilla's example, and instead will only use
DoH if the local stub resolver in question is on
their explicit shortlist of DoH resolvers.

That is, the user (or the organization controlling the
end-point) have already set the stub resolver to that
service; if the user changes the stub resolver to
point to some other IP, then Chrome will _not_
override that and use DoH to e.g., Google's public
resolver.

> and also depriving network operators of the ability
> to enforce the ?my network, my rules? concept.

The network operator has _some_ control, but that
control is limited by design, as the primary threat
model for DoH and especially for _DoH to a third-party
resolver_ is to defend against an untrusted network
operator.

That is indeed the argument of increased choice made
by Mozilla: if a user explicitly enables DoH to a
given server, they can enable it to be mandatory with
no fallback and the network operator cannot change
that.  (Unless the network operator is also in control
of the user's device, of course.)

-Jan



More information about the NANOG mailing list