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

[Ben Schwartz <[e-mail]>]

On Thu, Nov 14, 2019 at 7:42 AM Ralf Weber <[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 and “resolver B” for example.net.


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


> > - 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

So long
> -Ralf
> —--
> Ralf Weber
>