Re: [Add] Comparative DoH Discovery DNS RR Types

> On Jun 29, 2020, at 2:01 PM, Paul Vixie <paul@redbarn.org> wrote:
> 
> On Monday, 29 June 2020 15:36:42 UTC Livingood, Jason wrote:
>> Just noting far we have a variety of suggestions on CNAME, URI, TXT, RESINFO
>> and HTTPSSVC (though I don’t think all have I-Ds as yet) - always nice to
>> see the ideas flowing. :-) As a practical person that in IETF land is
>> considered an implementer, I naturally feel inclined towards RR types that
>> already exist as this enables something to be rapidly deployed.
> 
> the community apparently lacks coherence on the importance of rapid deployment 
> as compared to the importance of technical excellence. if we're not going to 
> add any more new RR types because they take ten years to become usable (see 
> the SPF RR vs. the later _spf TXT RR), we should say that, and close the RR 
> type registry, so as to avoid confusing newcomers.
> 
> if on the other hand we're going to continue to evolve DNS in ways that 
> include adding new RR types, and all the initiators who are stuck behind 
> dumbass middleboxes who reject or butcher unknown RR types are going to fail 
> hard and be excluded from the new applications and protocols in order to put 
> more pressure on middlebox users/makers/distributors, we should say that.

Agreed on both points.

To that end, one of the reasons I like using HTTPS RR (aka HTTPSSVC) for the ADD information is that this RR type, while new, is tied directly to the deployment of TLS Encrypted Client Hello (ECH). Improving the privacy of names on a network requires, ultimately, both encrypted DNS *and* encrypted SNIs in the client hello.

Of course, a client could only expect to do ECH when it already has encrypted DNS set up, but I’d prefer that the architecture not design for that case. We should have a system that allows to discover local encrypted resolver support, and even do ECH to hosts private to a local-network. There will indeed be networks or middle boxes that butcher this, but they also could be butchering other aspects that would stop the local network from upgrading from Do53 to DoT/DoH.

Tommy

> 
> either way, nothing is temporary. whatever we use for resolver discovery will 
> be present as a data pattern and code path in all future software. improved 
> signal patterns and associated logic will live alongside the unimproved ones, 
> raising the bar for both short-term expedients and later improvement to be 
> "worthy of its coexistence cost". for clarity, that's a _very_ high bar.
> 
>> As all of these become documented a discussed a bit further - or even tested
>> experimentally - my humble suggestion is that it may be helpful for the WG
>> to develop a grid of all the options with their associated pros & cons.
> 
> such grid would be well informed by the attached graphic.
> 
> -- 
> Paul<complexity.png>-- 
> Add mailing list
> Add@ietf.org
> https://www.ietf.org/mailman/listinfo/add