[Add] comments / question regarding draft-cook-doh-discovery-trial

[Daniel Migault <[e-mail]>]

Hi,

I am commenting quite late on the document, but I have a suggestion and
would be happy to hear your feed backs. Overall I like the mechanism, but I
would like to avoid the use of SUDN as it prevents the use of DNSSEC.

If the resolver is being advertised by its IP address, I would rather
rather derive the query from that IP. A FQDN based on <ip>.in-addr.arpa
(<ip>.ip6.arpa could fulfill such condition which provides the following
advantages:
* it does not require the creation of another SUDN.
* it does not require to handle a special case for the resolution and
instead proceed to standard and unchanged DNS resolution which makes it
work with any currently deployed DNS software.
* the mechanism works for resolver, and authoritative server proving DoH.
* DNSSEC can be used to protect against spoofed attacks including NXDOMAIN
responses.
* DNSSEC can be used to delegate securely to a third party DoH resolver by
providing the certificate used in the TLS session.

When used with private IP addresses [rfc6303], the DNSSEC key used to sign
the forward and reverse zone needs to be provisioned or learned with TOFU
mechanisms - which remains better than none.
With these benefits, the implementation on CPE is not much difficult than
responding dohresolver.arpa.

One difference is that the data associated with the IP address is hosted on
the authoritative server, while in the current proposal, it is the entity
receiving the data (authoritative or resolver). In both cases, the
association is the IP address value. In most CPE deployment, this does not
represent a huge change as the CPE hosts the internal data as well as plays
as a resolver. There is only NAT that I see causing potential issues.

Yours,
Daniel

-- 
Daniel Migault
Ericsson