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

Thu Mar 12 04:59:21 UTC 2020

> On Mar 11, 2020, at 19:25 , Jan Schaumann <jschauma at netmeister.org> wrote:
> 
> 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.)

When you change the way a system works and make the new
behavior “opt-out”, especially when you present the option in
such a misleading way, I’ll stand by my statement.

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

Yeah, the part they leave out is that name servers like 2001:4860:4860::8888 and 2001:4860:4860::8844 are on that list.

> 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 you think that the average internet user has a sufficient level of understanding
to make an informed choice about this, let alone implement said choice?

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

OK, but what about the network operator’s ability to defend against an untrusted user?

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

Right… Now put yourself in the position of a typical parent who works in a widget
factory and has all the skills necessary to find the power switch on a computer. Said
parent’s pre-teen child decides that DoH can lock dad out of snooping her web-surfing
and chat room choices and, so, enables it. Dad, in the meantime, has decided to
depend on the Disney service that came bundled with his Netgear router and is
assuming that has him covered there and won’t allow her to resolve adult sites and
risky chatrooms.

Do you not see a problem here?

Owen