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 <[email protected]> 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
> [email protected]
> https://www.ietf.org/mailman/listinfo/dns-privacy
>
_______________________________________________
dns-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy
