RFC 3008

Title Block 🎀

Okay bestie, first the receipts. This is RFC 3008, titled "Domain Name System Security (DNSSEC) Signing Authority" 💅. It came from the Network Working Group, written by B. Wellington (that's Brian Wellington at Nominum 💜), dated November 2000. It's a Standards Track doc, and it updates RFC 2535 (more on that in Section 1 🫶). The title block doesn't list anything it obsoletes.

Status of this Memo ✨

This doc specifies an Internet standards track protocol for the Internet community, and it's literally asking for discussion and suggestions for improvements 🌸 For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🦋

Copyright Notice 🔥

Copyright (C) The Internet Society (2000). All Rights Reserved.

Abstract 🧚

This doc proposes a revised model of Domain Name System Security (DNSSEC) Signing Authority. The new model is meant to clear up earlier docs and add some extra restrictions so the secure resolution process is simpler. Specifically, it's about how keys get authorized to sign sets of records 👑

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119] 🎀

1. Introduction ✨

This doc defines extra restrictions on DNSSEC signatures (SIG) records, specifically about their authority to sign associated data 💖 The goal is a standard policy that a secure resolver follows, and local rules can add to it on top. This builds on [RFC2535] and updates section 2.3.6 of that doc 🦋

The biggest change is that in a secure zone, zone data is required to be signed by the zone key. Iconic 👑

You're expected to already know the DNS system [RFC1034, RFC1035] and the DNS security extensions [RFC2535], just so you know 🤓

2. The SIG Record 💅

A SIG record is normally tied to an RRset, and it "covers" (aka demonstrates the authenticity and integrity of) that RRset. This is called a "data SIG" 🌈 Heads up, there can be multiple SIG records covering one RRset, and the same validation process should be repeated for each of them 🧚 Some data SIGs are "material", meaning they matter to a DNSSEC capable resolver. Others are "immaterial" or "extra-DNSSEC", since they aren't relevant to DNSSEC validation. Immaterial SIGs may have application defined roles 🙈 SIG records can also exist without being bound to any RRset, and those count as immaterial too. The validation process is what figures out which SIGs are material. Once a SIG is shown to be immaterial, no other validation is necessary 💀

SIGs can also do transaction security. In that case, a SIG record with a type covered field of 0 gets attached to a message to protect its integrity. This is called a SIG(0) [RFC2535, RFC2931] 🫶

The following sections define requirements for all the fields of a SIG record. These requirements MUST be met for a DNSSEC capable resolver to process the signature. If any of them aren't met, the SIG can't be processed any further. Also, once a KEY has been identified as having generated this SIG, there are requirements it MUST meet too 😭

2.1. Type Covered 🍓

For a data SIG, the type covered MUST be the same as the type of data in the associated RRset. For a SIG(0), the type covered MUST be 0 💜

2.2. Algorithm Number 🌸

The algorithm specified in a SIG MUST be recognized by the client, and it MUST be an algorithm that has a defined SIG rdata format ✨

2.3. Labels 🦋

The labels count MUST be less than or equal to the number of labels in the SIG owner name, as specified in [RFC2535, section 4.1.3] 🎀

2.4. Original TTL 🧚

The original TTL MUST be greater than or equal to the TTL of the SIG record itself, since intermediate servers can't increase the TTL 🙈 This field can be ignored for SIG(0) records 💅

2.5. Signature Expiration and Inception 👑

The current time at the time of validation MUST lie within the validity period bounded by the inception and expiration times ⏰

2.6. Key Tag 🌈

There are no restrictions on the Key Tag field, although future algorithms might impose constraints. Plot twist, but it's fine 💖

2.7. Signer's Name 🔥

The signer's name field of a data SIG MUST contain the name of the zone that the data and signature belong to. The combination of signer's name, key tag, and algorithm MUST identify a zone key if the SIG is going to be considered material 🫶 The only exception: the signer's name field in a SIG KEY at a zone apex SHOULD contain the parent zone's name, unless the KEY set is self-signed 🦋 This doc defines a standard policy for DNSSEC validation, and local policy may override that standard policy 🌸

There are no restrictions on the signer field of a SIG(0) record. But the combination of signer's name, key tag, and algorithm MUST identify a key if this SIG(0) is going to be processed 💜

2.8. Signature 🍓

No restrictions on the signature field. It will be verified at some point, but it doesn't need to be examined before verification unless a future algorithm imposes constraints 😭

3. The Signing KEY Record 💅

Once a signature has been examined and its fields validated (but before the signature is verified), the resolver tries to find a KEY that matches the signer name, key tag, and algorithm fields in the SIG. If it can't find one, the SIG can't be verified and is considered immaterial. If KEYs are found, several fields of the KEY record MUST have specific values for the SIG to be considered material and authorized 🌈 If there are multiple KEYs, the following checks run on all of them, because there's no way to tell which one made the signature until verification happens 🧚

3.1. Type Flags ✨

The signing KEY record MUST have a flags value of 00 or 01 (authentication allowed, confidentiality optional) [RFC2535, 3.1.2] 🔥 A DNSSEC resolver MUST only trust signatures generated by keys that are permitted to authenticate data 🙌

3.2. Name Flags 🎀

The interpretation of this field is really different for data SIGs and SIG(0) records 🍓

3.2.1. Data SIG 👑

If the SIG record covers an RRset, the name type of the associated KEY MUST be 01 (zone) [RFC2535, 3.1.2]. This updates RFC 2535, section 2.3.6 💖 The DNSSEC validation process a resolver performs MUST ignore all keys that aren't zone keys, unless local policy dictates otherwise 🫶

The main reason RFC 2535 lets host and user keys generate material DNSSEC signatures is so dynamic update works without online zone keys, meaning you avoid storing private keys on an online server 🌸 But avoiding online signing keys can't actually be achieved, since they're needed to sign NXT and SOA sets [RFC3007] 😭 These online zone keys can sign any incoming data. Once you drop the goal of having no online keys, the reason to let host and user keys make material signatures goes away 🦋

Limiting material signatures to zone keys makes validation simpler 💅 The length of the verification chain is bounded by the name's label depth. A key's authority is clearly defined, so a resolver doesn't have to make a potentially complicated call about whether a key has the right authority to sign data ✨

Finally, letting host/user keys make material signatures gives no extra flexibility. As long as users and hosts can authenticate update requests to the primary zone server, signatures from zone keys are enough to protect the data's integrity for the whole world 🧚

3.2.2. SIG(0) 🌈

If the SIG record is a SIG(0) protecting a message, the name type of the associated KEY SHOULD be 00 (user) or 10 (host/entity). Transactions are started by a host or user, not a zone, so zone keys SHOULD not generate SIG(0) records 🙈

A client is either explicitly run by a user or on behalf of a host, so the name type of a SIG(0) generated by a client SHOULD be either user or host. A nameserver is associated with a host, and its use of SIG(0) isn't tied to a particular zone, so the name type of a SIG(0) generated by a nameserver SHOULD be host 💜

3.3. Signatory Flags 💅

This doc doesn't assign any values to the signatory field, and it doesn't require any values to be present 🦋

3.4. Protocol 🔥

The signing KEY record MUST have a protocol value of 3 (DNSSEC) or 255 (ALL). If a key isn't specified for use with DNSSEC, a DNSSEC resolver MUST NOT trust any signature that it generates 😭

3.5. Algorithm Number ✨

The algorithm field MUST be identical to that of the generated SIG record, and it MUST meet all requirements for an algorithm value in a SIG record 👑

---

Part 1 of 2 is done 🧚 Part 2 covers the rest of the doc: security, acknowledgements, references, and the author's address 🎀

8. Full Copyright Statement ✨

Copyright (C) The Internet Society (2000). All Rights Reserved. 🎀

Okay bestie, this is the legal bit, but it's important so pay attention 💅 Anyone can copy this document and share it with others. You can also make derivative works that comment on or explain it, or that help people implement it, and you can prepare, copy, publish, and distribute those, in whole or in part, with no restrictions of any kind. The one condition is that the copyright notice and this paragraph must be included on all of those copies and derivative works. 📝

However, this document itself can't be changed in any way. You can't remove the copyright notice, and you can't remove references to the Internet Society or other Internet organizations. There are two exceptions. The first is when it's needed for developing Internet standards, in which case the copyright procedures defined in the Internet Standards process must be followed. The second is when it's needed to translate it into languages other than English. 🌍

The limited permissions above are perpetual, and the Internet Society or its successors or assigns will never revoke them. 🦋

This document and the information in it is provided on an "AS IS" basis, and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. 💀

Acknowledgement

Funding for the RFC Editor function is currently provided by the Internet Society. 🫶🌸