RFC 3090

Network Working Group, Request for Comments: 3090. Hi bestie, this is RFC 3090, the one that cleans up what it means for a DNS zone to be "secured" ✨

Title: DNS Security Extension Clarification on Zone Status 🎀

Author: E. Lewis, NAI Labs 💜

Category: Standards Track 🔥

Date: March 2001 🌸

Updates: RFC 2535 🦋 (it clarifies and updates some sections of that one, so go read it too)

---

Status of This Memo

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

Copyright Notice

Copyright (C) The Internet Society (2001). All Rights Reserved. ©️✨

Abstract

okay so this doc defines what a secured zone is 💖 It clarifies and updates some parts of RFC 2535. RFC 2535 decided whether a zone was secured on a per-algorithm basis. So a zone could be secured with RSA keys but not secured with DSA keys 🙃 This doc says nope, a zone is either secured or not secured, no matter which key algorithm is used (or not used at all). To make the status easier to figure out, the "experimentally secure" status is deprecated 💅

1. Introduction 🧚

So, is a DNS zone "secured" or not? That question pops up in at least four different situations 👀 A zone administrator asks it when setting up a zone to use DNSSEC. A dynamic update server asks it when an update request shows up, since that might need DNSSEC processing. A delegating zone asks it of a child zone when the parent enters data saying what the child's status is. And a resolver asks it when it gets data that belongs to the zone 🫶

1.1. When a Zone's Status is Important

A zone administrator needs to figure out what steps to take to make the zone as secure as it can possibly be 💪 Here's the thing: DNS is distributed and run by lots of different people, so any single zone is at the mercy of other zones when it comes to how secure it looks 😭 This document defines what makes a zone qualify as secure ✨

A name server doing dynamic updates needs to know whether a zone being updated is supposed to get signatures added to the updated data, get NXT records applied, and go through any other required processing. The name server could be configured with that knowledge, but honestly, being able to work out a zone's status from the data itself is a much better option than relying on configuration parameters 🙌

A delegating zone is required to say whether a child zone is secured. Why? It comes down to how a resolver decides things about a zone (more on that in the next paragraph) 🍓 To make a long story short, a parent needs to know whether a child should be considered secured. That's really a two-part question. First, under what circumstances does a parent consider a child zone to be secure? Second, how does a parent know if the child actually conforms? 🤔

A resolver needs to know whether a zone is secured while it's processing data from that zone. Ultimately, the resolver needs to know whether or not to expect a usable signature covering the data 🔐 How it figures that out is out of scope for this document, except that in some cases the resolver will need to contact the zone's parent to see if the parent states that the child is secured 📞

1.2. Islands of Security

The goal of DNSSEC is to have every zone secured, from the root zone and the top-level domains all the way down to the leaf zones 🌳 Going from the unsecured DNS we have now to a fully secured tree (or "as much as will be secured") is gonna take some time ⏳ In the meantime, DNSSEC will show up in various spots in the tree, not necessarily "top down" 🎢

For example, at a particular moment, the root zone and the "test." TLD might be secured, but region1.test. might not be. (For reference, let's assume region2.test. is secured.) However, subarea1.region1.test. may have gone through the process of becoming secured, along with its delegations. The dilemma is that subarea1 can't get its zone keys properly signed, because its parent zone, region1, isn't secured 😩

The colloquial phrase for the collection of contiguous secured zones at or below subarea1.region1.test. is an "island of security" 🏝️ The only way a DNSSEC resolver will trust any data from this island is if the resolver is pre-configured with the zone key(s) for subarea1.region1.test., which is the root of the island of security. Other resolvers (the ones not configured that way) will recognize this island as unsecured 🙈

An island of security begins with one zone whose public key is pre-configured in resolvers. Inside the island, the subzones are also secured. The "bottom" of the island is defined by delegations to unsecured zones. One island may also sit on top of another, meaning there's at least one unsecured zone between the bottom of the upper island and the root of the lower secured island 🧱

Even though both subarea1.region1.test. and region2.test. have been properly brought to a secured state by the administering staff, only the latter is actually "globally" secured. That means all DNSSEC resolvers can and will verify its data 🌍 The former, subarea1, will only be seen as secured by a subset of resolvers, the ones that are appropriately configured. This document refers to zones like that as being "locally" secured 🫧

RFC 2535 has a provision for "certification authorities," which are entities that sign public keys for zones such as subarea1 👑 There's another document, [RFC3008], that restricts this activity. Regardless of that other document, resolvers would still need proper configuration to use the certification authority to verify the data for the subarea1 island 🔑

1.2.1. Determining the closest security root

Given a domain, the first step to figuring out whether it's secure is determining the closest security root 🧭 The closest security root is the top of an island of security whose name has the most matching right-most labels (counting in order from the root) with the given domain 💅

Let's say we have a name "sub.domain.testing.signed.exp.test.", and the secure roots "exp.test.", "testing.signed.exp.test." and "not-the-same.xy.". The middle one is the closest! The first secure root shares 2 labels, the middle one shares 4, and the last one shares 0 🎯

The reason we want the closest one is to avoid false senses of insecurity caused by a NULL key 🫠 Continuing the example, both "testing..." and "exp.test." are listed as secure roots because "signed.exp.test." is unsecured (it has a NULL key). If we started descending from "exp.test." toward our domain (sub...), we'd hit that NULL key and wrongly conclude that sub... is unsigned. But if we descend from "testing..." and find keys for "domain....", then we can conclude that "sub..." is secured 🎉

Heads up, this example assumes one-label-deep zones and assumes we don't configure overlapping islands of security. To be clear, the definition should exclude "short.xy.test." from being the closest security root for "short.xy." even though 2 labels match 🙅‍♀️

Overlapping islands of security don't introduce any conceptually interesting ideas, and they don't impact the protocol in any way 🤷‍♀️ That said, protocol implementers are advised to make sure their code doesn't get thrown for a loop by overlaps. Overlaps are sure to be configuration problems as islands of security grow to cover bigger regions of the name space 🌀

1.3. Parent Statement of Child Security

In 1.1 of this document, there's the comment "the parent states that the child is secured." This has caused quite a bit of confusion 😵‍💫

The need for the parent to "state" a child's status comes from this observation. If you want to see whether an answer is secured (meaning it comes from an "island of security" and is properly signed), you have to begin at the appropriate root of that island 🏝️

To find the answer you're inspecting, you may have to descend through zones inside the island. Starting from the trusted root of the island, you descend into the next zone down. Since you trust the upper zone, you need to get data from it about the next zone down. Otherwise there's a vulnerable point where a zone can be hijacked 🚨 If you ever reach a point where you go from a secured zone to an unsecured zone, you've left the island of security, and you should conclude that the answer is unsecured 🙅

However, in RFC 2535, section 2.3.4, these words seem to clash with the need for the parent to "state" something about a child:

   There MUST be a zone KEY RR, signed by its superzone, for every
   subzone if the superzone is secure.  This will normally appear in
   the subzone and may also be included in the superzone.  But, in
   the case of an unsecured subzone which can not or will not be
   modified to add any security RRs, a KEY declaring the subzone to
   be unsecured MUST appear with the superzone signature in the
   superzone, if the superzone is secure.

The confusion is this: in RFC 2535, a secured parent states that a child is secured by SAYING NOTHING ("may also be" as opposed to "MUST also be") 🤯 That's counterintuitive, because it means the absence of data is what signals "secured." This idea has been fine in theory, but it has made some people in operations uncomfortable 😬 Still, using silence to state something does work in this case, so there hasn't been enough demonstrated need to change the definition 🫶

1.4. Impact on RFC 2535

This document updates sections of RFC 2535 💫 The definition of a secured zone is an update to section 3.4 of that RFC. Section 3.4 is also updated to get rid of the definition of experimental keys, and it shows a way to still achieve the functionality those keys were designed to provide ✨ Section 3.1.3 is updated by specifying the value of the protocol octet in a zone key 🔢

1.5. "MUST" and other key words

The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY" in this document are to be interpreted as described in [RFC 2119] 📖 Right now, only "MUST" is actually used in this document 💜

2 Status of a Zone ✨

okay so this section is where we get the rules for how secure a zone is, and there are three levels: global, local, and unsecured 💅. A zone is globally secure when it follows the strictest set of DNSSEC processing rules 👑. It's locally secured when it's set up so that only resolvers that are configured for it see it as secured 🔐. Everything else is unsecured 🌸.

Note: there's no single document that fully defines the DNSSEC verification rules yet 🙈. For this doc, the strictest rules are assumed to say that the chain of zone keys follows the delegation tree all the way up to the root zone. (See 2.b below.) This doesn't ban alternate verification paths, it just sets a baseline definition ✨.

To avoid repeating ourselves in the rules below, here are some terms we're defining 🎀.

2.a Zone signing KEY RR - A KEY RR whose flag field has the value 01 for name type (indicating a zone key) and either value 00 or value 01 for key type (indicating a key permitted to authenticate data). (See RFC 2535, section 3.1.2). The KEY RR also has a protocol octet value of DNSSEC (3) or ALL (255). 🦋

This definition updates RFC 2535's definition of a zone key. Requiring the protocol field to be either DNSSEC or ALL is a new requirement (a change to section 3.1.3.) 💜

2.b On-tree Validation - The authorization model where only the parent zone is recognized to supply a DNSSEC-meaningful signature that a resolver uses to build a chain of trust from the child's keys up to a recognized root of security 🌳. "On-tree" means following the DNS domain hierarchy (upwards) to reach a trusted key, presumably the root key if no other key is available ⬆️. "Validation" means the parent's digital signature proving the integrity, authentication and authorization of the child's key to sign the child's zone data 🔏.

2.c Off-tree Validation - Any authorization model that lets domain names other than the parent's provide a signature over a child's zone keys, so a resolver can trust those keys 🌈.

2.1 Globally Secured

a globally secured zone, in a nutshell, is a zone that uses only mandatory to implement algorithms (RFC 2535, section 3.2) and relies on a key certification chain that parallels the delegation tree (on-tree validation) 🍓. These are the rules for globally secured zones 👇.

2.1.a. The zone's apex MUST have a KEY RR set. There MUST be at least one zone signing KEY RR (2.a) of a mandatory to implement algorithm in the set. 💖

2.1.b. The zone's apex KEY RR set MUST be signed by a private key belonging to the parent zone. The private key's public companion MUST be a zone signing KEY RR (2.a) of a mandatory to implement algorithm and owned by the parent's apex. 🫶

If a zone can't get a conforming signature from the parent zone, the child zone can't be considered globally secured 😭. The only exception is the root zone, since there's no parent zone for it ✨.

2.1.c. NXT records MUST be deployed throughout the zone. (Clarifies RFC 2535, section 2.3.2.) Note: there's some operational discomfort with the current NXT record 💀. This requirement is open to modification once two things happen: first, an alternate mechanism to the NXT is defined, and second, there's a way for a zone to say it's using an alternate method 🧚.

2.1.d. Each RR set that qualifies for zone membership MUST be signed by a key that is in the apex's KEY RR set and is a zone signing KEY RR (2.a) of a mandatory to implement algorithm. (Updates 2535, section 2.3.1.) 🔥

As mentioned earlier, the root zone is a special case 👑. The root zone is considered globally secured as long as it conforms to the rules for locally secured, except that rule 2.1.a. must also be met (mandatory to implement requirement) 🌟.

2.2 Locally Secured

The word "locally" comes from the fact that the only resolvers likely to be configured for a particular zone are resolvers "local" to an organization 🏠.

A locally secured zone follows rules like those for a globally secured zone, with these exceptions 💅. The signing keys may use an algorithm that isn't mandatory to implement, and/or verifying the zone keys in use may rely on a verification chain that doesn't parallel the delegation tree (off-tree validation) 🦄.

2.2.a. The zone's apex MUST have a KEY RR set. There MUST be at least one zone signing KEY RR (2.a) in the set. 🎀

2.2.b. The zone's apex KEY RR set MUST be signed by a private key, and one of the following two subclauses MUST hold true. 🌸

2.2.b.1 The private key's public companion MUST be pre-configured in all the resolvers of interest. 🔑

2.2.b.2 The private key's public companion MUST be a zone signing KEY RR (2.a) authorized to provide validation of the zone's apex KEY RR set, as recognized by resolvers of interest. 🤝

This sentence is trying to get across the idea of using a trusted third party to validate keys 🧑‍🤝‍🧑. If the domain name owning the validating key isn't the parent zone, the domain name must represent someone the resolver trusts to provide validation 💜.

2.2.c. NXT records MUST be deployed throughout the zone. Note: see the discussion following 2.1.c. 🙈

2.2.d. Each RR set that qualifies for zone membership MUST be signed by a key that is in the apex's KEY RR set and is a zone signing KEY RR (2.a). (Updates 2535, section 2.3.1.) 💖

2.3 Unsecured

All other zones qualify as unsecured 🌸. That includes zones that are designed to be experimentally secure, which is covered in a later section on that topic 🧪.

2.4 Wrap up

The labels globally secured, locally secured, and unsecured are just tags we put on zones, based on what's in them 🏷️. Resolvers only ever see a zone as either secured or unsecured, depending on whether they expect a signature 👀.

Resolvers that follow the most restrictive DNSSEC verification rules will only see globally secured zones as secured, and all the others as unsecured, including locally secured zones ✨. Less restrictive resolvers, like ones that implement algorithms beyond the mandatory to implement ones, will see some locally secured zones as secured 🦋.

The point of the "global" and "local" labels is to pin down the specific attributes of a zone 📌. The words were picked to help write a document recommending what zone administrators should do when using the DNS security extensions 🧚. They're explicitly NOT meant to show whether something complies with DNS security standards 🙅‍♀️.

3 Experimental Status ✨

The whole point of an experimentally secured zone is to make it easier to move from an unsecured zone to a secured one 🦋. This distinction is dropped 💀.

You don't need a special experimental status to get that migration goal 🌈. Experimentally secured is just a special case of locally secured 🎀. A zone administrator can do this by publishing a zone with signatures and setting up a group of test resolvers with the matching public keys 🧪. Even if the public key is published in a KEY RR, without a parent signature the resolvers still need some pre-configuration to know they should process the signatures 🔧. That lets a zone be secured within the bounds of the experiment, while still being registered as unsecured on the general Internet 🌍.

4 IANA Considerations ✨

This document doesn't ask any assigned number authority for action, and it doesn't recommend any actions either 📝.

5 Security Considerations 🔐

Without a way to enforce compliance with specified protocols or recommended actions, declaring a DNS zone "completely" secured is impossible 💀. Even if, assuming an omnipotent view of DNS, one can declare a zone properly configured for security, and all of the zones up to the root too, a misbehaving resolver could be duped into believing bad data 😱. If a zone and resolver comply, a non-compliant or subverted parent could interrupt operations 🚨. The best we can hope for is that all parties are prepared to be judged secure, and that security incidents can be traced to the cause in short order 🫠.

6 Acknowledgements 🫶

The need to refine the definition of a secured zone became clear through the work of the participants at two DNSSEC workshops, sponsored by the NIC-SE (.se registrar), CAIRN (a DARPA-funded research network), and other workshops 🌟. More discussions that led to this document include Olafur Gudmundsson, Russ Mundy, Robert Watson, and Brian Wellington 💜. Roy Arends, Ted Lindgreen and others contributed significant input via the namedroppers mailing list 📬.

7 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.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
          Requirement Levels", BCP 14, RFC 2119, March 1997.

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

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

[RFC3007] Wellington, B., "Simple 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.

10 Author's Address 🧑‍💻

Edward Lewis
NAI Labs
3060 Washington Road Glenwood
MD 21738

Phone: +1 443 259 2352
EMail: lewis@tislabs.com

11 Full Copyright Statement 💖

Copyright (C) The Internet Society (2001). All Rights Reserved. ©️

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English 🌍.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns ♾️.

This document and the information contained herein 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 💜.