RFC 4033

DNS Security Introduction and Requirements

📅 published March 2005, from ietf

DNS Security Introduction and Requirements 🎀

RFC 4033 💖 is giving Standards Track energy, and it's dated March 2005 🦋. It was written by R. Arends (Telematica Instituut), R. Austein (ISC), M. Larson (VeriSign), D. Massey (Colorado State University), and S. Rose (NIST) 👑. Bestie, it obsoletes RFC 2535, 3008, 3090, 3445, 3655, 3658, 3755, 3757, and 3845 💅. It also updates (but does not obsolete) RFC 1034, 1035, 2136, 2181, 2308, 3225, 3007, 3597, and the DNSSEC-related parts of 3226 ✨.

Status of This Memo 📜

okay so this document is a standards track protocol spec for the Internet community 🌸, and it's basically inviting everyone to talk about it and suggest improvements 🫶. If you want to know where this protocol stands in terms of standardization, check the current edition of the "Internet Official Protocol Standards" (STD 1) 🧚. And the memo can be distributed freely, no cap 💜.

Copyright (C) The Internet Society (2005) 🌈.

Abstract 🔥

ok so the Domain Name System Security Extensions (DNSSEC) add data origin authentication and data integrity to the DNS 🔐. This document introduces those extensions and spills the tea on what they can and can't do 💅. It also covers the stuff DNS security does and does not provide 🙈. Last but not least, it explains how all the DNSSEC documents connect to each other, which is lowkey the most important part 🍓.

Table of Contents 🗂️

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Definitions of Important DNSSEC Terms  . . . . . . . . . . .   3
   3.  Services Provided by DNS Security  . . . . . . . . . . . . .   7
       3.1.  Data Origin Authentication and Data Integrity  . . . .   7
       3.2.  Authenticating Name and Type Non-Existence . . . . . .   9
   4.  Services Not Provided by DNS Security  . . . . . . . . . . .   9
   5.  Scope of the DNSSEC Document Set and Last Hop Issues . . . .   9
   6.  Resolver Considerations  . . . . . . . . . . . . . . . . . .  10
   7.  Stub Resolver Considerations . . . . . . . . . . . . . . . .  11
   8.  Zone Considerations  . . . . . . . . . . . . . . . . . . . .  12
       8.1.  TTL Values vs. RRSIG Validity Period . . . . . . . . .  13
       8.2.  New Temporal Dependency Issues for Zones . . . . . . .  13
   9.  Name Server Considerations . . . . . . . . . . . . . . . . .  13
   10. DNS Security Document Family . . . . . . . . . . . . . . . .  14
   11. IANA Considerations  . . . . . . . . . . . . . . . . . . . .  15
   12. Security Considerations  . . . . . . . . . . . . . . . . . .  15
   13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . .  17
   14. References . . . . . . . . . . . . . . . . . . . . . . . . .  17
       14.1. Normative References . . . . . . . . . . . . . . . . .  17
       14.2. Informative References . . . . . . . . . . . . . . . .  18
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . .  20
   Full Copyright Statement . . . . . . . . . . . . . . . . . . . .  21

1. Introduction ✨

okay bestie, this doc introduces DNSSEC (the Domain Name System Security Extensions) 🎀. It and its two companion docs ([RFC4034] and [RFC4035]) update, clarify, and refine the security extensions from [RFC2535] and its predecessors 💖. These extensions bring in a set of new resource record types and tweaks to the existing DNS protocol ([RFC1035]) 🦋. The new records and protocol changes aren't fully explained in this doc, though. They're covered in a whole family of documents, which Section 10 lays out 🧚. Sections 3 and 4 go deeper on what the security extensions can and can't do 🔥. Section 5 talks about the scope of the document set 🍓. Sections 6, 7, 8, and 9 cover how these extensions affect resolvers, stub resolvers, zones, and name servers 👑.

This doc and its two companions obsolete [RFC2535], [RFC3008], [RFC3090], [RFC3445], [RFC3655], [RFC3658], [RFC3755], [RFC3757], and [RFC3845] 💅. The document set also updates, but does not obsolete, [RFC1034], [RFC1035], [RFC2136], [RFC2181], [RFC2308], [RFC3225], [RFC3007], [RFC3597], and the parts of [RFC3226] that deal with DNSSEC 🌈.

The DNS security extensions give you origin authentication and integrity protection for DNS data 🔐, plus a way to distribute public keys 🫶. Just know that they do not provide confidentiality 🙈💀.

2. Definitions of Important DNSSEC Terms ✨

okay bestie, this section is basically the glossary for the whole document set 📚🎀 the vibe is that you can skim it first, read the rest, then come back here whenever a word confuses you. no judgment, we've all been there 🫶

Authentication Chain: okay so this one is a chain of signed stuff where every link vouches for the next 🔗✨ you get an alternating run of DNSKEY RRsets and Delegation Signer (DS) RRsets. a DNSKEY RR checks the signature covering a DS RR, which means the DS RR can be authenticated. that DS RR holds a hash of another DNSKEY RR, and that new DNSKEY RR gets authenticated by matching the hash. the new one then authenticates another DNSKEY RRset, and some DNSKEY RR in that set can be used to authenticate yet another DS RR, and it just keeps going like that 💅 the chain ends at a DNSKEY RR whose private key signs the DNS data you actually wanted. for example, the root DNSKEY RRset can authenticate the DS RRset for example.. that DS RRset has a hash matching some example. DNSKEY, and that DNSKEY's private key signs the example. DNSKEY RRset. the private key counterparts of the example. DNSKEY RRset sign records like www.example. and DS RRs for delegations like subzone.example. iconic chain behavior 🌈

Authentication Key: a public key that a security-aware resolver has verified, so it can use the key to authenticate data 🔑 a security-aware resolver can get these keys in three ways. first, the resolver is usually configured to know about at least one public key. that configured data is either the public key itself or a hash of it as found in the DS RR (see "trust anchor") 🌸 second, the resolver can use an authenticated public key to verify a DS RR and the DNSKEY RR that the DS RR points to. third, the resolver might be able to tell that a new public key was signed by the private key of another public key the resolver already verified. ngl the big one to remember is that the resolver must always follow local policy when deciding whether to authenticate a new public key 👑 even if that local policy is just "authenticate any new public key whose signature I can verify" 💜

Authoritative RRset: okay this one is kind of a rule about who owns what 🏠 inside a particular zone, an RRset is "authoritative" if and only if its owner name sits inside the part of the name space that is at or below the zone apex and at or above the cuts separating the zone from its children (if it has any). every RRset at the zone apex is authoritative, EXCEPT certain RRsets at that domain name that, when present, belong to the zone's parent 🙈 those could include a DS RRset, the NSEC RRset that references this DS RRset (the "parental NSEC"), and RRSIG RRs tied to these RRsets, and all of them are authoritative in the parent zone. similarly, if the zone has any delegation points, only the parental NSEC RRset, DS RRsets, and any RRSIG RRs associated with those RRsets are authoritative for this zone 🫣

Delegation Point: the name on the parent's side of a zone cut 🪧 for example, the delegation point for foo.example would be the foo.example node in the "example" zone, NOT the zone apex of the "foo.example" zone. see also zone apex 🦋

Island of Security: a signed, delegated zone that doesn't have an authentication chain coming from its delegating parent 🏝️ that means there's no DS RR in the parent zone containing a hash of a DNSKEY RR for the island (see [RFC4034]). an island of security is served by security-aware name servers and can still provide authentication chains to any delegated child zones. the catch is that responses from an island of security (or its descendants) can only be authenticated if its authentication keys can be authenticated by some trusted means outside the DNS protocol 😭 so it's still valid, it just needs a little extra help 🫶

Key Signing Key (KSK): an authentication key that corresponds to a private key used to sign one or more other authentication keys for a given zone 🗝️ usually the private key of a key signing key signs a zone signing key, and that zone signing key has its own private key that signs the other zone data. local policy might say the zone signing key gets changed often, while the key signing key can have a longer validity period so it works as a more stable secure entry point into the zone ✨ designating a key as a key signing key is purely an operational issue. DNSSEC validation doesn't tell key signing keys apart from other DNSSEC authentication keys, and it's totally possible to use one single key as both a key signing key and a zone signing key 🤷‍♀️ key signing keys are discussed in more detail in [RFC3757]. also see zone signing key 💅

Non-Validating Security-Aware Stub Resolver: a security-aware stub resolver that trusts one or more security-aware recursive name servers to do most of the tasks discussed in this document set on its behalf 🙌 basically, it's an entity that sends DNS queries, receives DNS responses, and can set up an appropriately secured channel to a security-aware recursive name server, which then provides these services for it. see also security-aware stub resolver and validating security-aware stub resolver 💖

Non-Validating Stub Resolver: a less tedious term for a non-validating security-aware stub resolver 🙃 much better, right? 😭

Security-Aware Name Server: an entity acting as a name server (defined in section 2.4 of [RFC1034]) that understands the DNS security extensions defined in this document set 🛡️ specifically, it receives DNS queries and sends DNS responses, supports the EDNS0 ([RFC2671]) message size extension and the DO bit ([RFC3225]), and supports the RR types and message header bits defined in this document set 🎀

Security-Aware Recursive Name Server: an entity that acts as both a security-aware name server and a security-aware resolver 🧠 a more cumbersome but equivalent phrase would be "a security-aware name server that offers recursive service" 🙈

Security-Aware Resolver: an entity acting as a resolver (defined in section 2.4 of [RFC1034]) that understands the DNS security extensions defined in this document set 🔍 specifically, it sends DNS queries, receives DNS responses, supports the EDNS0 ([RFC2671]) message size extension and the DO bit ([RFC3225]), and is capable of using the RR types and message header bits defined in this document set to provide DNSSEC services 🌈

Security-Aware Stub Resolver: an entity acting as a stub resolver (defined in section 5.3.1 of [RFC1034]) that understands the DNS security extensions defined in this document set enough to offer extra services that a security-oblivious stub resolver just can't give 🧚 security-aware stub resolvers can be either "validating" or "non-validating" 🫧 it depends on whether the stub resolver checks DNSSEC signatures on its own, or trusts a friendly security-aware name server to do it for them 💜 see also validating stub resolver and non-validating stub resolver 🦋

Security-Oblivious <anything>: an <anything> that is not "security-aware" 🙈 basically, if it doesn't speak DNSSEC, it's security-oblivious 😌

Signed Zone: a zone whose RRsets are signed and that contains properly constructed DNSKEY, Resource Record Signature (RRSIG), Next Secure (NSEC), and (optionally) DS records 🖊️✨ the "properly constructed" part is doing a lot of work there, bestie 💅

Trust Anchor: a configured DNSKEY RR, or a DS RR hash of a DNSKEY RR 🪝 a validating security-aware resolver uses this public key or hash as its starting point for building the authentication chain up to a signed DNS response 🌟 in general, a validating resolver has to get the initial values of its trust anchors through some secure or trusted means outside the DNS protocol 🔐 having a trust anchor also means the resolver should expect the zone it points to be signed 🎀

Unsigned Zone: a zone that is not signed 🫥 that's it, that's the whole tea ☕

Validating Security-Aware Stub Resolver: a security-aware resolver that sends queries in recursive mode, BUT does its own signature validation instead of just blindly trusting an upstream security-aware recursive name server 🕵️‍♀️ see also security-aware stub resolver and non-validating security-aware stub resolver 🌸

Validating Stub Resolver: a less tedious term for a validating security-aware stub resolver 💖

Zone Apex: the name on the child's side of a zone cut 🏡 see also delegation point 🫶

Zone Signing Key (ZSK): an authentication key that corresponds to a private key used to sign a zone 🖋️ usually a zone signing key is part of the same DNSKEY RRset as the key signing key whose private key signs that DNSKEY RRset 🧩 the zone signing key is used for a slightly different purpose, though, and it can differ from the key signing key in other ways, like its validity lifetime ⏳ designating an authentication key as a zone signing key is purely an operational issue too. DNSSEC validation doesn't distinguish zone signing keys from other DNSSEC authentication keys, and it's possible to use a single key as both a key signing key and a zone signing key 🌈 see also key signing key 🍓

3. Services Provided by DNS Security 🛡️✨

okay so the Domain Name System (DNS) security extensions give you origin authentication and integrity assurance for DNS data 🎀 they also include mechanisms for authenticated denial of existence, which is a fancy way of proving a name doesn't exist, and that's honestly so iconic 😭 these mechanisms are described below 💅

these mechanisms need changes to the DNS protocol, so buckle up 🎢 DNSSEC adds four new resource record types: Resource Record Signature (RRSIG), DNS Public Key (DNSKEY), Delegation Signer (DS), and Next Secure (NSEC) 🍓 it also adds two new message header bits: Checking Disabled (CD) and Authenticated Data (AD) 🦋 because DNSSEC RRs make DNS messages bigger, DNSSEC also requires EDNS0 support ([RFC2671]) 🌸 and finally, DNSSEC requires support for the DNSSEC OK (DO) EDNS header bit ([RFC3225]) so that a security-aware resolver can say in its queries that it wants to receive DNSSEC RRs in the response messages 💜

these services protect against most of the threats to the Domain Name System described in [RFC3833] 🧚 but please, please check Section 12 for a discussion of the limitations of these extensions, because no protocol is perfect and it's giving honesty 🫶 ngl that's the part you do not skip 👑

3.1. Data Origin Authentication and Data Integrity 🎀

okay bestie, DNSSEC does authentication by attaching cryptographically generated digital signatures to DNS RRsets 🔐. Those signatures get stored in a brand new record type called the RRSIG record 💌. Usually one private key signs a zone's data, but multiple keys are possible too, like keys for a few different digital signature algorithms 🔑. If a security-aware resolver reliably learns a zone's public key, it can authenticate that zone's signed data ✅. The big DNSSEC concept here is that the key signing a zone's data is tied to the zone itself and not to the zone's authoritative name servers 👑.

ngl, transaction authentication keys can show up in zones too (see [RFC2931]), but DNSSEC is all about object security of DNS data, not channel security of DNS transactions 🙈. Those transaction-security keys might live in different RR types, so check [RFC3755] for the details.

A security-aware resolver can learn a zone's public key in one of two ways: a trust anchor configured into the resolver, or normal DNS resolution 🗝️. To make the second option work, public keys are stored in a new type of resource record, the DNSKEY RR. Quick reminder that the private keys used to sign zone data must be kept secure and should be stored offline when practical 🔒. To discover a public key reliably through DNS resolution, the target key itself has to be signed by either a configured authentication key or another key that has already been authenticated 🧐. Security-aware resolvers check zone info by building an authentication chain from a newly learned public key back to a previously known authentication public key, which either got configured into the resolver or was learned and verified earlier. So, the resolver must be configured with at least one trust anchor 🌱.

If the configured trust anchor is a zone signing key, it authenticates the associated zone. If the configured key is a key signing key, it authenticates a zone signing key 🔑✨. If the configured trust anchor is the hash of a key instead of the key itself, the resolver may have to grab the key with a DNS query. To help security-aware resolvers build this chain, security-aware name servers attempt to send the signature(s) needed to authenticate a zone's public key(s) in the DNS reply message, along with the public key itself, as long as there's space available in the message 📦.

The Delegation Signer (DS) RR type makes some of the admin stuff easier when signing delegations across organizational boundaries 🤝. The DS RRset lives at a delegation point in a parent zone and points to the public key(s) that match the private key(s) used to self-sign the DNSKEY RRset at the delegated child zone's apex 🫶. The child zone's admin then uses the private key(s) for one or more of the public keys in that DNSKEY RRset to sign the child zone's data. The typical authentication chain looks like this:

DNSKEY->[DS->DNSKEY]*->RRset

Here, "*" means zero or more DS->DNSKEY subchains 🧩. DNSSEC also allows more complex chains, like extra layers of DNSKEY RRs signing other DNSKEY RRs within a zone 🌈.

A security-aware resolver normally builds this chain from the root of the DNS hierarchy down to the leaf zones, starting from configured knowledge of the root's public key 🌳. Local policy, though, can let a security-aware resolver use one or more configured public keys (or hashes of public keys) other than the root public key 🗺️. It might also not have configured knowledge of the root public key at all, or it might block particular public keys for arbitrary reasons, even when those keys are properly signed with verifiable signatures 🚧. DNSSEC gives mechanisms for a security-aware resolver to figure out whether an RRset's signature is "valid" within the meaning of DNSSEC 🔍. In the end, though, authenticating both DNS keys and data is a matter of local policy, which can extend or even override the protocol extensions defined in this document set 💅. See Section 5 for further discussion 📖.

3.2. Authenticating Name and Type Non-Existence 🙈

The security mechanism from Section 3.1 only signs existing RRsets in a zone, so it doesn't cover the "nothing's here" case 🫠. Giving negative responses the same level of authentication and integrity requires another new resource record type, the NSEC record 🆕. The NSEC record lets a security-aware resolver authenticate a negative reply, whether for name or type non-existence, using the same mechanisms used to authenticate other DNS replies 🔐. NSEC records need a canonical representation and ordering for domain names in zones 📚. Chains of NSEC records explicitly describe the gaps, or "empty space", between domain names in a zone, and they list the types of RRsets present at existing names 🕳️. Each NSEC record is signed and authenticated using the mechanisms described in Section 3.1 ✨.

4. Services Not Provided by DNS Security 🚫

DNS was originally designed on the assumptions that it returns the same answer to any given query no matter who issued the query, and that all data in the DNS is therefore visible 👀. Because of that, DNSSEC isn't designed to provide confidentiality, access control lists, or other ways of telling inquirers apart 🙅‍♀️.

DNSSEC provides no protection against denial of service attacks 💀. Security-aware resolvers and security-aware name servers are vulnerable to an extra class of denial of service attacks based on cryptographic operations 😭. Please see Section 12 for details 📖.

The DNS security extensions give data and origin authentication for DNS data 🛡️. The mechanisms above aren't designed to protect operations like zone transfers and dynamic update ([RFC2136], [RFC3007]) 🚚. The message authentication schemes described in [RFC2845] and [RFC2931] cover the security operations that pertain to those transactions 🔏.

5. Scope of the DNSSEC Document Set and Last Hop Issues 🌍

The specification in this document set defines the behavior for zone signers and security-aware name servers and resolvers, so that validating entities can unambiguously determine the state of the data 🧠✨.

A validating resolver can determine the following 4 states 🚦:

  • Secure: The validating resolver has a trust anchor, has a chain of trust, and is able to verify all the signatures in the response 💖.
  • Insecure: The validating resolver has a trust anchor, a chain of trust, and, at some delegation point, signed proof of the non-existence of a DS record. This indicates that subsequent branches in the tree are provably insecure 🫥. A validating resolver may have a local policy to mark parts of the domain space as insecure 🏷️.
  • Bogus: The validating resolver has a trust anchor and a secure delegation indicating that subsidiary data is signed, but the response fails to validate for some reason: missing signatures, expired signatures, signatures with unsupported algorithms, data missing that the relevant NSEC RR says should be present, and so forth 🚨.
  • Indeterminate: There is no trust anchor that would indicate that a specific portion of the tree is secure. This is the default operation mode 🌫️.

This specification only defines how security-aware name servers can signal non-validating stub resolvers that data was found to be bogus (using RCODE=2, "Server Failure"; see [RFC4035]) 🙅.

There's a mechanism for security-aware name servers to signal security-aware stub resolvers that data was found to be secure, using the AD bit (see [RFC4035]) 🎉.

This specification doesn't define a format for communicating why responses were found to be bogus or marked as insecure 🤷‍♀️. The current signaling mechanism also doesn't distinguish between the indeterminate and insecure states 😵‍💫.

A method for signaling advanced error codes and policy between a security-aware stub resolver and security-aware recursive nameservers is a topic for future work, and so is the interface between a security-aware resolver and the applications that use it 🔭. Still, the lack of a specification for such communication doesn't prohibit deploying signed zones, or deploying security-aware recursive name servers that prohibit propagation of bogus data to the applications 🙌.

6. Resolver Considerations 🧠💅

A security-aware resolver has to be able to perform the cryptographic functions needed to verify digital signatures, using at least the mandatory-to-implement algorithm(s) 🔐. Security-aware resolvers must also be capable of forming an authentication chain from a newly learned zone back to an authentication key, as described above 🔗. This process might need extra queries to intermediate DNS zones to get the necessary DNSKEY, DS, and RRSIG records 🔍. A security-aware resolver should be configured with at least one trust anchor as the starting point for establishing authentication chains 🌱.

If a security-aware resolver is separated from the relevant authoritative name servers by a recursive name server, or by any sort of intermediary device that acts as a DNS proxy, and that recursive name server or intermediary device is not security-aware, the security-aware resolver may not be able to operate in a secure mode 🙃. For example, if a security-aware resolver's packets get routed through a network address translation (NAT) device that includes a DNS proxy which isn't security-aware, the resolver may find it difficult or impossible to obtain or validate signed DNS data 😩. It may have an especially rough time getting DS RRs in that situation, because DS RRs don't follow the usual DNS rules for ownership of RRs at zone cuts 🧱. Note that this problem isn't specific to NATs: any security-oblivious DNS software of any kind sitting between the security-aware resolver and the authoritative name servers will interfere with DNSSEC 🚫.

If a security-aware resolver has to rely on an unsigned zone or on a name server that isn't security aware, the resolver may not be able to validate DNS responses, and it will need a local policy on whether to accept unverified responses ⚖️.

A security-aware resolver should take a signature's validation period into account when deciding the TTL of data in its cache, so it doesn't cache signed data beyond the signature's validity period ⏳. It should also allow for the possibility that its own clock is wrong 🕰️. So a security-aware resolver that's part of a security-aware recursive name server has to pay careful attention to the DNSSEC "checking disabled" (CD) bit ([RFC4034]) 👀. The point is to avoid blocking valid signatures from getting through to other security-aware resolvers that are clients of this recursive name server 🫶. See [RFC4035] for how a secure recursive server handles queries with the CD bit set 📚.

7. Stub Resolver Considerations ✨

Okay so, the protocol doesn't strictly require it, but most DNS queries actually come from stub resolvers 🫶. By definition, stub resolvers are minimal DNS resolvers that use recursive query mode to offload most of the DNS resolution work to a recursive name server. Since stub resolvers are everywhere, the DNSSEC architecture has to take them into account 🌸. The security features a stub resolver needs do differ in some ways from what a security-aware iterative resolver needs, though.

Even a security-oblivious stub resolver can get some benefit from DNSSEC if the recursive name servers it uses are security-aware 🦋. But for the stub resolver to place any real reliance on DNSSEC services, it must trust both the recursive name servers in question and the communication channels between itself and those name servers. The first one is a local policy issue. Basically, a security-oblivious stub resolver has no choice but to put itself at the mercy of the recursive name servers it uses, because it doesn't do DNSSEC validity checks on its own 💀. The second one needs some kind of channel security mechanism. Proper use of DNS transaction authentication mechanisms like SIG(0) ([RFC2931]) or TSIG ([RFC2845]) would do the job, and so would appropriate use of IPsec 🔐. Particular implementations might have other options too, like operating system specific interprocess communication mechanisms. Confidentiality isn't needed for this channel, but data integrity and message authentication are 🙈.

A security-aware stub resolver that trusts both its recursive name servers and its channel to them may choose to look at the Authenticated Data (AD) bit in the message header of the response messages it receives 👀. It can use this flag bit as a hint to find out whether the recursive name server was able to validate signatures for all of the data in the Answer and Authority sections of the response ✨.

There's one more step a security-aware stub resolver can take if, for whatever reason, it can't establish a useful trust relationship with the recursive name servers it uses: it can do its own signature validation by setting the Checking Disabled (CD) bit in its query messages 🛡️. A validating stub resolver is thus able to treat the DNSSEC signatures as trust relationships between the zone administrators and the stub resolver itself 👑.

8. Zone Considerations 🎀

Signed and unsigned zones are different in several ways. A signed zone contains additional security-related records (RRSIG, DNSKEY, DS, and NSEC records) 🍓. RRSIG and NSEC records may be generated by a signing process before the zone gets served. The RRSIG records that come with zone data have defined inception and expiration times, and those set a validity period for the signatures and the zone data the signatures cover ⏳.

8.1. TTL Values vs. RRSIG Validity Period ⏰

It's important to note the difference between an RRset's TTL value and the signature validity period specified by the RRSIG RR covering that RRset 🧐. DNSSEC doesn't change the definition or function of the TTL value, which is meant to keep database coherency in caches. A caching resolver purges RRsets from its cache no later than the end of the time period specified by the TTL fields of those RRsets, whether or not the resolver is security-aware 🧹.

The inception and expiration fields in the RRSIG RR ([RFC4034]), on the other hand, specify the time period during which the signature can be used to validate the covered RRset ✨. The signatures tied to signed zone data are only valid for the time period set by those fields in the RRSIG RRs in question. TTL values can't extend the validity period of signed RRsets in a resolver's cache 🚫. However, the resolver may use the time remaining before the signature validity period expires as an upper bound for the TTL of the signed RRset and its associated RRSIG RR in the resolver's cache 🧠.

8.2. New Temporal Dependency Issues for Zones ⌛

Information in a signed zone has a temporal dependency that didn't exist in the original DNS protocol 🥺. A signed zone needs regular maintenance to make sure each RRset in the zone has a current valid RRSIG RR. The signature validity period of an RRSIG RR is an interval during which the signature for one particular signed RRset can be considered valid, and the signatures of different RRsets in a zone may expire at different times 📅. Re-signing one or more RRsets in a zone will change one or more RRSIG RRs, which will in turn require incrementing the zone's SOA serial number to indicate that a zone change has occurred, and re-signing the SOA RRset itself 📝. So re-signing any RRset in a zone may also trigger DNS NOTIFY messages and zone transfer operations 📣.

9. Name Server Considerations 🏰

A security-aware name server should include the appropriate DNSSEC records (RRSIG, DNSKEY, DS, and NSEC) in all responses to queries from resolvers that have signaled their willingness to receive such records via use of the DO bit in the EDNS header, subject to message size limitations 📦. Because including these DNSSEC RRs could easily cause UDP message truncation and fallback to TCP, a security-aware name server must also support the EDNS "sender's UDP payload" mechanism 🧩.

If possible, the private half of each DNSSEC key pair should be kept offline 🔒. But this won't be possible for a zone where DNS dynamic update has been enabled. In the dynamic update case, the primary master server for the zone will have to re-sign the zone when it's updated, so the private key corresponding to the zone signing key will have to be kept online 🌐. This is an example of a situation where splitting the zone's DNSKEY RRset into zone signing key(s) and key signing key(s) may be useful, since the key signing key(s) in that case can still be kept offline and may have a longer useful lifetime than the zone signing key(s) 🗝️.

By itself, DNSSEC is NOT enough to protect the integrity of an entire zone during zone transfer operations 😱. Even a signed zone contains some unsigned, nonauthoritative data if the zone has any children, so zone maintenance operations will require some additional mechanisms (most likely some form of channel security, such as TSIG, SIG(0), or IPsec) 🛠️.

10. DNS Security Document Family 📚

The DNSSEC document set can be partitioned into several main groups, under the larger umbrella of the DNS base protocol documents 🗂️.

The "DNSSEC protocol document set" refers to the three documents that form the core of the DNS security extensions:

  1. DNS Security Introduction and Requirements (this document)
  2. Resource Records for DNS Security Extensions [RFC4034]
  3. Protocol Modifications for the DNS Security Extensions [RFC4035]

Additionally, any document that would add to or change the core DNS Security extensions would fall into this category 💫. This includes any future work on the communication between security-aware stub resolvers and upstream security-aware recursive name servers.

The "Digital Signature Algorithm Specification" document set refers to the group of documents that describe how specific digital signature algorithms should be implemented to fit the DNSSEC resource record format 🖊️. Each document in this set deals with a specific digital signature algorithm. Please see the appendix on "DNSSEC Algorithm and Digest Types" in [RFC4034] for a list of the algorithms that were defined when this core specification was written 📖.

The "Transaction Authentication Protocol" document set refers to the group of documents that deal with DNS message authentication, including secret key establishment and verification 🔑. It's not strictly part of the DNSSEC specification as defined in this set of documents, but this group is noted because of its relationship to DNSSEC 🤝.

The final document set, "New Security Uses", refers to documents that seek to use proposed DNS Security extensions for other security related purposes 🌈. DNSSEC does not provide any direct security for these new uses, but it may be used to support them. Documents that fall in this category include those describing the use of DNS in the storage and distribution of certificates ([RFC2538]) 📜.

11. IANA Considerations 🧾

This overview document introduces no new IANA considerations. Please see [RFC4034] for a complete review of the IANA considerations introduced by DNSSEC 💖.

12. Security Considerations 🔐✨

okay bestie, this is the section where we get real 🥺 this doc adds the DNS security extensions and describes the set of docs with the new security records and DNS protocol tweaks. The extensions give you data origin authentication and data integrity by slapping digital signatures on resource record sets. This section is about the limits, so read it all 🫶

For a security-aware resolver to validate a DNS response, all zones along the path from the trusted starting point to the zone containing the response zones must be signed, and all name servers and resolvers involved in the resolution process must be security-aware, as defined in this document set. A security-aware resolver can't verify responses from an unsigned zone, from a zone not served by a security-aware name server, or for any DNS data it can only get through a recursive name server that isn't security-aware 💀 And if there's a break in the authentication chain so the resolver can't get and validate the authentication keys it needs, then it can't validate the affected DNS data either. Not it 😭

This document briefly talks about other ways to add security to a DNS query, like using a channel secured by IPsec, or a DNS transaction authentication mechanism such as TSIG ([RFC2845]) or SIG(0) ([RFC2931]). But transaction security is not part of DNSSEC per se, so don't mix them up 💅

A non-validating security-aware stub resolver, by definition, does not do DNSSEC signature validation on its own 🙈 So it's vulnerable both to attacks on (and by) the security-aware recursive name servers that do the checks for it, and to attacks on its communication with those recursive name servers. Non-validating security-aware stub resolvers should use some form of channel security to defend against that second threat. The only known defense against the first threat is for the security-aware stub resolver to do its own signature validation, and at that point, again by definition, it would no longer be a non-validating security-aware stub resolver. Plot twist 🌀

DNSSEC does not protect against denial of service attacks. 🚨

Ngl this part is a lot. DNSSEC makes DNS vulnerable to a brand new class of denial of service attacks based on cryptographic operations against security-aware resolvers and security-aware name servers, because an attacker can try to use DNSSEC mechanisms to eat up a victim's resources 😤 This class of attacks takes at least two forms. An attacker may be able to consume resources in a security-aware resolver's signature validation code by tampering with RRSIG RRs in response messages, or by building needlessly complex signature chains. An attacker may also be able to consume resources in a security-aware name server that supports DNS dynamic update, by sending a stream of update messages that force the name server to re-sign some RRsets in the zone more often than would otherwise be necessary. Absolutely unhinged, and I'm obsessed 💀

Due to a deliberate design choice, DNSSEC does not provide confidentiality 🙃 It's about authenticity and integrity, not keeping things secret.

DNSSEC also lets a hostile party enumerate all the names in a zone by following the NSEC chain 👀 NSEC RRs assert which names do not exist in a zone by linking from one existing name to the next existing name along a canonical ordering of all the names in the zone. So an attacker can query these NSEC RRs in sequence and collect every name in the zone. Technically this isn't an attack on the DNS itself, but it could let an attacker map network hosts or other resources just by listing what's in a zone 🗺️

DNSSEC adds a lot of complexity to the DNS, which means lots of new chances for implementation bugs and misconfigured zones 🫠 In particular, turning on DNSSEC signature validation in a resolver may make entire legitimate zones effectively unreachable because of DNSSEC configuration errors or bugs. Yikes, the vibes are chaotic.

DNSSEC does not protect against tampering with unsigned zone data 🥀 Non-authoritative data at zone cuts (glue and NS RRs in the parent zone) is not signed. That's not a problem when validating the authentication chain, but it does mean the non-authoritative data itself can be tampered with during zone transfer operations. So while DNSSEC can provide data origin authentication and data integrity for RRsets, it can't do that for zones, and other mechanisms (such as TSIG, SIG(0), or IPsec) must be used to protect zone transfer operations 🔒

Please see [RFC4034] and [RFC4035] for additional security considerations 📖

13. Acknowledgements 🫶🌸

This document was created from the input and ideas of the members of the DNS Extensions Working Group 💜 Explicitly listing everyone who contributed during the decade DNSSEC was under development would be impossible, so the editors especially want to thank the following people for their contributions to and comments on this document set: Jaap Akkerhuis, Mark Andrews, Derek Atkins, Roy Badami, Alan Barrett, Dan Bernstein, David Blacka, Len Budney, Randy Bush, Francis Dupont, Donald Eastlake, Robert Elz, Miek Gieben, Michael Graff, Olafur Gudmundsson, Gilles Guette, Andreas Gustafsson, Jun-ichiro Itojun Hagino, Phillip Hallam-Baker, Bob Halley, Ted Hardie, Walter Howard, Greg Hudson, Christian Huitema, Johan Ihren, Stephen Jacob, Jelte Jansen, Simon Josefsson, Andris Kalnozols, Peter Koch, Olaf Kolkman, Mark Kosters, Suresh Krishnaswamy, Ben Laurie, David Lawrence, Ted Lemon, Ed Lewis, Ted Lindgreen, Josh Littlefield, Rip Loomis, Bill Manning, Russ Mundy, Thomas Narten, Mans Nilsson, Masataka Ohta, Mike Patton, Rob Payne, Jim Reid, Michael Richardson, Erik Rozendaal, Marcos Sanz, Pekka Savola, Jakob Schlyter, Mike StJohns, Paul Vixie, Sam Weiler, Brian Wellington, and Suzanne Woolf 🌈

No doubt the above list is incomplete. The editors apologize to anyone they left out 🥹

14. References 📚✨

14.1. Normative References

[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.

[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.

[RFC2535] Eastlake 3rd, D., "Domain Name System Security Extensions", RFC 2535, March 1999.

[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, August 1999.

[RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC 3225, December 2001.

[RFC3226] Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver message size requirements", RFC 3226, December 2001.

[RFC3445] Massey, D. and S. Rose, "Limiting the Scope of the KEY Resource Record (RR)", RFC 3445, December 2002.

[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for DNS Security Extensions", RFC 4034, March 2005.

[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005.

14.2. Informative References

[RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997.

[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997.

[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC 2308, March 1998.

[RFC2538] Eastlake 3rd, D. and O. Gudmundsson, "Storing Certificates in the Domain Name System (DNS)", RFC 2538, March 1999.

[RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845, May 2000.

[RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures ( SIG(0)s )", RFC 2931, September 2000.

[RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, November 2000.

[RFC3008] Wellington, B., "Domain Name System Security (DNSSEC) Signing Authority", RFC 3008, November 2000.

[RFC3090] Lewis, E., "DNS Security Extension Clarification on Zone Status", RFC 3090, March 2001.

[RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record (RR) Types", RFC 3597, September 2003.

[RFC3655] Wellington, B. and O. Gudmundsson, "Redefinition of DNS Authenticated Data (AD) bit", RFC 3655, November 2003.

[RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record (RR)", RFC 3658, December 2003.

[RFC3755] Weiler, S., "Legacy Resolver Compatibility for Delegation Signer (DS)", RFC 3755, May 2004.

[RFC3757] Kolkman, O., Schlyter, J., and E. Lewis, "Domain Name System KEY (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag", RFC 3757, April 2004.

[RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name System (DNS)", RFC 3833, August 2004.

[RFC3845] Schlyter, J., "DNS Security (DNSSEC) NextSECure (NSEC) RDATA Format", RFC 3845, August 2004.

Authors' Addresses 🖊️🦋

Roy Arends
Telematica Instituut
Brouwerijstraat 1
7523 XC  Enschede
NL

EMail: roy.arends@telin.nl


Rob Austein
Internet Systems Consortium
950 Charter Street
Redwood City, CA  94063
USA

EMail: sra@isc.org


Matt Larson
VeriSign, Inc.
21345 Ridgetop Circle
Dulles, VA  20166-6503
USA

EMail: mlarson@verisign.com


Dan Massey
Colorado State University
Department of Computer Science
Fort Collins, CO 80523-1873

EMail: massey@cs.colostate.edu


Scott Rose
National Institute for Standards and Technology
100 Bureau Drive
Gaithersburg, MD  20899-8920
USA

EMail: scott.rose@nist.gov

Copyright (C) The Internet Society (2005).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property ⚖️

okay bestie, this part is the legal fine print, but it's still the IETF being precise, so we keep every bit 💅. The IETF takes no position on whether any Intellectual Property Rights or other rights someone might claim over the tech in this document are valid, or how far they reach. It also can't or won't say whether a license for those rights is available, and it hasn't done its own digging to find any such rights 🕵️‍♀️. If you want the rules for rights in RFC documents, check out BCP 78 and BCP 79 📚.

Copies of IPR disclosures sent to the IETF Secretariat, plus any promises of licenses, and the results of anyone trying to get a general license or permission to use proprietary rights for this spec, can be found in the IETF online IPR repository at http://www.ietf.org/ipr 🔗. Implementers and users can look there 👀.

The IETF also invites anyone who knows about copyrights, patents, patent applications, or other proprietary rights that might cover tech needed to implement this standard to tell them 📣. Send that info to ietf-ipr@ietf.org 💌. no cap, it's giving transparency ✨.

Acknowledgement 🫶

The RFC Editor function is currently funded by the Internet Society 🌈. Thank you to the Internet Society, the people keeping the lights on behind the scenes, obsessed 💖.

📦 where this page comes from