On Tue, Jul 25, 2023 at 11:28 AM Viktor Dukhovni <ietf-d...@dukhovni.org> wrote:
> On Tue, Jul 25, 2023 at 10:43:25AM -0700, Shumon Huque wrote: > > > Ok, yes, I understand now, thanks. An NXNAME ignorant validator > > will treat a response to a query for the NXNAME type specifically > > as bogus, and could spray a bunch of follow-on queries to other > > servers for the zone before giving up and returning SERVFAIL. > > > > If the Compact DoE authority is specially defined to return only > > "NSEC RRSIG" in the type bitmap for explicit NXNAME queries > > for a non-existent name, doesn't that solve the problem? > > Yes, that could solve the problem, though NXNAME-aware resolvers would > need a somewhat tricky cache state, that holds and returns: > > - The NSEC record with the "NSEC RRSIG NXNAME" bitmap for most > RTYPEs > - The "NSEC RRSIG" bitmap if explicitly asked for NXNAME. > > The draft should describe the behaviour expected from auth servers, > and validating resolvers, including their responses upstream. > Yes, we could certainly do that. > To me a single signed record that proves NXDOMAIN regardless of the > query RTYPE sure looks simpler! The above is noticeably kludgier. > My preference would be to try to make this issue irrelevant by having DNS servers treat meta-types specially and return an error, or at least, in the case of resolvers, not cache any responses received for them. One challenge is that there isn't a unique range that identifies metatypes. Range 128 - 255 seems to unfortunately be for both meta-types and q-types. I did a quick test of BIND and Unbound just now - they return FORMERR for almost all of this range, but respond to specific q-types they support (IXFR/AXFR/*). And then, there is the issue of the period of time where we are using private RR type codes. There is no meta-type subset range in there that is treated differentially. Viktor - your original suggestion was to only define the ENT sentinel instead of NXNAME. How would that solve the problem of systems and applications needing to precisely obtain the NXDOMAIN signal. Resolvers won't then be able to tell whether a NOERROR bitmap of "NSEC RRSIG" is a normal ENT response from a non Compact DoE implementation, or an NXDOMAIN response from a Compact DoE implementation. > Especially simple would be using just distinct combinations of > "NSEC" and "RRSIG" for NXDOMAIN vs ENT, with no new sentinel > types, provided resolvers can gracefully handle bare-bones > bitmaps that include a proper subset of "NSEC RRSIG". > I think that suggestion would need detailed testing and also possible arguments with DNSSEC protocol correctness people. The NSEC record is designed to prove its own existence and is required to have NSEC and RRSIG in its type bitmap if I recall. Shumon.
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
