[ BCCed to DNSOP, DOH, DPRIVE (to stop cross-posting issues) ] Hi all,
I wanted to mention a proposed (non-WG forming) BoF -- DNS Resolver Identification and Use (DRIU). The description is below, and the mailing list is: https://www.ietf.org/mailman/listinfo/driu I think that this will be of interest to many... -------- The IETF has added additional methods for DNS stub resolvers to get to recursive resolvers (notably DNS-over-TLS, RFC 7858), and is about to add another (DNS-over-HTTPS, from the DOH Working Group). As these have been developed, questions have been raised about how to identify these resolvers from protocols such as DHCP and DHCPv6, what the security properties these transports have in various configurations (such as between strict security and opportunistic security), and what it means for a user who has multiple resolvers configured when the elements of the configured set have different transports and security properties. This BoF is not intended to form a Working Group. Instead, it is meant to bring together authors of various WG and individual drafts to prevent overlap and to garner interest in particular topics. Because many people are thinking of writing documents covering various related topics, it would be good to have a mailing list and a BoF to help cross-pollinate the ideas. Some of the topics that would be on-topic would be: * How to identify DNS-over-different-transport in protocols such as DHCP, and in user-accessible configuration * Security properties of the various flavors of transport-secured DNS * TLS authentication when the identifier is an IP address (which is most common for identifying DNS resolvers) * How resolvers can express their capabilities to clients who might care (such as "this resolver does DNSSEC validation" or "this resolver passes client subnet information to authoritative servers") * Identifying a resolver in the "dns:" URI scheme in RFC 4501. A related question is whether there should be a "dnss:" URI scheme whose semantics mean "Look up this name, but only use a secure DNS server", where "secure" would need to be defined. * There are likely additional related topics that the BoF and mailing list might delve into. ----- W -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
