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. > Viktor, For (a), apart from some mental incongruity, what practical operational problem do you see this causing? I am not seeing one, but I'd be happy to be educated. The (proposed) response is: nxdomain.example. NSEC <next> NSEC RRSIG NXNAME If a resolver caches this, what problems can it cause? Even in the case of Aggressive negative cachers that perform type inference, there is no actual data type whose existence could be denied and lead to problems. (The main operational issue I see is the more general one that already exists, unrelated to what sentinel we choose - NODATA for NXDOMAIN leads to unnecessary follow-on queries for other types at the same name. That issue can only be solved with rcode substitution or stub resolver code enhanced to recognize these sentinels). When we get a formal allocation for a meta-type for NXNAME (or ENT), servers could recognize that fact and return an error or at least refuse to cache (because it's not a data type or query type). I think there are implementations in the field that already deal with meta-types received in DNS queries in this way. There is one other possible advantage to the NXNAME sentinel. It makes the ENT response from both Compact DoE and RFC 4470 online signers uniform (NODATA + type bitmap: RRSIG NSEC). There is no way to make the NXDOMAIN response uniform of course, but at least there is some uniformity that was recovered. Again, as a practical matter, I'm not sure how compelling this observation is either (in terms of actual operational issues). Shumon
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
