RFC 9364

DNS Security Extensions (DNSSEC)

📅 published February 2023, from ietf

RFC 9364: DNS Security Extensions (DNSSEC) 🎀

Okay bestie, RFC 9364 is the DNSSEC one, and it's giving a whole guided tour 🦋. P. Hoffman from ICANN wrote it, and it was published in February 2023 by the Internet Engineering Task Force (IETF) 🌸. It's a Best Current Practice (that's BCP 237 for the IETF's rule book, with ISSN 2070-1721) 💜. The header doesn't list anything it obsoletes or updates, and the abstract says it doesn't update RFCs 4033, 4034, or 4035 ✨.

Abstract

okay so this doc describes DNS Security Extensions (lowkey known as "DNSSEC") as they're set out in RFCs 4033, 4034, and 4035, plus a handful of others 🧚. It has three goals. First, it puts all the RFCs in one spot so you can get the whole DNSSEC picture 🌈. Second, it says that using DNSSEC for origin authentication of DNS data is the best current practice 💅. Third, it's a single reference that other docs can point to when they want to mention DNSSEC 🫶.

Status of This Memo

bestie, this one is pure paperwork but it still matters 📝. It documents an Internet Best Current Practice 🔥.

It's a product of the Internet Engineering Task Force (IETF), it represents what the IETF community agreed on, it got public review, and the Internet Engineering Steering Group (IESG) approved it for publication ✅. If you want more on BCPs, check Section 2 of RFC 7841 🍓.

Info about the current status of this doc, any errata, and how to give feedback lives at https://www.rfc-editor.org/info/rfc9364 💖.

Copyright (c) 2023 IETF Trust and the persons identified as the document authors 💜. All rights reserved ✨.

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the publication date 🎀. Please read these carefully, because they spell out your rights and restrictions for this doc 🙈. Code components pulled out of this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Revised BSD License 💅.

Table of Contents

   1.  Introduction
     1.1.  DNSSEC as a Best Current Practice
     1.2.  Implementing DNSSEC
   2.  DNSSEC Core Documents
     2.1.  Addition to the DNSSEC Core
   3.  Additional Cryptographic Algorithms and DNSSEC
   4.  Extensions to DNSSEC
   5.  Additional Documents of Interest
   6.  IANA Considerations
   7.  Security Considerations
   8.  References
     8.1.  Normative References
     8.2.  Informative References
   Acknowledgements
   Author's Address

1. Introduction ✨

okay so the core spec for DNSSEC (that's the combo of [RFC4033], [RFC4034], and [RFC4035]) lays out a bunch of protocols that give you origin authentication of DNS data 🔐. [RFC6840] updates and extends those core RFCs, but it doesn't fundamentally change how DNSSEC works 🌸.

This doc lists the RFCs that someone building a DNSSEC implementation, or someone deploying DNSSEC as it's currently standardized, should look at 📚. We tried to be thorough, but don't assume the list is complete 🙈. It also uses terminology from those docs without defining it, so bring your homework 💅. It points to the relevant IANA registry groups for DNSSEC too 🧚. What it doesn't do is point to standards that depend on zones being signed with DNSSEC, like DNS-Based Authentication of Named Entities (DANE) [RFC6698] 💜.

1.1. DNSSEC as a Best Current Practice 💖

the main vibe here is that using the DNSSEC set of protocols is the best current practice for adding origin authentication to DNS data 👑. So far, no Standards Track RFCs offer any other way to do origin authentication of data in the DNS 🔥.

It's been more than 15 years since the DNSSEC spec was published, and it's still not widely deployed 😭. Recent estimates say fewer than 10% of the domain names used for websites are signed, and only around a third of queries to recursive resolvers get validated 💀. But low deployment doesn't change whether DNSSEC is a best current practice 🫶. It just means people often think the value of deploying it is lower than the cost 🎀. Still, the big deployment under some top-level domains (TLDs), and the near-universal deployment for the TLDs in the DNS root zone, prove that DNSSEC is doable for both ordinary and highly sophisticated domain owners 🌈✨.

1.2. Implementing DNSSEC 🦋

Developers of validating resolvers and authoritative servers, plus the operators running them, need to know the parts of the DNSSEC protocol that affect them 🧑‍💻. They should read the DNSSEC core docs and probably be at least familiar with the extensions 📖. Developers will probably need to be very familiar with the algorithm docs too 🔥.

Side note, bestie: some of the DNSSEC-related RFCs have significant errata, so when you read the RFCs, look up the related errata as well 🙈.

2. DNSSEC Core Documents 🌸

so "DNSSEC" as we use it is the third iteration of the DNSSEC spec 👑. [RFC2065] was the first, and [RFC2535] was the second 🧚. Earlier versions never got deployed at any real scale 💀. In this doc, "DNSSEC" means the protocol that was first defined in [RFC4033], [RFC4034], and [RFC4035] 💖.

The three original core docs each cover different stuff 📚:

  • [RFC4033] is an overview of DNSSEC, including how it might change the way DNS queries get resolved 🌈.
  • [RFC4034] specifies the DNS resource records used in DNSSEC. It obsoletes a lot of RFCs about earlier versions of DNSSEC 🗑️.
  • [RFC4035] covers the changes DNSSEC makes to the DNS protocol. That includes signing zones, serving signed zones, resolving with DNSSEC in mind, and authenticating DNSSEC-signed data 🔐.

When this set of core docs came out, you could build DNSSEC signing software, a DNSSEC-aware authoritative server, or a DNSSEC-aware recursive resolver using just those three core docs, plus a few older RFCs that specify the cryptography ✨. Those two older docs are:

  • [RFC2536] defines how to use the DSA signature algorithm, though it points to other docs for the details. DSA was thinly implemented and DNSSEC implementations can safely ignore it 🙈.
  • [RFC3110] defines how to use the RSA signature algorithm, though it also points to other docs for the details. RSA is still among the most popular signing algorithms for DNSSEC 💅.

Important to note, later RFCs update the core docs. For example, [RFC9077] changes how TTL values are calculated in DNSSEC processing 🎀.

2.1. Addition to the DNSSEC Core 💜

as with any major protocol, developers and operators found issues with the original core docs over the years 😭. [RFC6840] is an omnibus update to the original core docs, so it has basically become a core doc itself 👑. Besides covering new requirements from newer DNSSEC RFCs, it describes a lot of important security and interoperability issues that popped up while the initial specs were being deployed, especially after the DNS root got signed in 2010 🔥. It also lists some errors in the examples in the core specs 🙈.

[RFC6840] adds a few things to the core of DNSSEC. It makes NSEC3 [RFC5155] just as much a part of DNSSEC as NSEC is 🌈. It also makes the SHA-256 and SHA-512 hash functions defined in [RFC4509] and [RFC5702] part of the core 💖.

Part 1 is done, bestie! 🎀 Part 2 picks up with Section 3 next 🦋.

5. Additional Documents of Interest ✨

Okay so the docs above are the core of DNSSEC, the extra crypto algorithms, and the big extensions. 💖 If you're implementing or running DNSSEC, these extra reads are lowkey essential:

  • [RFC4470] explains how to build DNSSEC NSEC records that cover a smaller range of names than [RFC4034] asks for. Authoritative name servers can generate and sign these on demand, which stops anyone from walking the NSEC chain in a signed zone and seeing what's inside 🙈
  • [RFC6975] is giving validating end-system resolvers a way to tell a server which digital signature and hash algorithms they support 🔥
  • [RFC7129] is the background tea ☕ on the NSEC and NSEC3 mechanisms that DNSSEC uses for authenticated denial-of-existence responses. It's super important if you want to get how NSEC and NSEC3 are used in practice 🧚
  • [RFC7583] covers the timing issues when you roll a key in a DNSSEC-secured zone. Timing is everything, bestie ⏰
  • [RFC7646] defines Negative Trust Anchors (NTAs). These let you mitigate DNSSEC validation failures by turning off DNSSEC validation at specific domains 🫶
  • [RFC7958] describes the format and publication mechanisms IANA uses to distribute the DNSSEC trust anchors 🎀
  • [RFC8027] walks through the problems a validating DNS resolver, stub resolver, or application can run into when the infrastructure isn't compliant 💀
  • [RFC8145] describes two different ways validating resolvers can tell a server which keys are referenced in their chain of trust 🦋
  • [RFC8499] is the terminology glossary for talking about DNS. Sections 10 and 11 are the DNSSEC bits 📚
  • [RFC8509] gives end users and third parties a mechanism to figure out the trusted key state for the root key of the resolvers that handle their DNS queries 👑
  • [RFC8901] lays out deployment models for when each DNS provider signs zone data with its own keys, and it describes the key-management requirements for that setup 🌸
  • [RFC9276] gives guidance on setting NSEC3 parameters, based on recent real-world deployment experience 🌈

There will definitely be more DNSSEC RFCs published after this one. Stay tuned 💅

6. IANA Considerations

IANA already has three registry groups that relate to DNSSEC 🍓

The rules for the DNSSEC algorithm registry were set in the core RFCs, and then [RFC6014], [RFC6725], and [RFC9157] updated them 🫶

This document does not update or create any registry groups or registries. Nothing new in the registries from this one, so nothing to see here 🙈

7. Security Considerations

Okay, this part is serious, so listen up 😭🔥 All of the security considerations from all of the RFCs referenced in this document apply here. Every single one. You can't skip them just because this doc is the summary. Read the referenced RFCs' security sections like your DNSSEC deployment depends on it, because it does 💜

8. References

8.1. Normative References 📖

[RFC3110]  Eastlake 3rd, D., "RSA/SHA-1 SIGs and RSA KEYs in the
           Domain Name System (DNS)", RFC 3110, DOI 10.17487/RFC3110,
           May 2001, <https://www.rfc-editor.org/info/rfc3110>.

[RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
           Rose, "DNS Security Introduction and Requirements",
           RFC 4033, DOI 10.17487/RFC4033, March 2005,
           <https://www.rfc-editor.org/info/rfc4033>.

[RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
           Rose, "Resource Records for the DNS Security Extensions",
           RFC 4034, DOI 10.17487/RFC4034, March 2005,
           <https://www.rfc-editor.org/info/rfc4034>.

[RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
           Rose, "Protocol Modifications for the DNS Security
           Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
           <https://www.rfc-editor.org/info/rfc4035>.

[RFC4509]  Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer
           (DS) Resource Records (RRs)", RFC 4509,
           DOI 10.17487/RFC4509, May 2006,
           <https://www.rfc-editor.org/info/rfc4509>.

[RFC5155]  Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
           Security (DNSSEC) Hashed Authenticated Denial of
           Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008,
           <https://www.rfc-editor.org/info/rfc5155>.

[RFC5702]  Jansen, J., "Use of SHA-2 Algorithms with RSA in DNSKEY
           and RRSIG Resource Records for DNSSEC", RFC 5702,
           DOI 10.17487/RFC5702, October 2009,
           <https://www.rfc-editor.org/info/rfc5702>.

[RFC6840]  Weiler, S., Ed. and D. Blacka, Ed., "Clarifications and
           Implementation Notes for DNS Security (DNSSEC)", RFC 6840,
           DOI 10.17487/RFC6840, February 2013,
           <https://www.rfc-editor.org/info/rfc6840>.

8.2. Informative References 📚

okay bestie, these are the extra reads 🤓 they're informative, not normative, so they're the "go deeper if you're curious" pile 🧚

Acknowledgements 🫶

the DNS world owes a massive thank-you to everyone who wrote and contributed to the core DNSSEC documents and the notable DNSSEC extensions 💖

also, big shoutout to Ben Schwartz and Duane Wessels 🌸 they made significant contributions to the early draft versions of this document, so they're literally the reason it got off the ground ✨

Author's Address 🎀

Paul Hoffman
ICANN
Email: paul.hoffman@icann.org
📦 where this page comes from