Hi Erik,
On Fri, Dec 13, 2019 at 2:12 PM Erik Nygren <[email protected]> wrote:
> Linking ALPN and port defeats the purpose of ALPN.
>
Unfortunately, ALPN's native "discovery" mechanism is more-or-less connect
and see what the list is. That's pretty much what the original respondents
are trying to avoid.
If you have an external method, you can certainly make it more detailed
(and a set of tuples is a way to do that), but there is question of
synchronization of the addresses used in each. If DHCP/RA are going to be
used for discovery, what I think that means is that if both the current DNS
option and a DNS-Tuple option are present, the DNS-Tuple option's
information would have to supersede any information in the current options.
So, let's back up a step: are people interested in using DHCP and RA as
part of the discovery story here or not?
regards,
Ted
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
