On Thu, Jul 27, 2023 at 03:04:37AM +0000, Edward Lewis 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:
>
> Launching off this observation (and realizing there's a whole thread
> following it), I wanted to register some discomfort with this
> approach.
It is decidedly pragmatic. Negative responses (NODATA or NXDOMAIN)
require presenting NSEC or NSEC3 RRs to extant resolvers. Introducing a
new flavour of denial existence would require a fresh batch of DNSSEC
algorithms (just like NSEC3 required adding algorithm 7 to supplment
algorithm 5). Requiring broad support for a new algorithm would make
CDoE impractical for quite some time.
> # An NSEC record (and its associated RRSIG RRset) MUST NOT be the only
> # RRset at any particular owner name. That is, the signing process
> # MUST NOT create NSEC or RRSIG RRs for owner name nodes that were not
> # the owner name of any RRset before the zone was signed. The main
> # reasons for this are a desire for namespace consistency between
> # signed and unsigned versions of the same zone and a desire to reduce
> # the risk of response inconsistency in security oblivious recursive
> # name servers.
>
> What is most significant in that text is the "desire for namespace
> consistency between signed and unsigned versions of the same zone".
> With this proposal providing an answer that says "yes the name exists
> but it doesn't have what you want" contradicts the unsigned response
> that would indicate NXDOMAIN, there is an inconsistency in what is
> seen in the signed and unsigned zone.
That's admirable for pre-signed zones, but for on-the-fly signing with
zones that may not even have a well-defined whole zone point in time
snapshot (loosely coherent, eventually consistent, across various
authoritative copies) that text has little relevance.
> With signing on the fly, that approach makes no sense - you should be
> able to send a tailored response.
The cleanest solution is to use an *EMPTY* type bitmap for NXDOMAIN
responses. It likely works just fine in extant resolvers. The apparent
denial of the very NSEC and RRSIG records that evidence the denial of
existence is unlikely to be an issue. In particular, (and I believe
this to be a feature), even for a qtype "NSEC" query, the answer section
remains empty (the name does not exist), and the type bitmap denies the
existence of the NSEC RRset.
;
; QUESTION
nxdomain.example. IN NSEC ?
; AUTHORITY
example. IN SOA ...
example. IN RRSIG SOA ...
nxdomain.example. IN NSEC \0.nxdomain.example. ; (EMPTY type bitmap)
nxdomain.example. IN RRSIG NSEC ...
The NSEC RRs in the authority section are not answer records, and don't
constitute an answer to the request for the NSEC records associated with
the qname. It would be greate to see some interop testing of this or a
similar variant of pruned type bitmaps. We already know that the
unexpected "NSEC RRSIG" is working out OK, can we prune the bitmap even
more?
> A tailored response, i.e., "there's no name matching the QNAME", means
> there's no need to mention the next name. This would be great - no
> need to sort the zone, no need to assist zone walking, etc. The NSEC
> record is just not built for that though, it's an entirely ill-fit.
This is entirely impractical with extant algorithm codepoints.
> We have the NSEC record, it's implemented and deployed. (I'm just not
> considering NSEC3 as it's similar in approach despite it working on
> hashes and not names.) Rolling out a new approach (say "NSEC17")
> would be an uphill battle (although we did roll out NSEC3...), assumed
> to be more work that force-fitting on-the-fly signing into NSEC.
We rolled out NSEC3 by introducing new algorithm code points, and
eventually these weere widely enough deployed to allow zones to be
signed with 7/8/10/13/14 without being seen as insecure by a significant
fraction of resolvers. I don't expect CDoE to wait for the ~5 years or
more that this would take.
--
Viktor.
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
