[DNSOP] DNS Resolver Identification and Use (DRIU) BoF.

[ 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