On Tue, Jul 25, 2023 at 8:42 AM Viktor Dukhovni <ietf-d...@dukhovni.org> wrote:
> 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. > 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? Shumon.
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
