Where did DNSSEC go wrong?
5 hours ago
- #Internet Protocols
- #DNS Security
- #DNSSEC
- Economics are against DNSSEC’s adoption despite deployment in most Top-Level Domains (TLDs).
- DNSSEC's architecture from the 1990s reflects an era with insecure protocols and limited commercial hosting.
- DNSSEC's three technical objectives: authentication of data, integrity of data, and authentication of negative answers.
- Precomputed responses in DNSSEC lead to larger responses and reveal unnecessary information.
- On-the-fly signing is feasible but complicates integration with DNSSEC's precomputed answer assumption.
- DNSSEC's design assumes a singular 'zone administrator,' hindering parent-child delegation relationships.
- DNSSEC adoption has grown top-down, contrary to initial expectations of bottom-up growth.
- The DELEG record in IETF efforts is important for DNSSEC's parent-child zone relationships.
- DNSSEC's two key roles (KSK and ZSK) double workload and complicate explanations.
- A Common Signing Key (CSK) simplifies DNSSEC management with automated provisioning.
- DNSSEC treats all zones equally, overlooking the root zone's unique position requiring Trust Anchors (TAs).
- Initial DNSSEC workshops involved DNS operators with protocol-shaping skills, leading to overconfidence in design.
- Low DNSSEC adoption reflects design critiques, not just lack of education or promotion.
- DNSSEC's cryptographic assumptions were inspired by military/government use, leading to minimalist operator approaches today.
- Revisiting DNSSEC's past can inform future designs or enhancements for operator-friendly security.