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

[Edward Lewis <[e-mail]>]

On 7/28/23, 1:48 PM, "DNSOP on behalf of Viktor Dukhovni" <[e-mail] on behalf of [e-mail]> wrote:

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

"Minimally Covering NSEC Records and DNSSEC On-line Signing" is referenced in the Compact Denial of Existence draft, it was published in 2004 (aka RFC 4470).  I can't determine which internet draft led to that document so I can't tell when discussions on this topic began.  Suffice it to say, this has been hanging around a very long time - enough time for a person to be born, raised and graduate from public schools (~18 years).  Persuasively I'll claim that this is the result of trying to be pragmatic when updating a protocol.  (Meaning - "what's another few years"?.)

I also think that software is updated more quickly, when motivated.  That's one lesson from the 2018 root zone KSK roll.  But I won't concentrate on that here.

What's pragmatic for protocol engineering may not be suitable for operations.  I'm concerned with the low deployment of DNSSEC, 25 years since the first meeting to spur adoption.  Having sat through years of messaging that "operators need to be informed" and "we need to present the business case" without much success has led me to think inward.  My hypothesis (note-hypothesis) is that DNSSEC is not (entirely) suitable for operations.  My theory is that we need to be driving towards a simpler protocol, and as part of that, we need to avoid trying to retrofit "what is needed in the world now" into "what was designed for the world we anticipated in 1990."

This is the reason I'm objecting to this approach.

One of my objections is that this approach will make names that are non-existent (per the definition in "The Role of Wildcards in the Domain Name System") and reply to queries with records owned by the name.  In replies without DNSSEC records, the response code would be NXDOMAIN and in replies with DNSSEC records, the answer appears to be a no error but no data response.  This means the zone would be seen differently depending on whether the recipient reads DNSSEC or not.

Another objection is in the redefining of fields.  While the implementation of signing and validation may be able to accommodate using "dummy resource record types" (such as meta types designed to be in the range 128-255), whether management tools will be able to keep up needs to be kept in mind as well as the increasing skillset needed by the operations staff (who will be called in when customers do not get what they expect).

E.g., while preparing this message I tried these two dig messages:

dig somename.cloudflare.com a @ns3.cloudflare.com.
and
dig somename.cloudflare.com a

The first returned NXDOMAIN, the later NoError/NoData.  If I were a human trying to figure out a problem with a wildcard not matching, the difference between these two responses would be significant.  (The reason existence is defined in the wildcard document is that existence matters when applying the synthesis rules.)

I encourage updating DNSSEC to fit into the modern world.  The result ought to lead towards higher adoption - by making DNSSEC a "no brainer" to deploy and operate.  I'm urging that this be done in the (unquantified here) right way.  I have my doubts that fitting new meanings into old formats is the way to go.