Re: [DNSOP] [Ext] Compact DoE sentinel choice

[Edward Lewis <[e-mail]>]

On 7/24/23, 1:55 PM, "DNSOP on behalf of Viktor Dukhovni" <[e-mail] on behalf of [e-mail]> 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.

The definition of DNSSEC in RFC 4035 contains this paragraph:

#   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.

Note: I'm not trying to say "we have to stick to the old rules", I'm trying to look at the environment in which the DNSSEC was born and how we went from concept to reality (then).

In some sense, this proposal is establishing a (set of) wildcard(s) (source[s] of synthesis) that owns just an NSEC record when it applies to otherwise NXDOMAIN responses.  Mulling this over, it becomes apparent that the next name field in the NSEC record is a problem - wildcards allow for the inclusion of an owner name pulled from the query (and DNSSEC accommodates that via the label count) but there is no process for modifying the RDATA in a synthesized record.  The lack of a process for modifying the RDATA means that "this is something entirely new".

 I think that signing on the fly is a great idea.  But when DNSSEC was defined, and specifically here the NSEC record, it was assumed that DNSSEC records would be generated on machines air-gapped from the network because the state of the art in host security was simply poor.  This forced the design to take on an approach of showing the querier "here's what I do have, you can deduce that your request has no answer (NXDOMAIN)".  With signing on the fly, that approach makes no sense - you should be able to send a tailored response.

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.

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.

But I'm not so sure - because of the potential problems with inconsistencies introduced.

I'm not saying "this can't work" - I'm raising a concern...and hoping some thought/work is done to come up with a new approach that is built to support the modern world.