Re: [Add] Agenda and Revised Charter for the ABCD BoF

["Livingood, Jason" <[e-mail]>]

After reflecting on the list discussion, I agree there are aspects of the proposed charter on which it will be difficult to achieve consensus (LOL). So maybe let’s just set aside the stuff where we all know that is the case and try to focus more narrowly on those areas where getting a few things done might be possible. So for example – here are some off-the-cuff thoughts which may or may not be well considered on my part. ;-) (with apologies to people that view this in plaintext mode vs. HTML - since I have added strikethrough and colored text markup – blue text is new):

This working group will consider technical drafts on DNS client
configuration, especially with a focus on the following items where
technical consensus seems obtainable:

- Communicating configuration between the network, operating system, and
Applications How resolvers can signal their configuration and/or practices to operating systems and applications (and users?), to support decision-making or selection behaviors by those parties.

- Automated discovery & selection Discovery of resolvers, with selection potentially made based on detected resolver and their capabilities and behaviors (based on OS, app and/or user preferences)

- Query routing in a multi-resolver environment

- Multiple non-equivalent query paths, such as split-horizon DNS or
geo-sensitive answers

- Determination / detection of split-horizon DNS environments and standardized uses of ‘canary domains’ or other methods to enable detection of such environments

- Potential use of alternative application port numbers in some controlled environments (e.g. managed enterprise environments), including the pros/cons and implications of security downgrade and/or detectability in these environments

- Local DNS caches (e.g. partitioning, use of stale records)

- Resilience and fault-tolerance (e.g. single points of failure modes from encrypted DNS to Do53 or from a primary encrypted DNS resolvers to secondary or tertiary resolvers – or something like that)

- Support Standards / approaches for debugging and analysis (e.g. to support development of OS and application-layer diagnostic troubleshooting tools, a la dig, whether software-driven or user-prompted)

- DNS Push (accepting responses to queries that have not yet been issued) [JL comment: not sure why this would not be a client-driven activity, such as looking at all possible FQDNs on a site that a user is likely to ask for and sending all those queries from the client when the app/site first opens, based on prior user behavior or likely pathways through an app/site]

- Ossification and evolvability

The following topics are also relevant, but represent areas that are
significantly more challenging for consensus-building:

- End-user privacy and pervasive surveillance
- Detection and suppression of malware
- Use of records from untrusted sources
- Policy enforcement and control of the stub resolver configuration
- Use and impacts of large recursive resolution services

The working group will not attempt to resolve disagreements on these topics,
and will require full consensus on any statements regarding these areas.

This working group will coordinate with dnsop (OPS Area), capport (ART
Area), dprive, dhc, and homenet (INT Area). All last-call announcements will
be copied to the relevant working groups to ensure thorough and careful
review. The working group will also coordinate with the SEC Area, and will
be assigned a security advisor.



From: Add <[e-mail]> on behalf of Patrick McManus <[e-mail]>
Date: Saturday, November 16, 2019 at 1:06 PM
To: Ben Schwartz <bemasc=[e-mail]>
Cc: ADD Mailing list <[e-mail]>, Ralf Weber <[e-mail]>
Subject: Re: [Add] Agenda and Revised Charter for the ABCD BoF

This charter just seems like a suggestion for a perpetual forum to argue and, afaict, isn't actually expected to produce anything... it just has some things that if they were published would belong in the proposed wg.

Please don't make us collectively relive the ADD side meeting every full meeting.

My suggestion: If the proponents believe that a group can publish a document on (e..g.) "Communicating configuration between the network, operating system, and applications" please write a charter with that as the goal of the group and the BoF can do the usual thing of deciding whether that is a problem worth solving, is well understood, and has a chance of success. If it works out - recharter the group for new work.


As is the charter fails those tests by putting everything in scope but requiring nothing at the same time.


-Patrick



On Thu, Nov 14, 2019 at 1:14 PM Ben Schwartz <bemasc=[e-mail]<mailto:[e-mail]>> wrote:


On Thu, Nov 14, 2019 at 7:42 AM Ralf Weber <[e-mail]<mailto:[e-mail]>> wrote:
Moin!

On 13 Nov 2019, at 2:32, Ben Schwartz wrote:
> Please review the agenda and proposed charter, and join us next week
> for a
> full discussion.
 From the proposed charter:
> This working group will consider technical drafts on DNS client
> configuration, especially with a focus on the following items where
> technical consensus seems obtainable:
>
> - Communicating configuration between the network, operating system,
> and
> applications
> - Discovery of resolvers and their capabilities and behaviors
> - Query routing in a multi-resolver environment
This is ambiguous.

I think this is very closely related to the next entry on the list, so we should understand them together.  Perhaps they should be combined

If it describes the current /etc/resolv.conf that’s
fine,

That would be in-scope (and there has been some innovation here related to retry behavior, load spreading, etc. which could be documented).

but I fear that it describes something where you ask “resolver
A” for example.com<https://urldefense.com/v3/__http:/example.com__;!rx_L75ITgOQ!QpYiYmLfw5x0GNCzn55qgsVeik8Scqtt7RQzzTGhG4peCplTE5ij67Tt1xPomd9ytuQ_Ug$> and “resolver B” for example.net<https://urldefense.com/v3/__http:/example.net__;!rx_L75ITgOQ!QpYiYmLfw5x0GNCzn55qgsVeik8Scqtt7RQzzTGhG4peCplTE5ij67Tt1xPomd-IwSWjYg$>.

I think designs of this kind would also be in-scope.

I don’t think that there is consensus for such an approach.

I don't think there is a single approach here; it seems to me that there is a vast range of possible client behaviors related to multiple resolvers.  Recommending a single behavior universally might be controversial, but I think there is plenty of room for productive technical discussion in this area without triggering reflexive disagreement.

> - Multiple non-equivalent query paths, such as split-horizon DNS or
> geo-sensitive answers

As an example of the kinds of issues that come up here, consider Mozilla's default behavior [1], in which an NXDOMAIN response from the primary resolution path triggers a retry of the query on a second resolution path.  This is an interesting choice with particular privacy, security, compatibility, and performance properties.  Perhaps it's worth specifying this solution in more detail, or perhaps defining a range of solutions with different properties.  I believe we can discuss the properties of different stub state-machines without debating Mozilla's method for choosing the primary resolver.

[1] https://support.mozilla.org/en-US/kb/dns-over-https-doh-faqs#w_how-does-firefox-handle-split-horizon-dns<https://urldefense.com/v3/__https:/support...mozilla.org/en-US/kb/dns-over-https-doh-faqs*w_how-does-firefox-handle-split-horizon-dns__;Iw!rx_L75ITgOQ!QpYiYmLfw5x0GNCzn55qgsVeik8Scqtt7RQzzTGhG4peCplTE5ij67Tt1xPomd-lJFnTqg$>

> - Local DNS caches (e.g. partitioning, use of stale records)
> - Resilience and fault-tolerance (e.g. single points of failure)
> - Support for debugging and analysis
> - DNS Push (accepting responses to queries that have not yet been
> issued)
Same thing I don’t think that there is consensus on this.

We don't need consensus that a topic is worthwhile in order to include it in a working group charter.  We merely need to believe that there is some positive interest and potential for a technical consensus to emerge without derailing the working group's other topics.

I personally
think it is a bad idea, but I seem to recall from earlier discussions
that others agreed with me. IMHO this belongs in the relevant, but more
challenging for  consensus building category.

I don't think this topic is particularly controversial, and versions of this idea have been considered previously without major incident, e.g. [2].  This is purely a performance question; there is little security relevance, because we are speaking about answers delivered from the same resolver and query path as all the other DNS responses.

In any case, RFC 8484 DoH already defines DNS Push (Section 5.3), along with some rules about when it cannot be used.  It does not, however, provide any additional guidance that might support practical use, and has some significant limitations.  Including this topic would allow us to improve the specification of DNS Push, or indeed deprecate it if that is the technical consensus.

[2] https://tools.ietf.org/html/draft-wkumari-dnsop-multiple-responses-05<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-wkumari-dnsop-multiple-responses-05__;!rx_L75ITgOQ!QpYiYmLfw5x0GNCzn55qgsVeik8Scqtt7RQzzTGhG4peCplTE5ij67Tt1xPomd8TK2_YaQ$>

So long
-Ralf
—--
Ralf Weber
--
Add mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/add<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/add__;!rx_L75ITgOQ!QpYiYmLfw5x0GNCzn55qgsVeik8Scqtt7RQzzTGhG4peCplTE5ij67Tt1xPomd-iZisPzQ$>