[Doh] Comments on draft-hoffman-resolver-associated-doh-07

[Alexander Dupuy <[e-mail]>]

Not to derail the current thread on whether browsers or other applications
should use non-system resolvers, but as somebody working on a large public
resolver with experimental support for DoH, I have some comments on the
draft that a colleague encouraged me to share.

In particular, I'm concerned that the two Special Use Domain Names
(resolver-associated-doh.arpa and resolver-addresses.arpa) in draft-07
(henceforth just "draft-07 SUDNs") will get SERVFAIL when a forwarding DNS
resolver is performing DNSSEC validation, but does not support DoH or the
draft-07 SUDNs, even though the DNS resolver that it is forwarding to *does*
support DoH and the draft-07 SUDNs.

Attempts to resolve the draft-07 SUDNs in this scenario will get SERVFAIL
because the IANA Considerations section of draft-07 specifies that IANA
MUST NOT delegate the draft-07 SUDNs, and as a result, there will be no
proof of insecure delegation for those domains, nor any DNSSEC signatures
that would validate any answer other than the provable NXDOMAIN (using NSEC
records from the .ARPA zone). In this situation, somewhat like the
discarded approach of a special root domain record type, a DNSSEC
validating resolver will fail validation of any non-NXDOMAIN response. If
the forwarding resolver implements RFC 8198 (Aggressive Use of
DNSSEC-Validated Cache), it might well never forward queries for these
names at all, instead synthesizing an NXDOMAIN response from those cached
.ARPA NSEC records.

Perhaps this is intentional, but if so, it is inconsistent, since a
non-DNSSEC-validating forwarding DNS resolver in this scenario would pass
through queries and responses for the draft-07 SUDNs without any problems.
The scenario where a forwarding resolver is performing its own DNSSEC
validation is not common, but I know that it exists for some of our
clients, and it seems undesirable that they would see a different outcome
simply because they are being diligent about DNSSEC validation.

If this is not intentional (and the expectation is that any forwarding
resolver that wants to control DoH discovery in any way must do so by
handling the SUDNs used for this discovery), then another approach is
needed, one that doesn't depend on updates to intermediate
DNSSEC-validating resolvers.

Mandating insecure delegations in the .ARPA zone for those names (or better
yet, modifying the SUDNs so that they both would fall under a single
insecure delegation from .ARPA) would allow resolvers to create their own
responses that would not fail DNSSEC-validation. If there are political
reasons (reated to ICANN or IANA) that this can't be mandated for a new
subdomain of .ARPA, use of some other TLD might be an option, although it's
less desirable.

The insecure delegation NS records for the zone with the TXT and A/AAAA
records for the local resolver could either point to an AS112 RFC 7534
resolver name like blackhole-[12].iana.org or perhaps better,
blackhole.as112.arpa (which could serve a copy of the existing
empty.as112.arpa zone file for a new resolver-doh.arpa zone).

On the other hand, if it is explicitly desired that DoH discovery should
*not* pass through forwarding resolvers, then another approach that will
also fail even without DNSSEC validation by the forwarding resolver should
be used. I'm not sure what would be best in that case,. Historically, use
of queries with CHAOS class that will not transit a resolver is common, and
more recently EDNS options seem to be preferred, but neither approach would
permit identifying the resolver IP address in use when an application is
limited to using gethostbyname() library calls. Using a subdomain of an
existing SUDN like localhost might do the trick although there would likely
be a lot of variability in how that might or might not work (like the
draft-07 SUDNs, it would fail DNSSEC validation, but it would probably
still transit some resolvers that only special-case localhost and not
resolver-addresses.localhost or similar names). In the end, it might be
best to explicitly allow the resolver-addresses to transit (to an
insecurely delegated .ARPA domain), but use CHAOS or EDNS to get the
resolver's DoH information.

-- 
Alexander Dupuy |  Software Engineer |  [e-mail] |  +1
646-462-3568