On Wed, 24 Nov 2021, Bill Woodcock wrote:
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.
Not only that, but the in-baliwick parts are fairly meaningless anyway,
as protecting in-baliwick either adds no real privacy. Either it reveals
a well known large auth server responsibly for huge amounts of domains
that knowing the nameserver won't tell you anything anyway, or it goes
to a tiny nameserver that even if fully encrypted and private, by itself
reveals the target was interested in 1 of a few possible domain names.
And once you are take this into account, just adding a TLSA record at
the nameserver name works fine. As you said, the vast majority of these
can then be long living HTTPS / TLS / QUIC connections.
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.
A signal on the parent domain seems mostly not adding anything if the
signaling for encrypted transport happens over the nameserver names.
Paul
_______________________________________________
dns-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy
