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

[Eric Rescorla <[e-mail]>]

On Mon, Jun 29, 2020 at 2:40 PM Daniel Migault <[e-mail]> wrote:

> 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.
>

I don't quite follow this, as we do not use HTTP.


>
> I believe that CNAME is to restrictive
> and would not make possible for example
> to have multiple resolvers
>

This goes back to use case. In our use case, the multiple resolvers would
be supplied by manual configuration of the client. the CNAME is just a
lookup key.

>
> 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.
>

As I said earlier, this goes back to threat model. Please describe the
thrat model where you think DNSSEC helps.

-Ekr




> 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
> --
> Add mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/add
>