I am going to echo my original comment on the draft as it may have been lost in this long thread and it will make sense to keep this close to related convo.
``` As for feedback on the draft options. - Section 2.3: Why DoH has no option data? The IP from the DNS recursive name server option merely provide an IP to connect to. DoH server may have a cert that will validate for a hostname. The endpoint may or may not be /dns-query . How about alternate ports? It seems a having the URI as part of the data would be useful ( e.g https://dnsserver.example.net/dns-query , https://10.10.10.10:8443/dns-query , https://2001:DB8::1/doh ...) - the draft as is, assumes that port 853 will be used for DoT, 443 for DoH. Being able to provide alternate ports could be a plus - It is not clear to me if the options apply to all nameservers from the dns recursive nameserver option, or if there needs to be 1 option for each nameserver. I could for instance have nameserver1 which does DoT + DoH while nameserver2 does none. In this case, I would get option 147 with option len of 2 for the first server, followed by option 147 with option len of 0 for the second one. - A DHCP option should be able to be set multiple time, so one can configure TLS_SPKI with multiple values. May be useful for rotations and such. ``` Manu On Mon, Aug 20, 2018 at 9:42 AM Tony Finch <d...@dotat.at> wrote: > Marek Vavruša <mvavrusa=40cloudflare....@dmarc.ietf.org> wrote: > > > > > https://github.com/vavrusa/draft-dhcp-dprive/blob/master/draft-dhcp-dprive.txt > > This is interesting to me because I want to support DoTH on my campus > resolvers. > > Regarding DoT, it seems to me that a super simple way for the client to > be able to authenticate the server would be to include the server's IP > address(es) in the subjectAltName field. This wouldn't require a DHCP > extension, and nicely supports opportunistic updgrade. I'm afraid I wasn't > paying attention when RFC 8310 was being prepared so I don't know why it > excludes iPAddress authentication. > > Regarding DoH, the DHCP option ought to include a URI template (there > isn't a .well-known for DoH). I plan to set up my servers so that > misdirected attempts to get web pages from the DoH server are redirected > to the relevant documentation; that's much easier if the DoH endpoint > isn't at the server root. > > A URI template usually implies the need for DNS queries to resolve the > server name (unless it's an address literal). Would it be plausible to > allow the client to assume that the DoH server IP addresses are the same > as the DNS server addresses, so it can skip the lookup? I guess that would > be too annoying for operators that want their DoH servers to be separate > from their normal DNS resolvers, so maybe it's a bad idea :-) > > Tony. > > (PS. DoTH is clearly what happens if someone suggests "DoNT" but we do it > anyway.) > > -- > f.anthony.n.finch <d...@dotat.at> http://dotat.at/ > fight poverty, oppression, hunger, ignorance, disease, and > aggression_______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
