Subject: [dns-privacy] Comments on draft-dkgjsal-dprive-unilateral-probing

From: Ralf Weber <[email-masked]>
Date: Thu, 11 Nov 2021 10:49:26 -0400

Moin!

As technology didn’t work here are the comments I wanted to make on the mic:

The draft mainly seems to focus on a single recursive to authoritative interaction. Most domains have more then on name server and the selection of them often is quite complex and differs between implementations ( I recall some very interesting and entraining DNS-OARC talks about that topic, though don’t have links handy ). Now what shall a resolver do if 1 out of the say 4 servers offers encryption and the others not? And when it later comest to signals  on the domain level a full cold recursion often goes to multiple TLDs, SLDs that all have different name servers, at what level should the resolver fail?

While the IP address might be a good identifier on where to encrypt to we recently had a situation where an authoritative server with the same IP did answer just fine for one domain, but did, because the domain was used in an attack earlier drop all packets if you asked it for another domain. So I think you would need more then just the IP especially if you are wanting to use signals.

And answering Brian Dickson on the idea of a client signalling a resolver to encrypt a resolution I think is a non starter for the amount of complexity involved. What would you do if you had a half finished resolution form an non private client and then got a request for the same name again from a privacy wanting client? What to do if the answer in Cache came from an non secure resolution?

So long
-Ralf
——-
Ralf Weber

---

From: Christian Huitema <[email-masked]>
Date: Thu, 11 Nov 2021 07:28:13 -0800

> While the IP address might be a good identifier on where to encrypt to we recently had a situation where an authoritative server with the same IP did answer just fine for one domain, but did, becau…

Or, "server" is in fact a cluster of servers behind a load balancer and 
a single IP. It is not uncommon to see upgrades being rolled out at 
different times to different servers in the farm. Opportunistic 
strategies and probing strategies have to deal with that.

-- Christian Huitema

---

From: Jim Reid <[email-masked]>
Date: Thu, 11 Nov 2021 16:16:24 +0000

> On 11 Nov 2021, at 15:28, Christian Huitema <[email-masked]> wrote:
> 
> It is not uncommon to see upgrades being rolled out at different times to different servers in the farm. Opportunistic strategies and probing strategies have to deal with that.

This can be complex. Lots of busy domain names (like TLDs) use a combination of DNS servers that are managed and operated by different organisations using different flavours of softwware for the obvious SPoF reasons. Which means upgrades can be like changing a plane's engines in mid-flight. For instance, look at how long it took for all 12 RSOs to be in a position to support DNSSEC and IPv6.

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 19 Nov 2021 18:19:34 -0500

> This can be complex. Lots of busy domain names (like TLDs) use a combination of DNS servers that are managed and operated by different organisations using different flavours of softwware for the ob…

Thanks for this discussion, y'all.

I've tried to capture these thoughts with some additional text in the
draft, which you can see here:

  https://gitlab.com/dkg/dprive-unilateral-probing/-/commit/477721af91dc517a0696c27a7ae3b6a97f8795a3

In particular, there's a section about how authoritatives can more
safely deploy in a heterogenous pooled or anycasted situation:

------------
## Pooled Authoritative Servers Behind a Single IP Address {#authoritative-pools}

Some authoritative DNS servers are structured as a pool of authoritatives standing behind a load-balancer that runs on a single IP address, forwarding queries to members of the pool.

In such a deployment, individual members of the pool typically get updated independently from each other.

A recursive resolver following the guidance in {{recursive-guidance}} that interacts with such a pool likely does not know that it is a pool.
If some members of the pool are updated to follow this guidance while others are not, the recursive client might see the pool as a single authoritative server that sometimes offers and sometimes refuses encrypted transport.

To avoid incurring additional minor timeouts for such a recursive resolver, the pool operator should either:

- ensure that all members of the pool enable the same encrypted transport(s) simultaenously, or
- ensure that the load balancer maps client requests to pool members based on client IP addresses.

Similar concerns apply to authoritative servers responding from an anycast IP address.
As long as the pool of servers is in a heterogenous state, any flapping route that switches a given client IP address to a different responder risks incurring an additional timeout.
Frequent changes of routing for anycast listening IP addresses are also likely to cause problems for TLS, TCP, or QUIC connection state as well, so stable routes are important to ensure that the service remains available and responsive.

------------

and a bit of a reminder for operators of recursive resolvers:

------------
### Separate State for Each of the Recursive Resolver's Own IP Addresses {#resolver-binding}

Note that the recursive resolver should record this per-authorititative-IP state for each IP address it uses as it sends its queries.
For example, if a recursive resolver can send a packet to authoritative servers from IP addresses 192.0.2.100 and 192.0.2.200, it should keep two distinct sets of per-authoritative-IP state, one for each source address it uses.
Keeping these state tables distinct for each source address makes it possible for a pooled authoritative server behind a load balancer to do a partial rollout while minimizing accidental timeouts (see {{authoritative-pools}}).
------------

We'll include something along these lines in draft -01.  If you'd like
to propose fixes or raise concerns, Joey and I would be happy to
incorporate them.

            --dkg

---

From: Ben Schwartz <[email-masked]>
Date: Mon, 22 Nov 2021 11:27:50 -0500

On Fri, Nov 19, 2021 at 6:48 PM Daniel Kahn Gillmor <[email-masked]>
wrote:
...

> To avoid incurring additional minor timeouts for such a recursive
> resolver, the pool operator should either:
>

Nit: These should not be timeouts.  The non-participating backends are
expected to return TCP RST or ICMP Destination Unreachable (Port
Unreachable), leading to immediate fallback after 1 RTT.  Maybe the draft
needs some guidance to that effect.

A timeout is still possible if the network is misbehaving (e.g. ICMP
blackhole), but it shouldn't happen otherwise.

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 24 Nov 2021 09:57:04 -0500

> blackhole), but it shouldn't happen otherwise.

Thanks, Ben!

I agree that these shouldn't necessarily be "timeouts" -- but it's not
just network misbehavior that could cause them to be timeouts, there are
some service administrators who believe that having ports in "stealth
mode" (i.e. not responding with a "port closed" ICMP response) is
somehow safer; and, in the event of extreme resource exhaustion, it's
conceivable that TCP RST messages wouldn't get sent.

So "timeout" is there to make sure we handle all of these cases, and we
do still want to minimize the number of places where we risk incurring
them, since neither sender nor receiver can guarantee that the
appropriate signalling makes it through in a timely fashion.

Any concrete proposals for what text to change or add would be welcome!

    --dkg