On Aug 24, 2018, at 7:45 AM, Philip Homburg <pch-dnso...@u-1.phicoh.com> wrote: > >>> Well, if the OS resolver is validating, it will SERVFAIL with such a >>> query. >> >> The protocol requires special handling of those specific queries, >> so a resolver that understands the protocol will give the desired >> answer. A resolver that doesn't understand the answer will give >> NXDOMAIN even if it is validating because that RRtype is not in >> the root zone. > > It seems to go wrong when you have one validating resolver that forwards to a > resolver that supports this mechanism.
Agree. This might mean that using an unsigned 6761 special use domain name would be better. > It don't really see the point of what you propose. For resolvers obtained by > DHCP it makes more sense to include the URL in the DHCP reply than to have > yet another DNSSEC-violating discovery hack. Two reasons here (although they might not be convincing): - This proposal works for browsers even if the OS doesn't understand a new DHCP extension for DoH server URI templates - It relives the DHCP server admin from needing to know which DoH servers are associated with a particular Do53 server. As I hope I made clear in the proposal, it will work even if there is a new DHCP extension for the OS. It just doesn't rely on it. > For manually configured resolvers, it is likely more convenient for the user > to just enter the URL and let the system figure out the addresses of the > resolvers. Again, it is not clear how that information would get to the browsers. They have a hard enough time getting good answers to "what is the address being used for the resolver". > Figuring out what SNI to use using insecure DNS sort of negates any advantage > TLS authentication offers. I don't understand this at all. The SNI is the host in the URI template. --Paul Hoffman _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
