Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3D583A0D7F for ; Mon, 29 Jun 2020 14:40:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P2rDt5KgYm6g for ; Mon, 29 Jun 2020 14:40:28 -0700 (PDT) Received: from mail-vs1-xe41.google.com (mail-vs1-xe41.google.com [IPv6:2607:f8b0:4864:20::e41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBF943A0D7E for ; Mon, 29 Jun 2020 14:40:27 -0700 (PDT) Received: by mail-vs1-xe41.google.com with SMTP id k7so8720166vso.2 for ; Mon, 29 Jun 2020 14:40:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=95U2/rN/Xdhb/BUY7nkqVeIOP9mRM6UI+o7chR8Smdo=; b=T30WXi7R8AHJNKFNgh82enImPkNMiIY8hpGHy+ZSUWZQWBy0X1zQeKY9JnmSfyRi8R 8KoMWkkVhCY6cUFLBNDwkwAV7DaQAD4pLsVnvLQnl2qk57rYzCwykIEFNwhJZSRsm22D 3JUf7KPSgPtxU/GrQ9JFxPze8+H4rA88AOhMK6a/VCxbKfauKj7AvnzUrJjW5dahQ9wK 0YgHXvINMgYDl+Jth61R7VDFuECcCpru6xsuTKaYLFeTaSTw6CiGYNqjypcA1z0nRa03 +RV2lLoI/7+Q2wpsDsIgE/oFXh48RNQJh6B1XC61DzS+9Ns8rNiz69EB8dOUYMb7xPxw wXMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=95U2/rN/Xdhb/BUY7nkqVeIOP9mRM6UI+o7chR8Smdo=; b=kzZ7qIOXxytEo6a7UEAaABg1eBAod5Vtue+0OGnih/+BPsE5Dn6J058ymy+C/UxjgW XGmaGofeQsBNxdvdcj4IzFewrc9mWjOZz3LfD4t3qZcsEbTUAaCBZfrj8caYN3cWa404 jd8Lt9kMKP+8MV8y5ePJKx1VP0ESu+7uKEtzvDTGPoaH32OCl0379QycP9dp88etRhr8 /DGFKoRNCjugdDbOK9SwMpDnzKQNlB7yGOjfRwv6RYJBW6di26p0g2ItD96+nzT5eMCG 2Jix0WqclH9t8X1r0sJU73PQOR/nZiUgsknfdUL7nCWQsrsLfyaP8pcDy4R44V16zvvr TQQQ== X-Gm-Message-State: AOAM532STp6Rnjwc6IB9kHCKYoQqQN/dfaHLq1D95isnd3LMkLkNaV4N HNqTO+H6jlydURNk8+k+apAq5m9yTe5cHxVW8gRThw== X-Google-Smtp-Source: ABdhPJwt09xnqmEqEg1WNMEAjTi3Hh6BZ0xeWhqdEDQcN0rDUoU3dk2xLRqePm6I/EjPPEfGmR8gACbdZ79DldFJwiE= X-Received: by 2002:a67:6546:: with SMTP id z67mr5377184vsb.169.1593466826861; Mon, 29 Jun 2020 14:40:26 -0700 (PDT) MIME-Version: 1.0 References: <14119.1593367594@localhost> <3615321.ADK9YsXCiF@linux-9daj> In-Reply-To: <3615321.ADK9YsXCiF@linux-9daj> From: Daniel Migault Date: Mon, 29 Jun 2020 17:40:16 -0400 Message-ID: To: Paul Vixie Cc: Michael Richardson , ADD Mailing list , John R Levine Content-Type: multipart/alternative; boundary="0000000000002d312805a93fe8ef" Archived-At: Subject: Re: [Add] [Ext] Draft Posting: CNAME Discovery of Local DoH Resolvers X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2020 21:40:30 -0000 --0000000000002d312805a93fe8ef Content-Type: text/plain; charset="UTF-8" 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 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 > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add > -- Daniel Migault Ericsson --0000000000002d312805a93fe8ef Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,=C2=A0

I bel= ieve 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 gen= eric,
and would be happy to improve it.

I would be happy to unde= rstand 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 Do= T DoH and DNS, but I might
be missing something. =C2=A0

Here are = my comments regarding your
proposal:

I believe that CNAME is to r= estrictive
and would not make possible for example
to have multiple r= esolvers. I believe
the ISP should be able to provide
multiple resolv= ers. Some resolver may
implement DoH, DoT in combination with
multipl= e additional services. So in
short CNAME would limit the discover of
= one or no resolvers.=C2=A0 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 othe= r hand, the ISP can hardly to
made a choice that fits any applicationor the end user. The ISP cannot propose
different services for differen= t
applications. =C2=A0 =C2=A0

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

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

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

I= n DRDP [1], the list of resolvers is
associated to a resolving domain. I= n the
case of an ISP the resolving domain is
derive with a reverse re= solution from
the IP address announced by the ISP .
Note that other m= eans may be provided.
With the resolving domain - in your case
resolv= er.example, the application will
retrieve the resolvers associated to th= e
resolving domain.=C2=A0 In your case you are
exclusively focused on= DoH server, so
your application will them perform
_443_dns.example.com. SVCB. =C2=A0

Note tha= t an early version of DRDP was
using SRV/TXT instead of SVCB. =C2=A0
=
Yours,=C2=A0
Daniel

On Sun, Jun 28, 2020 at 3:23 PM Paul Vixie= <paul@redbarn.org> wrote:
On Sunday, 28 June= 2020 18:29:22 UTC John R Levine wrote:
> On Sun, 28 Jun 2020, Michael Richardson wrote:
> >=C2=A0 =C2=A0 > Beyond that I gather there is still concern abo= ut SOHO routers with
> >=C2=A0 =C2=A0 > poorly implemented DNS forwarders that only han= dle some kinds of
> >=C2=A0 =C2=A0 > queries.
> >
> > I believe that the majority of devices on the market are now base= d upon
> > versions of openwrt which, even if 10 years out of date, now have= only 15
> > year old DNS forwarding code.=C2=A0 And that's new enough. >
> It's not what's on sale now, it's what's installed.=C2= =A0 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 scal= ed
and won't.

--
Paul


--
Add mailing list
Add@ietf.org
https://www.ietf.org/mailman/listinfo/add


--
Daniel Migault
Ericsson
--0000000000002d312805a93fe8ef--