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
