On 7/28/23, 1:48 PM, "DNSOP on behalf of Viktor Dukhovni"
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.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
