Re: [Add] Updated charter proposal for ADD

["Smith, Kevin, Vodafone Group" <[e-mail]>]

+1 but with an amendment here:

    This working group will focus on discovery *, authentication* and selection of DNS resolvers
    by DNS clients in a variety of networking environments,

This is to help mitigate the scenario of a rogue resolver in a local network.

All best,
Kevin




C2 General
From: Add <[e-mail]> On Behalf Of Andrew Campling
Sent: 15 January 2020 15:45
To: Paul Adair <[e-mail]>; Tommy Pauly <tpauly=[e-mail]>; Glenn Deen <[e-mail]>; ADD Mailing list <[e-mail]>
Subject: Re: [Add] Updated charter proposal for ADD

+1

Andrew

-----Original Message-----
From: Paul Adair <[e-mail]<mailto:[e-mail]>>
Sent: 15 January 2020 13:07
To: Tommy Pauly <tpauly=[e-mail]<mailto:tpauly=[e-mail]>>; ADD Mailing list <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Add] Updated charter proposal for ADD

I support the charter as written.

Paul Adair
Infoblox

On 1/14/20, 4:38 PM, "Add on behalf of Tommy Pauly" <[e-mail] on behalf of tpauly=[e-mail]<mailto:[e-mail]%20on%20behalf%20of%20tpauly=[e-mail]>> wrote:

    Hi all,

    I wanted to share an updated proposal for an ADD charter, based on the feedback and discussion on the list in the past several weeks.

    This is based on the original proposal that was sent in December, taking into account various comments and suggestions. Glenn Deen, Andrew Campling, and I worked on this revision together and came to consensus on its contents.

    Thoughts and comments are welcome as always!

    (Note that the proposed name of the group was not changed, and is entirely open to bikeshedding. Naming is hard!)

    Best,
    Tommy



    Adaptive DNS Discovery (ADD)
    ====================================
    Proposed Working Group Charter

    Sending DNS messages over encrypted transports, as defined in DNS over
    TLS (DoT) [RFC 7858] and DNS over HTTPS (DoH) [RFC 8484], provides
    benefits to the security and privacy of DNS data. Clients, such as
    applications and host operating systems, have started adopting these
    protocols to provide these user benefits.

    This working group will focus on discovery and selection of DNS resolvers
    by DNS clients in a variety of networking environments, including public
    networks, private networks, and VPNs; supporting both encrypted and
    unencrypted resolvers.

    Clients adopting encrypted DNS protocols need to determine which DNS
    servers support encrypted transports, and which server to use for specific
    queries if multiple servers are available. These decisions can vary based
    on the network environment, and also based on the content and purpose of
    the client queries.

    Network operators that start offering DNS encryption on their servers also
    need a way to indicate this support to clients. Communicating information
    about resolver configuration and behavior allows clients to make more
    informed decisions about which DNS servers to use. For example, a resolver
    may be able to resolve private or local names as a split DNS server.

    The Adaptive DNS Discovery (ADD) working group will work on the following
    deliverables:

    - define a mechanism that allows clients to discover DNS resolvers,
    including encrypted DNS servers, that are available to the client
    either on the public Internet or on private or local networks;

    - define a mechanism that allows communication of DNS resolver
    information to clients for use in selection decisions;

    - develop an informational document that describes how client
    applications and systems can manage selection of DNS resolvers
    in various network environments and use cases.

    Any mechanisms that specify interactions between clients and
    servers must provide the security properties expected of IETF
    protocols, e.g., confidentiality protection, integrity protection,
    and authentication with strong work factor.

    This working group will coordinate with dnsop, doh, and dprive for any
    changes required in DNS protocols. It will also work with capport to
    ensure that solutions are applicable to captive networks.

    --
    Add mailing list
    [e-mail]<mailto:[e-mail]>
    https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/add__;!!JYsgTRAg6ZQ!YAYWpqIz-5mnVKFP1uomaHnZqaaPeM7jg_t3b2JEb1RGKILDMtltv1eD68VDh3Y$<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/add__;!!JYsgTRAg6ZQ!YAYWpqIz-5mnVKFP1uomaHnZqaaPeM7jg_t3b2JEb1RGKILDMtltv1eD68VDh3Y$>