> On Nov 24, 2021, at 7:24 PM, Robert Evans <[email protected]> wrote: > > On Wed, Nov 24, 2021 at 12:38 AM Bill Woodcock <[email protected]> wrote: > I agree with Ben’s assumptions and conclusions. > > I believe that, although I myself do not believe the assumed constraints hold > in the real world, that there will be others who do. I believe that > proceeding on the assumption that those hypothetical others’ hypothetical > objections must be addressed is the correct path. And I believe that we are > not blocked from the unoptimized/simpler path in the mean time. > > What level of interest is there for adopting the unoptimized/slower paths?
I, and a number of others, have been trying to move forward with them. My
personal belief is that this is an 80/20 situation, where the 20% of the work
to get to the unoptimized state will yield 80% of the benefit. And for large
operators, nearly 100% of the benefit. Because the larger the DNS operator,
the larger the portion of their traffic that goes to (the same unchanging set
of) other large operators. Since those will be long-lived TCP flows to known
destinations, all of the optimizations aimed at jump-starting new connections
for unknown counterparts won’t apply. And, honestly, probably won’t be worth
the work of implementing, though if the tools automate it well, then that work
could hypothetically be minimal.
What would not be a minimal amount of work, though, is moving forward over the
objections of people who believe that only 100% solutions are acceptable. So,
having the 100% solution out there in the future to appease them and for them
to work on, while the rest of us move forward with the 80% solution, suits me
fine.
> If we had a non-parent signal, would any real-world operators adopt it beyond
> limited experimentation (accepting extra RTTs and leaky queries)?
Seems unlikely.
> If so, would operators prefer to use these signals synchronously (strict
> security, slow) or asynchronously (use TLS when ready, fast, but leaky)?
I wouldn’t care to hypothesize about the preferences of hypothetical operators
that I’m not convinced exist.
-Bill
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
