Re: [Add] Drafts on upgrading stub-to-resolver communication to encrypted

[Vittorio Bertola <[e-mail]>]

> Il 24/04/2020 18:45 Paul Hoffman <[e-mail]> ha scritto:
> 
> Please let us know if you find these documents useful for the discussion of direct upgrade instead of discovery. Also, please let us know if we have missed any salient points. If so, we could ask the chairs to make these into WG documents.

Thanks for doing this and I support adoption at least for the resinfo draft.

On the resinfo draft, I want to support other comments saying that the HTTP-based mechanism should be removed. As an implementer, having two alternative methods means that you possibly have to implement and maintain both, doubling the work and the potential number of issues. 

I get the point that some clients already speak HTTPS and so why not use it, but there is the other point that all resolvers must speak DNS, so using DNS is the easiest path to widespread implementation on the server side. Not all resolvers will support DoH, so they would have to implement and run an HTTP server just to answer possible discovery queries, since there is no guarantee that even a client willing to speak DoT or DNS will not use the HTTP-based discovery mechanism. 

Even resolver platforms that implement DoH are often doing so by adding a separate layer of front-end HTTP termination servers that convert the messages into DNS queries to the actual resolver, so the resolver itself does not run an HTTP server over its own IP address (the one that the user's system already knows and that would go into the well-known URI), and would have to add one just to this purpose.

Moreover, while the DNS-based mechanism can work with forwarders, including home network CPEs, the HTTP-based one would end up making the request not to the actual resolver but to the CPE. This would entail modifying all CPEs (which is a daunting task that takes years in most big operator environments) and having them relay the HTTP request in some way to the resolver platform (which needs to be implemented).

The DNS-based mechanism, instead, is much more straightforward - it automatically follows the same path that the queries will follow, and so it will reach the correct resolver. Thanks for removing the reverse IP address in the queried domain name, which created problems in the CPE scenario above. I would still like to hear opinions on the classic "new RRTYPE vs TXT record" discussion, as I do not know whether adopting a new RRTYPE would hinder quick support, while TXT records can safely work right now almost in any scenario.

Regarding the second draft: I think it would benefit from a presentation before commenting. Anyway, I was a bit surprised by the fact that it seems to prescribe an algorithm (though configurable) for clients to decide which transport to use. I would rather expect a mechanism that allows clients to retrieve a known unencrypted resolver's equivalent DoT and/or DoH endpoints, through any of the methods supported in draft-resinfo (though, as I said, I really hope we will just end up with the DNS one), and then, what the client does with that information is none of our business.

Anyway, thanks for the work and I look forward to more discussion.

-- 
 
Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
[e-mail] 
Office @ Via Treviso 12, 10144 Torino, Italy