Re: [Add] [Ext] Draft Posting: CNAME Discovery of Local DoH Resolvers

[Paul Hoffman <[e-mail]>]

On Jun 25, 2020, at 7:05 AM, Eric Rescorla <[e-mail]> wrote:

> 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

A particular relevant part of this draft for this WG is:

3.2.  Why a CNAME?

   Most other proposed designs (e.g., [I-D.pp-add-resinfo] and
   [I-D.pp-add-stub-upgrade], and [I-D.pauly-add-resolver-discovery])
   use new RRtypes.  While this may be the right answer eventually, it
   is less convenient for immediate deployment, for several reasons:

   1.  It is somewhat more difficult (though not impossible) to look up
       new RRTypes on the client and provision them on the ISP resolver.

   2.  Some consumer-grade middleboxes (e.g., WiFI routers) may block
       unknown RRTypes.  The data here is quite old and limited, but
       still not particularly promising.

   The choice to use a CNAME does have one major drawback: it does not
   let us provide the URL template but only the name of the resolver.
   This is not a problem for our system in practice because Firefox will
   only connect to resolvers on a preconfigured list and thus will use
   the CNAME as a lookup key for that list.  The Mozilla team is working
   to measure the rate of new RRType interference and may revise this
   approach depending on the results of that.

   [[OPEN ISSUE: We are working to measure the rate of new RRType
   interference and may revise this approach depending on the results of
   that.]]

Point 1 feels overstated. The clients we are talking about here are modern web browsers, which can clearly write whatever they want in their DNS queries. I cannot imagine that an ISP resolver that has to also act as an authoritative server would have any restriction on what RRtypes they can provision.

Point 2 is interesting, and I'm glad to hear that Mozilla and Apple are looking into it. The key part of that is what is "unknown" to any such middlebox. The research should definitely look at whether CNAME is in the list of unknown RRtypes, given that stub resolvers rarely send CNAME queries.

The major drawback that is listed does indeed seem major for use cases other than Mozilla's TRR. This WG has been discussing other use cases, so it feels restrictive to consider a solution that is focused on just that one use case unless the middlebox problem is shown to be crippling to the use of new and more flexible RRtypes.

--Paul Hoffman