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.

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.

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?

Regards,
-drc

Attachment: signature.asc
Description: Message signed with OpenPGP

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to