On Tue, Jul 25, 2023 at 3:39 PM Shumon Huque <shu...@gmail.com> wrote:
> 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. > So, to recap the requirements that this is attempting to provide a solution for: - Online signers want to be able to provide a response for names that don't exist, in signed zones, without doing NXDOMAIN (which requires 2-3 signatures) - Some current implementations don't either provide answers that don't give clear distinction between NXDOMAIN and ENT - Other current implementations provide bitmaps in NSEC(3) records that claim types exist when they do not - The goal is to give answers that work for both CDoE and regular offline-signed zones, and permit distinguishing ENT from NXDOMAIN, and where CDoE signers only need to generate one signature. The non-NXDOMAIN answer is problematic already, I believe. What if it were possible to provide a solution to all of those requirements, AND give resolvers an actual cacheable NXDOMAIN? It's ugly, it's a kludge, it will likely be shouted down, but I think there is one method that could work. At the name that does not exist, generate and sign (on the fly) a CNAME record with RDATA of something like "nxname.empty.as112.arpa" (or something functionally equivalent). Only one signature is required, since there is an answer, rather than just an NSEC(3) with bitmap. The target of the CNAME is out of bailiwick, so the resolver would need to obtain that, and get the NXDOMAIN result from that response (which results in NXDOMAIN to the client). All of these are cacheable. If/when empty.as112.arpa is signed, the full chain would be protected by DNSSEC. ENTs are distinguishable (they would get the current ENT response of NSEC/RRSIG bit map) Am I incorrect in the asserted behavior of such a synthesized CNAME (and that it would match the requirements)? (It's not a DNAME, but is kind of close to it. :-) ) Brian
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
