Subject: [Doh] Resolver-associated comments (mike follow-up)

From: Brian Dickson <[email-masked]>
Date: Tue, 26 Mar 2019 14:47:01 +0100

Hi, DoH folks,

At the mike I had some comments, but it was recommended I put them on-list.
This is that.

One of the non-obvious challenges in any migration from a strict
DNS-over-UDP to anything else, is that there are some interesting DNS
topologies involving DNS Forwarders.

The basic UDP resolution path would generally be:
stub -> forwarder -> [forwarder ->][...] -> recursive/iterative resolver

This creates ambiguity in any single-common-name response(s) in elevating
from Do53 to Do{HT}.

Upgrades from traditional DNS forwarder, to Do{TH}, possibly still acting
as a forwarder, is the fundamental issue. It is possible that more than one
forwarder is upgraded. It is also not possible to determine which
forwarder(s) have upgraded. Since Do{TH} involves the client placing a
significant amount of trust (for privacy, security, and data integrity) in
the upgraded server, this seems important.

The idea is that a client would first do discovery of the names of upgraded
servers, and that the client would then select from those names (either via
configured preferences, or via a UI), and use that name for Do{TH}
connection to the selected server, explicitly and by name. This would
facilitate TLS validation of the name, which I believe improves the
security in ways that the current mechanisms don't seem to do.

I suspect this would require a new reserved query name or possibly new
opcode for the query.

It might require that the first responding server discover its upstream
forwarder/resolver name, and return both those upstream names plus its own
name.

It does involve some degree of trust and transitive trust, but the
configuration of a DNS server inherently involves trust.

These are just initial thoughts, but I think there is potential solutions,
or at least problems, that might be in the above stuff.

Comments welcome.

Brian