Re: [dns-privacy] Discovery of DNS over (not 53) and ALPN

Erik Nygren <erik+ietf@nygren.org> Fri, 13 December 2019 14:12 UTC

Return-Path: <nygren@gmail.com>
X-Original-To: dns-privacy@ietfa.amsl.com
Delivered-To: dns-privacy@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D087812009E for <dns-privacy@ietfa.amsl.com>; Fri, 13 Dec 2019 06:12:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.299
X-Spam-Level:
X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, MIME_BOUND_DIGITS_15=0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
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 CR5vUsByRm1S for <dns-privacy@ietfa.amsl.com>; Fri, 13 Dec 2019 06:12:22 -0800 (PST)
Received: from mail-wm1-f66.google.com (mail-wm1-f66.google.com [209.85.128.66]) (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 3C053120073 for <dns-privacy@ietf.org>; Fri, 13 Dec 2019 06:12:22 -0800 (PST)
Received: by mail-wm1-f66.google.com with SMTP id t14so6706894wmi.5 for <dns-privacy@ietf.org>; Fri, 13 Dec 2019 06:12:22 -0800 (PST)
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=K0AKx1uE7zgacXS1bcA+qDpXgSUsd12fMt7DwFIUV6M=; b=qWtwoTTmGd+FgACykLkCLgY4kakY+dFzkPrQl5h0QBxhhLjI3nJj1Pb5OYelYqDjnM M2lxLaDXxSuIdGalLLGCb8DeKw3ic9HpuXnPj6CloINW560VHroJwP/6PJCXOv3gfaK9 igt0l8xILLLMy/h0y/oJqW0inH6Qhl6NZxia/LtO1/ghgggQygaHO25iw3eAsh1kpSuV JCJwbH7u/n4meMjqrSJIVswl9VfmUZJEHSl9OzxpZqCt1GjBR+ehwLCaZ36oHlQoXz22 sKFwFNmDlBcZ7plw6004BoyQK2SsDG+xc1ql9G604Klp0Dg0MhGcBJ8ZM7V/567uQwFL SCQw==
X-Gm-Message-State: APjAAAWr1oaYJQ7bVg5HB5XJZ8zu49JeFXWkJhF/0OFrTypDRqSNUu4a UtBlTrZxUmOngI0vEyE0lf9KkTK6O1WcD8l7D/2k9jUhyuc=
X-Google-Smtp-Source: APXvYqw/gnOJL4iDguxk+yXbZo8r3WPeYbVh7nEQMwjVDmbLdava+ySmpTF+RO7nN+6JxeNZD5uPE3fjSXXODDSVWVk=
X-Received: by 2002:a7b:cc97:: with SMTP id p23mr14407866wma.89.1576246340428; Fri, 13 Dec 2019 06:12:20 -0800 (PST)
MIME-Version: 1.0
References: <CA+9kkMAmsK746ViRb9tXkJX+t_paOGpWCN3i78WK_t86bLGUnQ@mail.gmail.com>
In-Reply-To: <CA+9kkMAmsK746ViRb9tXkJX+t_paOGpWCN3i78WK_t86bLGUnQ@mail.gmail.com>
From: Erik Nygren <erik+ietf@nygren.org>
Date: Fri, 13 Dec 2019 09:12:09 -0500
Message-ID: <CAKC-DJhiZAv8gESrhvUc5v86TcRXrfASq4ujQ3BxOYnuENrBjg@mail.gmail.com>
To: Ted Hardie <ted.ietf@gmail.com>
Cc: dns-privacy@ietf.org
Content-Type: multipart/alternative; boundary="0000000000003327030599967300"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/bop8BovTEseOIzBCHbG6ZmuJvfM>
Subject: Re: [dns-privacy] Discovery of DNS over (not 53) and ALPN
X-BeenThere: dns-privacy@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <dns-privacy.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dns-privacy/>
List-Post: <mailto:dns-privacy@ietf.org>
List-Help: <mailto:dns-privacy-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Dec 2019 14:12:24 -0000

Linking ALPN and port defeats the purpose of ALPN.  It would be preferable
to have the discovery mechanism
enumerate an preference-ordered list of tuples of {host/ip(s), port,
proto/alpn, [uri_template]}.
This is similar to what Alt-Svc in HTTP does as well as what SVCB does.
For example:

   { 192.168.1.2, 853, "doq" }
   { 192.168.1.2, 853, "dot" }
   { 192.168.1.3, 443, "dot" }
   { "doh.example.com", 443, "h2", "https://doh.example.com/query/?{}" }
   { 192.168.1.1, 53, "do53" }

The main driving factor for having an ALPN token is for cases when there
is a desire to configure dot and doh to share a port (especially 443)
for some use-case.

Regards, Erik


On Fri, Dec 13, 2019 at 8:53 AM Ted Hardie <ted.ietf@gmail.com> wrote:

> So this came up in an another thread, but it probably needs a separate
> topic.
>
> The point being made was:
>
> We really need to figure out how to do DoWhatever discovery, preferably
>> better than probe ports on the same IP as the port 53 server.
>>
>
> I think one critical question is how discovery of DoT and DoH (and later
> entrants)  servers is related to the discovery of port 53 servers.  One
> possibility here, if we do define ALPN tokens for each of these, is to
> combine that token with the base discovery methods.  So, DHCPv4 Option 6
> (or DHCPv6 option 23) gives you the IP address of the server, and a new
> DNS-ALPN option code gives you the ALPN(s), from which you derive the port.
>
> If the DNS-ALPN option code is absent, go to port 53.  If there is one
> present, it is a list, like the ALPN next protocol list, of the tokens
> corresponding to the list the server supports.  This implies that you would
> need an ALPN token for DoT port 853 to be available and distinct from DoT
> port 443.
>
> Router advertisements are a little trickier.  If someone is currently
> using RFC 8106 style advertisements, I think it would be cleaner to have
> those still present and a new option for DNS-over-not-53 options.  That
> could still leverage the ALPN list as a way of making that a single option
> (rather than a bunch of separate announcements).
>
> There are clearly operational environments that wouldn't follow this
> (those that use the URI template in RFC 8484, for example), but something
> that allows you to signal them together does seem useful.
>
> Note that this approach means that if you have a client that supports DNS
> over 53 and doesn't understand the ALPN token in the new option, you can
> run into a corner case.  If the network does not support DNS over 53, the
> client will fail to see the alternatives to port 53.  It would then have to
> interpret an ICMP destination unreachable (presuming that gets through).
>
> I'm not an expert on either DHCP or RA, of course, so I may have this
> wrong way around.
>
> regards,
>
> Ted
> _______________________________________________
> dns-privacy mailing list
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy
>