On Thu, 2022-02-03 at 12:59 -0500, Daniel Kahn Gillmor wrote:
> Hi Peter, DPRIVE folks--
>
> On Thu 2022-02-03 11:03:35 +0100, Peter van Dijk wrote:
> > Speaking only for myself: some of the parts still seem too prescriptive
> > to me (but I know I haven't been clear on what parts!). Examples: 4.3.1
> > seems too focused on some specific load balancer implementations, and
> > causes a terrible combinatorial state explosion.
>
> §4.3.1 ("Separate State for Each of the Recursive Resolver's Own IP
> Addresses") was added specifically in response to concerns raised by
> load balancer operators, in coordination with §3.1 (guidance to the pool
> operators themselves), with a goal of convincing anyone interested that
> the system isn't going to be overwhelming as long as everyone involved
> sticks to a few simple and plausible guidelines.
Right, that makes sense!
> I don't think that there is a combinatorial state explosion here --
> every system that queries from a different outbound address just keeps
> its own copy of its state, no?
If they are separate systems, yes!
Some resolvers (such as Unbound) can use a whole /64 of v6 (or a /24 of
v4, if you happen to have one lying around) as extra entropy. In those
cases, it would really be a lot of extra state.
> It's possible that some other set of choices can offer equally
> unthreatening system analysis, but if we're proposing an alternative, we
> should write it down explicitly so that people can identify potential
> problems. Being able to reason about the system as a whole is an
> important part of this kind of description.
Agreed.
>
> One reason to be concerned about divergence from the described approach
> is if it interacts poorly with someone else's *different* divergence
> from approaches described in the draft, for example the guidance around
> operating and dealing with pools that we're discussing above ☺
Yes, that seems fair, and also a hard puzzle.
>
Kind regards,
--
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/
_______________________________________________
dns-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy
