Paging this thread back in after a break ...
On Tue, Jul 25, 2023 at 8:07 PM Viktor Dukhovni <ietf-d...@dukhovni.org>
wrote:
> On Tue, Jul 25, 2023 at 03:39:01PM -0700, Shumon Huque wrote:
>
> > Viktor - your original suggestion was to only define the ENT sentinel
> > instead of NXNAME. How would that solve the problem of systems and
> > applications needing to precisely obtain the NXDOMAIN signal. Resolvers
> > won't then be able to tell whether a NOERROR bitmap of "NSEC RRSIG"
> > is a normal ENT response from a non Compact DoE implementation, or an
> > NXDOMAIN response from a Compact DoE implementation.
>
> 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.
It also seems to be an unnecessary complication that can be avoided.
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.
(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).
On Thu, Jul 27, 2023 at 11:31 PM Viktor Dukhovni <ietf-d...@dukhovni.org>
wrote:
> On Tue, Jul 25, 2023 at 03:39:01PM -0700, Shumon Huque wrote:
>
> > Viktor - your original suggestion was to only define the ENT sentinel
> > instead of NXNAME. How would that solve the problem of systems and
> > applications needing to precisely obtain the NXDOMAIN signal. Resolvers
> > won't then be able to tell whether a NOERROR bitmap of "NSEC RRSIG"
> > is a normal ENT response from a non Compact DoE implementation, or an
> > NXDOMAIN response from a Compact DoE implementation.
>
> I may not have answered Shumon's question in full. The missing
> piece is that "NSEC RRSIG" isn't a "normal ENT response". In
> classic RFC 4035 DNSSEC, ENTs aren't part of the NSEC chain
> (NSEC records are associated only with names that appear as
> explicit nodes in the zone with at least one real RRset).
>
> To prove an ENT, a classic DNSSEC server returns:
>
> strictly-prior-node. IN NSEC descendent-of-ent. <bitmap for prior node>
>
> The fact that the next name is a descendent of the ENT, proves the
> existence of the ENT as an empty node.
>
> There are never any "NSEC RRSIG" bitmaps is classic DNSSEC. This
> combination has to mean something special is going on.
For classic "pre-computed" DNSSEC, yes. But we also need to distinguish
these responses from RFC4470 ("by-the-book" online signing) responses.
For empty non-terminals, they will return a minimally covering NSEC record
matching the ENT with a type bitmap of "NSEC RRSIG" -- that is not
distinguishable from a Compact DoE non-existent name response, if the
latter does not provide the NXNAME sentinel.
The NXNAME sentinel also provides the explicit means to implement
the signaled NXDOMAIN rcode restoration mechanism for DO=1 queries
that I mentioned in my IETF117 presentation. (The utility of that proposal
needs to be weighed of course against the additional complexity cost, and
against the possibility of misc software being updated to directly recognize
the NXNAME meta-type signal instead).
Shumon.
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
