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

[Daniel Migault <[e-mail]>]

Hi,

I believe the proposal presents some
similarities to draft-mglt-drdp [1] that is
using the DNS to proceed to the
discovery. I see drdp as more generic,
and would be happy to improve it.

I would be happy to understand why HTTP
is a better stack to perform the
discover as opposed to DNS. I think that
DNS is better as it is the common
protocol to DoT DoH and DNS, but I might
be missing something.

Here are my comments regarding your
proposal:

I believe that CNAME is to restrictive
and would not make possible for example
to have multiple resolvers. I believe
the ISP should be able to provide
multiple resolvers. Some resolver may
implement DoH, DoT in combination with
multiple additional services. So in
short CNAME would limit the discover of
one or no resolvers.  The limitation
seems for both the application and the
ISP as it does not provide the ability
for an application to chose the service
and force the ISP to make that choice.
On the other hand, the ISP can hardly to
made a choice that fits any application
or the end user. The ISP cannot propose
different services for different
applications.

CNAME does not provide useful necessary
parameters that may also be useful for a
DoH resolver DRDP lists among others:
alpn, ensiconfig, uri template, user
display, auth_domain, filtering,
ip_subnet, dnssec, ....

My understanding is that BCP 17 saw SRV
as a long term solution for CNAME which
is now superseded by HTTPSVC/SVCB. I see
SRV as very common in home networks with
service discovery.

I believe that using a generic is
problematic as is prevents its resoltion
to be secured with DNSSEC.

In DRDP [1], the list of resolvers is
associated to a resolving domain. In the
case of an ISP the resolving domain is
derive with a reverse resolution from
the IP address announced by the ISP .
Note that other means may be provided.
With the resolving domain - in your case
resolver.example, the application will
retrieve the resolvers associated to the
resolving domain.  In your case you are
exclusively focused on DoH server, so
your application will them perform
_443_dns.example.com. SVCB.

Note that an early version of DRDP was
using SRV/TXT instead of SVCB.

Yours,
Daniel

[1]
https://github.com/mglt/draft-mglt-abcd-dofoo-discovery/blob/master/draft-mglt-add-rdp.mkd

On Sun, Jun 28, 2020 at 3:23 PM Paul Vixie <[e-mail]> wrote:

> On Sunday, 28 June 2020 18:29:22 UTC John R Levine wrote:
> > On Sun, 28 Jun 2020, Michael Richardson wrote:
> > >    > Beyond that I gather there is still concern about SOHO routers
> with
> > >    > poorly implemented DNS forwarders that only handle some kinds of
> > >    > queries.
> > >
> > > I believe that the majority of devices on the market are now based upon
> > > versions of openwrt which, even if 10 years out of date, now have only
> 15
> > > year old DNS forwarding code.  And that's new enough.
> >
> > It's not what's on sale now, it's what's installed.  People tend to keep
> > what they have unless it breaks in ways that are obvious to them.
>
> as we learned with EDNS, we should have broken more stuff sooner. being
> liberal in what we accept and conservative in what we generate has not
> scaled
> and won't.
>
> --
> Paul
>
>
> --
> Add mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/add
>


-- 
Daniel Migault
Ericsson