On Mon, Jul 24, 2023 at 1:55 PM Viktor Dukhovni <ietf-d...@dukhovni.org> wrote:
> In today's session we had some discussion of the choice of sentinel > RTYPEs for ENTs vs. NXDOMAIN. > > There isn't much in the meeting to cover the fine details of various > alternatives, so I hope a followup message will make my comments more > clear. > > 1. I am all in favour of distinguishing NXDOMAIN from ENT. This is > a reasonable prerequisite for any proposal. > > 2. That said, there are multiple ways to *distinguish* ENT vs. NXDOMAIN > responses: > > a. Sentinel RTYPE for NXDOMAIN with just NSEC + RRSIG for ENT. > b. Sentinel RTYPE for ENT with just NSEC + RRSIG for NXDOMAIN. > c. Distinct sentinel RTYPEs for both ENTs and NXDOMAIN. > > Presently, the draft is proposing option "a". My point is that with "a" > we get a response that is promising the existence of an RRset for a name > that does not exist: > > Q: nxdomain.example. IN NXNAME ? > A: ??? > > - How should such a query be answered? How should the answer be cached? > - How is denial of existence of that RRset validated by legacy resolvers? > > It is far from clear that there's a clean/consistent answer to the above > questions. > > On the other hand, with "b", we can still distinguish NXDOMAIN from ENT, > because NSEC records with just "NSEC RRSIG" in the type bitmap are not > valid for ENTs. Once the providers currently "abusing" this response > form also for NXDOMAIN adopt the final spec, the ambiguity goes away. > > And, in this, it is possible to answer queries for the ENT sentinel > RTYPE, by returning an associated empty RDATA and RRSIG that can be > cached. The ENT is then a bit less "empty" than before, but the > resulting state is consistent. > > Q: enthere.example. IN ENTNAME ? ; > A: enthere.example. IN ENTNAME "" ; Zero-length RDATA > enthere.example. IN RRSIG ENTNAME ... > > The result can be cached, and it is not inconsistent with the existence > of the node as an (almost) empty non-terminal. > > The compact version of an ENT gains a additional RRset, but this can be > validated by legacy resolvers with no issues. > This "b" proposal is definitely prefered for all the reasons Viktor outlined. However, I had a thought about NSEC(3) bitmaps vs actual RRs. Since the compact responses are created and signed on-the-fly, there may be more explicit ways of signaling NXDOMAIN. I haven't thought this through completely, so it may be wrong or a really bad idea, but it might be worth thinking about and/or testing if it isn't totally wacky. I believe there are three potential query/answer things that on-line signers want to compactly respond to: 1. Name exists, other types exist, queried type does not exist 2. Name exists, no types exist (ENT), queried type does not exist 3. Name does not exist What if, rather than a response that needs inference for (3), an explicit response is provided, in the form of a signed record? It might not ever need to occur in an NSEC bitmap, since the name itself doesn't exist. So, for ENT, respond with "b" per Viktor (sentinel bitmap) For NXDOMAIN, respond with an actual NXNAME (no RDATA) and corresponding RRSIG. And for clarity, this would only be sent by an auth server doing compact DoE. Any other server doing offline signing would never *need* to send NXNAME records (but in theory, could, in addition to the normal NXDOMAIN response.) To explain the logic here: I'm borrowing this from DNAME, which provides DNAME (signed) plus CNAME (unsigned) to handle the backward compatibility issues in case the client does not understand DNAME. In the case of DNAME, DNAME is a (significant) optimization, is signed and validatable and cacheable; it is clearly preferable that the client understand and use DNAMEs if they exist. But, it is still only an optimization, as the legitimate (but unsigned) CNAME response is included. The reverse would be true for NXNAME: A client that didn't know about NXNAME would still be able to infer the NXDOMAIN (assuming it had the proper logic implemented). A client that knows about NXNAME might be able to use and cache that response with less work. I think the backward compatibility (if I am correct, and it tests true) would mean this could be unilaterally be deployed by auth servers immediately, avoiding any chicken/egg or critical mass problems. NB: *lack* of NXNAME does not automatically promote a name into existence. NXNAME is merely a shortcut to avoid inferences and extra work by signers and resolvers. Thoughts? Brian
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
