Dne 24. 10. 22 v 20:18 David Conrad napsal(a):
Libor,
On Oct 24, 2022, at 9:11 AM, libor.peltan <libor.pel...@nic.cz> wrote:
The root of the DNS is a commons, supported by volunteers who are paying out of
their own pocket to provision a global infrastructure. I’m personally not
comfortable recommending techniques that can add undefined (could be minimal,
might not be: no one knows for sure) load to that infrastructure.
Well, the modern and well-configured resolvers will protect Root servers by employing
Aggresive Negative Caching or Root Zone Prefetch (and eventually Query Name Minimisation
for the sake of querier's privacy); outdated and broken resolvers will keep bombing the
root's auths with junk queries even if we declare they MUST NOT. As a consequence, those
arguments for this "MUST NOT" are moot.
We appear to be arguing about wording/capitalization.
I don't think so.
Obviously, simply saying “MUST NOT” in an RFC will have (and has always had)
zero effect on code behaviors. What matters is what people actually implement.
If a modern/well-configured iterative resolver/forwarder implements according
to (the potential future) spec (either “MUST NOT” or “should not”), then all
queries for .alt sent by outdated/broken stub resolvers will not bomb the root
as soon as the modern code is deployed. As applications/operating systems get
updated over time, even the stub resolvers could behave better. However,
implementation of code is all about priorities. I personally believe that, in
general, a spec that says “MUST NOT” has a slightly higher likelihood of being
prioritized over a spec that says “should not” but maybe that’s just me.
So far, the modern features like Aggresive Negative Caching and Root
Zone Prefetch (hereinafter: (*)) are already standardized and being
implemented by a (hopefully) raising fraction of resolvers. Do you think
that if we now standardize this explicit blockade of specific TLD for
resolvers, it will get implemented much faster and broadlier than (*)
and protect the Root zone in the meantime before (*) is implemented
sufficiently close-to-everywhere?
The real point here is #3 in the list I provided earlier:
"3) whether the inevitable leakage of .alt queries to the DNS represent potential
issues, and if so, should there be an effort to address those issues."
Using the AS112 project approach could help address the leakage to the root
issue (even for outdated/broken resolvers), although it wouldn’t generally
address the privacy leakage issue. It also has its own implications (e.g.,
delegating an explicitly non-DNS TLD in the DNS). Given the AS112 approach
doesn’t result in code change, would you be ok with using it with .alt?
I don't like neither lame delegation of non-DNS name in DNS Root Zone,
nor lame DNAME therein.
I would expect the correct approach is:
1) Put a proper MUST NOT into the piece of software that will be
responsible for determining DNS and non-DNS queries. It should prevent
query leakage into DNS as much as possible.
2) If it doesn't, the resolver should be able to avoid any lame queries
(not limited to .alt) to Root zone with the help of (*). We don't need
any RFC for this -- this already happens, and frankly: if Quad8
implements this, half of the problem is gone.
3) If it doesn't, the Root servers shall be solid enough to withstand a
stream of lame queries (not limited to .alt). We don't need and RFC for
this, this already happens.
On the other hand, I agree that an analysis of how heavily the Root
Server could potentially be impacted by stray .alt queries would be
beneficial for deciding if we need to implement a defense and how. But I
doubt this is possible to estimate.
Regards,
-drc
Libor
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
