On Tue, Jul 25, 2023 at 07:35:41AM -0700, Shumon Huque wrote:
> > 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.
> >
>
> 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.
If the query is actually for the NXNAME rtype, the NSEC response is
bogus, because the bitmap promises the requested RTYPE, but the response
is NODATA (sentinel NXDOMAIN). Existing resolvers will servfail and
perhaps try a few more servers. There's also no correct response to
an upstream client that send DO=1.
> The (proposed) response is:
>
> nxdomain.example. NSEC <next> NSEC RRSIG NXNAME
It is fine if the qtype is "A", "AAAA", "HTTPS", "MX", ... but not
when the qtype is the new NXNAME type.
> If a resolver caches this, what problems can it cause?
As a response to typical queries it is fine, but not as a response to an
NXNAME query (bogus).
> 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.
Sure there is, the NXNAME type.
> 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).
My read of 4470 is that the server is supposed to return a *covering*
record where neither endpoints is the denied name.
enszzzz.example. IN NSEC \000.ent.example. NSEC RRSIG
This is because an ENT is not "instantiated name". However, 4470 fails
to give concrete examples or advice of how to report ENTs.
> 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).
To me, "uniformity" is less important than logical consistency, and
putting an RTYPE other than NSEC or RRSIG in an NXDOMAIN response
creates a logically inconsistent status for the sentinel RTYPE.
How are authoritative servers supposed to respond to queries for that
RTYPE??? How are existing resolvers supposed to handle that response?
--
Viktor.
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
