In your letter dated 4 Oct 2024 13:31:36 -0400 you wrote: >>There is no reason to assume that clients are constructing names that they >>don't want to the target zone to know. > >But the presumably don't want the TLD to know them. Query minimization would >only show e.example to the example TLD, but fake NODATA sends the TLD the whol >e >name.
If a stub resolver askes for a.b.c.d.example and d.example does not exist then example is the target zone. It is also a TLD, but if d.example does not exist then any query for a.b.c.d.example is directed at the zone example. The question then becomes how likely it is that clients construct such names. I can imagine somebody typing a long name and making a mistake somewhere. But who does that these days. >Per that other note reminding us that restoring NXDOMAIN breaks DNSSEC, I'm >wondering how useful this is likely to be in practice, unless you assume >that nobody uses DNSSEC in stubs now and never will. I now wonder. Any unmodified DNSSEC validator. If the query is for a.b.c.d.example and d.example does not exist. Then if d.example results in NODATA then the validator requires at least NODATA for a.b.c.d.example otherwise validation will fail. So I guess that any query that arrives at a recursive resolver with DO and optionally CD set could be from an unmodified DNSSEC validator. So the recursor has to obtain the NODATA result for a.b.c.d.example. _______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
