On Mon, Aug 07, 2023 at 08:51:36PM -0400, Shumon Huque wrote:
> Paging this thread back in after a break ...
>
> > For ENTs, there is no inconsistency, the nameserver can return a signed
> > answer with an empty RDATA for the ENTHERE (TBD) rtype.
> >
> > ; QUESTION:
> > ent.example. IN ENTHERE ?
> >
> > ; ANSWER:
> > ent.example. IN ENTHERE ""
> > ent.example. IN RRSIG ENTHERE ...
>
> That's an interesting idea, but it is contrary to our intention to make
> ENT (and/or NXNAME) a meta-type, which is defined to not own any
> cacheable zone data.
How is that going to be understood by extant validators that are unaware
of the new meta type code points? Why is the new meta type actually
necessary? Would it not be simpler to avoid it, and instead
differentiate the two cases by which combination of RRSIG and NSEC is
present?
In particular how is denial of the metatype itself handled? How should
such a denial affect a resolver's cache... The draft should cover all
the relevant query scenarios, rather than leave them unspecified.
> It also seems to be an unnecessary complication that can be avoided.
Another viewpoint is that such new metatypes are unnecessary complications.
> My earlier proposal still seems simpler to me: define explicit queries
> for ENT/NXNAME to return an NSEC bitmap with only "NSEC RRSIG"
> (i.e exclude the meta type). I took a quick look at NS1 just now, and they
> already appear to do this for ENT -- I tested a bunch of different resolver
> implementations with such queries and they all seem to behave fine.
So now the distinction between NXDOMAIN and ENT disappears, and the
response supercedes any cached response with the NXNAME signal, and
so now clients behind the resolver no longer see NXDOMAIN until the
cached entry times out? Is that right???
> (My other suggestion was to treat ENT/NXNAME queries as real
> meta-types that should elicit an error - BIND/Unbound appear to return
> FORMERR for such types).
So resolvers would then need to refuse these queries (return FORMERR or
REFUSED) and stubs will have to learn over time to not ask?
--
Viktor.
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
