Subject: Re: [Add] Draft Posting: CNAME Discovery of Local DoH Resolvers
From: Tommy Pauly <[email-masked]>
To: Eric Rescorla <[email-masked]>
Cc: ADD Mailing list <[email-masked]>
Date: Fri, 26 Jun 2020 14:46:18 -0700
List-Id: Applications Doing DNS <add.ietf.org>

Hi Ekr,

Thanks for sharing this draft. Very exciting to see this step forward in supporting the automatic use of DoH.

Regarding the choice of using DNS + CNAME, I completely understand and sympathize with the practical deployment aspects. Going forward, I’d like to see if collectively we can use a record that gives a full DoH URI. Your draft does reference the option of using HTTPS RRs for this, as Tommy Jensen has proposed in https://tools.ietf.org/id/draft-pauly-add-resolver-discovery-00.html#name-discovery-of-doh-capabiliti <https://tools.ietf.org/id/draft-pauly-add-resolver-discovery-00.html#name-discovery-of-doh-capabiliti>.

In my email to this list just a bit ago, I mentioned that we’re starting to request these RR types (well, the older version for HTTPSSVC, but will be updated) on the iOS and macOS betas. Hopefully we can measure based on that how much RRType interference exists in networks. I’d be curious to hear what kinds of measurements the Mozilla team is taking in this space, as you are able to share.

I’d also be interested to have a discussion here about the acceptable ranges for breakage. Certainly, if the percentage of home wifi setups that fails with a new RRType is very high, it’s a problem. However, if the percentage is lower but still significant (say, 5%?), we can consider the tradeoff of solutions. Intolerance to passing unknown RRTypes is one way that this could break; however, there are many other ways a local wifi router could potentially interfere. For example, a wifi router might not recurse to the ISP's DNS resolver, but some other resolver (which if it is 1.1.1.1 or 8.8.8.8 would support DoH, but could be something else that doesn’t). There will always be *some* tail of networks that won’t work, even with the CNAME approach; and I’d like to see a long-term solution that allows for richer information than just a hostname. Thoughts?

Best,
Tommy

> On Jun 25, 2020, at 7:05 AM, Eric Rescorla <[email-masked]> wrote:
> 
> Hi folks,
> 
> As has been noted previously, the current Firefox DoH/TRR design
> bypasses the ISP resolver even if the ISP resolver supports DoH.
> 
> I have just posted draft-rescorla-doh-cdisco-00, which describes a
> CNAME-based mechanism for discovering when a local resolver supports
> DoH/TRR. Firefox can then determine whether that resolver is on the
> TRR list and if so can use it in preference to generic resolver.. The
> use of CNAME was chosen for pragmatic reasons (laid out in the draft).
> We're studying other designs but thought it would be a good idea
> to document this one.
> 
> See: https://www.ietf.org/internet-drafts/draft-rescorla-doh-cdisco-00.txt <https://www.ietf.org/internet-drafts/draft-rescorla-doh-cdisco-00.txt>
> 
> -Ekr
> 
> 
> 
> 
> 
> 
> 
> 
> -- 
> Add mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/add