RFC 8509

A Root Key Trust Anchor Sentinel for DNSSEC

📅 published December 2018, from ietf

A Root Key Trust Anchor Sentinel for DNSSEC 🎀

RFC 8509, published in December 2018, is a Standards Track doc from the IETF. The authors are G. Huston, J. Damas (both at APNIC) and W. Kumari (at Google). It has ISSN 2070-1721. Its header doesn't list anything it obsoletes or updates, so it doesn't replace or change any other RFC. 💅

Abstract ✨

Okay so DNSSEC was built to keep DNS data trustworthy by signing it, which is so smart 🧚. You check those signatures by building a chain of trust that starts at a trust anchor and goes all the way down to a specific node in the DNS. This doc defines a mechanism that lets an end user and third parties figure out the trusted key state for the root key of the resolvers handling that user's DNS queries. 🔥 Just know that this method only works for finding out which keys are in the trust store for the root key, nothing more.

Status of This Memo 🌸

This is an Internet Standards Track document.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It went through public review and was approved for publication by the Internet Engineering Steering Group (IESG). More info on Internet Standards is in Section 2 of RFC 7841.

You can find the current status of this document, any errata, and how to send feedback at https://www.rfc-editor.org/info/rfc8509.

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

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

Table of Contents 🗺️

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
  1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   4
2.  Sentinel Mechanism in Resolvers . . . . . . . . . . . . . . .   4
  2.1.  Preconditions . . . . . . . . . . . . . . . . . . . . . .   5
  2.2.  Special Processing  . . . . . . . . . . . . . . . . . . .   6
3.  Sentinel Tests for a Single DNS Resolver  . . . . . . . . . .   7
  3.1.  Forwarders  . . . . . . . . . . . . . . . . . . . . . . .   9
4.  Sentinel Tests for Multiple Resolvers . . . . . . . . . . . .  10
  4.1.  Test Scenario and Objective . . . . . . . . . . . . . . .  11
  4.2.  Test Assumptions  . . . . . . . . . . . . . . . . . . . .  11
  4.3.  Test Procedure  . . . . . . . . . . . . . . . . . . . . .  12
5.  Security Considerations . . . . . . . . . . . . . . . . . . .  13
6.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .  14
7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  14
8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  14
  8.1.  Normative References  . . . . . . . . . . . . . . . . . .  14
  8.2.  Informative References  . . . . . . . . . . . . . . . . .  15
Appendix A.  Protocol Walk-Through Example  . . . . . . . . . . .  16
Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  19
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  19

1. Introduction ✨

Okay bestie, so DNSSEC ([RFC4033], [RFC4034], and [RFC4035]) was made to give DNS data origin authentication and integrity protection with digital signatures. 🔐 DNSSEC uses Key Tags to match each signature to the key it came from, quickly. The Key Tag is a 16-bit value worked out from the RDATA of a DNSKEY Resource Record (RR), as explained in Appendix B of [RFC4034]. The Key Tag field in an RRSIG RR holds the same value as the Key Tag of the DNSKEY RR that made the signature. Iconic. 💜

This doc explains how security-aware DNS resolvers that do validation can answer certain queries in a way that lets whoever is asking deduce whether a particular root key has been loaded into that resolver's trusted-key store. 🧚 It also describes a procedure for testing a group of resolvers to see whether at least one of them has loaded a given key into its trusted-key store. These tests can show whether a certain root zone Key Signing Key (KSK) is ready to be used as a trusted key, in the context of a planned root zone KSK roll. 🌈

There are two main use cases for this mechanism:

  • Users may want to check whether their DNS resolution environment's resolver is ready for an upcoming root KSK rollover. 🎀
  • Researchers want to run Internet-wide studies on the share of users who will be negatively impacted by an upcoming root KSK rollover. 📊

The mechanism here covers both of these use cases. ✅ It is OPTIONAL to implement and use. If you do implement it, it SHOULD be enabled by default to make Internet-wide measurement easier. 🫶 Configuration options MAY be provided to turn the mechanism off for local policy reasons.

The KSK sentinel tests in this doc use a set of DNS queries for domain names whose leftmost label has special values. The test depends on recursive resolvers supporting a mechanism that spots this special name pattern in queries. Under certain defined circumstances, the resolver returns a DNS SERVFAIL response code (RCODE 2), copying the response code that security-aware resolvers return when DNSSEC validation fails. 💀

If a browser or operating system is set up with multiple resolvers, and those resolvers behave differently (for example, one does DNSSEC validation and one doesn't), the sentinel test here can still be used. 🙈 The sentinel test makes some assumptions about DNS resolution behavior that might not hold in every environment. If those assumptions don't hold, the test may give indeterminate or inconsistent results. This could happen, for example, if the stub resolver is required to query the next recursive resolver in the locally configured set after receiving a SERVFAIL response code. In some cases where these assumptions don't hold, repeating the same test query set may give different results.

Also, the measurements this mechanism enables are different from the ones in [RFC8145]. RFC 8145 relies on resolvers reporting to the root servers a list of the trust anchors they have cached for the root zone. Those reports can show how many resolvers may be affected by a KSK roll, but they can't show what the user impact of the KSK roll will be. 💅

1.1. Terminology 📖

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

This doc has a bunch of DNS terms. You can find their current definitions in [RFC7719]. 🍓

2. Sentinel Mechanism in Resolvers 🔥

DNSSEC-validating resolvers that implement this mechanism MUST perform validation of responses in accordance with the DNSSEC response validation specification [RFC4035].

This sentinel mechanism uses two special labels:

  • root-key-sentinel-is-ta-<key-tag>
  • root-key-sentinel-not-ta-<key-tag>

These labels trigger special processing in the validating DNS resolver when responses from authoritative servers come in. Labels containing root-key-sentinel-is-ta-<key-tag> answer the question, "Is this the Key Tag of a key that the validating DNS resolver is currently trusting as a trust anchor?" Labels containing root-key-sentinel-not-ta-<key-tag> answer the question, "Is this the Key Tag of a key that the validating DNS resolver is not currently trusting as a trust anchor?" 🦋

The special labels defined here were picked after a lot of IETF evaluation of other patterns and approaches. That evaluation considered the behavior wanted inside the resolver (Sections 2.1 and 2.2) and the testing methodology that gets applied (Section 4.3). For example, underscore-prefixed names were rejected, because some browsers and operating systems wouldn't fetch them. They are domain names but not valid hostnames (see [RFC7719] for these definitions). The team also thought about local collisions and about reserving leftmost labels of a domain name. They considered the impact on zone operators who might want to use a similarly built hostname for something other than what's documented here. So just know that reserving these labels this way is definitely NOT considered "best practice". 🙈 It's a special case, not a model to copy. ✨

2.1. Preconditions 🎀

All of the following conditions must be met to trigger special processing inside resolver code:

  • The DNS response is DNSSEC validated.
  • The result of validation is "Secure".
  • The Extension Mechanisms for DNS (EDNS(0)) Checking Disabled (CD) bit in the query is not set.
  • The QTYPE is either A or AAAA (Query Type value 1 or 28).
  • The OPCODE is QUERY.
  • The leftmost label of the original QNAME (the name sent in the Question Section in the original query) is either root-key-sentinel-is-ta-<key-tag> or root-key-sentinel-not-ta-<key-tag>.

If any one of the preconditions isn't met, the resolver MUST NOT alter the DNS response based on the mechanism in this document. 💀

Here's a detail that really matters. The <key-tag> goes in the DNS label as an unsigned decimal integer (as described in [RFC4034], Section 5.3), but it's zero-padded to five digits. For example, a Key Tag value of 42 would be written in the label as 00042. The precise specification of the special labels above should be followed exactly. For instance, a label that doesn't include a Key Tag zero-padded to five digits does not match this specification and should not be processed as if it did. In other words, queries like that should be handled as any other label and not according to Section 2.2. 🔥 Be precise, bestie, this part is non-negotiable 👑

2.2. Special Processing ✨

okay so responses that pass every single precondition from Section 2.1 need special processing 💅 and what happens depends on the leftmost label in the QNAME 🎀

First up, the resolver checks whether the numerical value of <key-tag> matches the Key Tag of any active root zone KSK that it currently trusts and keeps in its store of trusted keys 🔑 An "active" root zone KSK is one that could be used for validation right now, meaning it's not in the AddPend or Revoked state, as described in [RFC5011] 🦋

Next, the resolver changes the response it sends back to the original query, based on BOTH the leftmost label AND whether a key with that Key Tag is in the trust-anchor store 🧚 Two labels times two possible key states gives four combos, and here's the whole tea in one table 🍓

 Label      | Key is trusted          | Key is not trusted
------------------------------------------------------------------
is-ta      | return original answer  | return SERVFAIL
not-ta     | return SERVFAIL         | return original answer

So "return SERVFAIL" means the resolver MUST set RCODE=SERVFAIL (value 2), and the Answer Section of the DNS response MUST be empty 🙈 That applies even if other documents say what should go in the Answer Section, so they get ignored, periodt 💀

"Return original answer" is the opposite energy 🌸 The resolver MUST process the query without any further special processing, which means it acts exactly as if this mechanism wasn't implemented or was turned off. The answer for the A or AAAA query just gets sent on to the client 💜

3. Sentinel Tests for a Single DNS Resolver 🦋

This section is all about using the sentinel detection mechanism against ONE DNS recursive resolver, to figure out whether it's using a particular trust anchor to validate DNSSEC-signed responses 🔍

Quick heads up: the test in this section is for a single DNS resolver. The test in Section 4 is for a whole collection of DNS resolvers, like what you'd find in an end-user's DNS configuration 🏠

The big thing to know about the DNS names here is that they contain the specified label, either the positive or the negative one, as the leftmost label in the query name ✨

The sentinel detection procedure tests a resolver with three queries 🎀

  • A query name with the leftmost label root-key-sentinel-is-ta-<key-tag>. This matches a validly signed name in the parent zone, so responses for it can be authenticated by a DNSSEC-validating resolver. Any validly signed DNS zone can be the parent zone for this test 💖
  • A query name with the leftmost label root-key-sentinel-not-ta-<key-tag>. This one is also a validly signed name, and again any validly signed DNS zone can be the parent zone 🌈
  • A query name that's signed with a DNSSEC signature that can't be validated. This is the "bogus" RRset from Section 5 of [RFC4033], for example when an RRset belongs to a zone that isn't signed with a valid RRSIG record 🙃

You can use the responses to these queries to infer the trust key state of the DNS resolver 🔮

Here's the big assumption, bestie: this technique relies on security-aware (DNSSEC-validating) resolvers returning a SERVFAIL response code to queries where DNSSEC checking was requested and the response can't be validated 🚨 Other issues can also make a resolver return SERVFAIL, so the sentinel processing might sometimes give wrong or inconclusive results 😭

To classify things, DNS resolvers get sorted into five behavior types, labelled "Vnew", "Vold", "Vind", "nonV", and "other" 🌟 Here's what each one means:

Vnew: A DNS resolver that's configured to implement this mechanism AND has loaded the nominated key into its local trusted-key stores will answer the "root-key-sentinel-is-ta" queries with an A or AAAA RRset response, answer the "root-key-sentinel-not-ta" queries with SERVFAIL, and answer the signed name queries that return "bogus" validation status with SERVFAIL 👑

Vold: A DNS resolver that's configured to implement this mechanism but has NOT loaded the nominated key into its local trusted-key stores will answer the "root-key-sentinel-is-ta" queries with SERVFAIL, the "root-key-sentinel-not-ta" queries with an A or AAAA RRset response, and the signed name queries that return "bogus" validation status with SERVFAIL 🥀

Vind: A DNS resolver that's NOT configured to implement this mechanism will answer "root-key-sentinel-is-ta" with an A or AAAA RRset response, "root-key-sentinel-not-ta" with an A or AAAA RRset response, and the name that returns "bogus" validation status with SERVFAIL. This set of responses doesn't tell you anything about the trust anchors this resolver uses 🤷‍♀️

nonV: A non-security-aware DNS resolver answers "root-key-sentinel-is-ta" with an A or AAAA RRset response, "root-key-sentinel-not-ta" with an A or AAAA RRset response, and the "bogus" name with an A or AAAA RRset response too 🫠

other: Other combinations of responses to these three queries are possible. It might sound self-contradictory, but it can totally happen 🙈 For example, in DNS resolver farms, what looks like a single resolver behind one IP address is actually a bunch of slave resolvers, and the query gets passed to one of them. If those slaves don't all behave the same way, you can get different sets of results from these three queries. In that case, no determination about this resolver farm's capabilities can be made 🌀

Heads up: SERVFAIL might get cached according to Section 7 of [RFC2308] for up to 5 minutes, and a positive answer can be cached for up to its TTL ⏰

If a client sends these three queries to a single resolver, the responses should let the client work out the resolver's capability and, if it supports this sentinel mechanism, whether it has a particular key in its trust-anchor store 💅 Here's the cheat sheet 🍓

                                 Query
                   +----------+-----------+------------+
                   |  is-ta   |  not-ta   |   bogus    |
           +-------+----------+-----------+------------+
           | Vnew  |    Y     |  SERVFAIL |  SERVFAIL  |
           | Vold  | SERVFAIL |      Y    |  SERVFAIL  |
     Type  | Vind  |    Y     |      Y    |  SERVFAIL  |
           | nonV  |    Y     |      Y    |     Y      |
           | other |    *     |      *    |     *      |
           +-------+----------+-----------+------------+

In that table, "Y" means an A or AAAA RRset response (depending on whether the query type is A or AAAA), "SERVFAIL" means a DNS SERVFAIL response code (RCODE 2), and "*" means either response is possible 🎀

And what each classification tells you 🫶

  • Vnew: The nominated key is trusted by the resolver. 👑
  • Vold: The nominated key is not yet trusted by the resolver. 🌸
  • Vind: There's no information about the trust anchors of the resolver. 🤍
  • nonV: The resolver doesn't do DNSSEC validation. 🙅‍♀️
  • other: The properties of the resolver can't be analyzed by this protocol. 💀

3.1. Forwarders 🧚

Some resolvers are set up NOT to answer queries with the recursive algorithm first described in [RFC1034], Section 4.3.2. Instead, they relay queries to one or more other resolvers 📬 In this document, resolvers set up like this are called "forwarders" 💖

If the resolver is non-validating and has a single forwarder, it will presumably mirror the capabilities of the forwarder's target resolver 🪞

If the validating resolver has a forwarding configuration and sets the EDNS(0) Checking Disabled (CD) bit, as described in Section 3.2.2 of [RFC4035], on ALL forwarded queries, then this resolver is acting exactly like a standalone resolver 🦋

Now the more complicated case, where ALL of the following are true 🌀

  • Both the validating resolver and the forwarder target resolver support this trusted key sentinel mechanism. 🔑
  • The local resolver's queries do NOT have the EDNS(0) CD bit set. 🙅‍♀️
  • The trusted key state is different between the forwarding resolver and the forwarder's target resolver. ⚡

In that situation, either the outcome is indeterminate validating ("Vind"), or there are mixed signals like SERVFAIL in all three responses ("other"), which is also an indeterminate response for the trusted key state 😵‍💫

4. Sentinel Tests for Multiple Resolvers 🌈

Section 3 covers a trust-anchor test for the simple case, where the test queries go to a single recursive resolver that directly queries authoritative name servers 📮

BUT the common end-user setup is that their local DNS resolution environment is configured with more than one recursive resolver 😩 The single-resolver technique won't work reliably there, because a SERVFAIL from one resolver can make the local stub resolver repeat the query against another configured resolver, and then the results might be inconclusive 🌪️

So for a test procedure that works across a set of DNS resolvers, a few things have to change: the question the test answers, the assumptions about how the DNS resolution environment behaves, and some extra notes about how much the test outcomes can vary 🎀

4.1. Test Scenario and Objective 💅

This test is NOT meant to reveal which trust anchors any single DNS resolver uses 🙅‍♀️

The scenario is explicitly limited to the KSK environment, where a current, active KSK (called "KSK-current") is going to be replaced with a new KSK (called "KSK-new") 🔄 The test is designed to run between when KSK-new is introduced into the root zone and when the root zone gets signed with KSK-new 🗓️

The goal is to figure out whether the user will be negatively impacted by the KSK roll 🥺 A "negative impact" is defined as this: ALL the configured resolvers are security-aware resolvers that validate DNSSEC-signed responses, and NONE of them have loaded KSK-new into their local trust-anchor set 💀 In that situation, once the KSK is rolled, the whole set of the user's resolvers is expected to be unable to validate the contents of the root zone, so the user will likely lose DNS service because of that inability to do successful DNSSEC validation 😭🫶

4.2. Test Assumptions ✨

okay so this test is making a bunch of assumptions about the DNS setup it's running in 🎀. if any of them don't hold, the results are indeterminate, so pls don't trust a result that breaks one of these 💀

  • When a recursive resolver returns SERVFAIL to the user's stub resolver, the stub resolver will send the same query to the next resolver in the locally configured resolver set. It keeps doing this until it either gets a non-SERVFAIL response or runs out of resolvers to try. 🔁
  • When the user's stub resolver passes a query to a resolver in the configured resolver set, it gets a consistent answer over the time frame of the queries. so if the same stub resolver asks the same query to the same recursive resolver a bunch of times in a row, the answer is the same every time 🧚
  • All DNSSEC-validating resolvers have KSK-current in their local trust-anchor cache. 🔑

ngl there's no current published measurement data showing how true the first two assumptions are, or how many end users they could affect 🙈 the first one is the big deal here. the whole test hinges on a consistent SERVFAIL making the local stub setup try every configured recursive resolver before it gives up on the name. super critical 👑

also, if you want more precision, you can skip the normal OS behavior and test each configured recursive resolver directly, like with "dig" ✨

4.3. Test Procedure 🦋

the sentinel detection process pokes a DNS resolution environment with three query names. these are the same general kinds of query we saw in Section 3, but the Key Tag is different for some of them 💜

  • a query name that's signed with a DNSSEC signature that can't be validated. the RRset is "bogus" in the Section 5 of [RFC4033] sense, for example when an RRset isn't signed with a valid RRSIG record 💀
  • a query name whose leftmost label is root-key-sentinel-not-ta-<key-tag-of-KSK-current>. this name MUST be a validly signed name. any validly signed DNS zone can be used for this test 🌸
  • a query name whose leftmost label is root-key-sentinel-is-ta-<key-tag-of-KSK-new>. this name MUST be a validly signed name. any validly signed DNS zone can be used for this test 🌸

the responses to resolving each of these names can be read to infer the trust key state of the user's DNS resolution environment. it's giving detective energy 🔍

we describe the responses with a simplified notation. each query ends up as either a SERVFAIL response (written "S"), meaning every resolver in the recursive resolver set returned SERVFAIL, or a response with the desired RRset value (written "A"). the queries are listed in this order: the "invalid" name, then the "root-key-sentinel-not-ta" label, then the "root-key-sentinel-is-ta" label. a triplet like (S S A) shows one particular set of responses. so (S S A) means SERVFAIL for the invalid query, SERVFAIL for the "root-key-sentinel-not-ta" query, and an RRset response for the "root-key-sentinel-is-ta" query 🧠

here are all the possible response sets:

  • (A * *): if any resolver gives an "A" response for the invalid name, then the resolver set has at least one non-validating DNS resolver, and the user won't be impacted by the KSK roll. the main character never has to worry about it 💖
  • (S A *): if any resolver gives an "A" response for the "root-key-sentinel-not-ta" query, then at least one resolver doesn't recognize the sentinel mechanism, and the behavior of the whole collection of resolvers during the KSK roll can't be reliably determined. this one's a little messy 🫠
  • (S S A): this means every resolver in the set does DNSSEC validation, every resolver knows about the sentinel mechanism, and at least one resolver has loaded KSK-new as a local trust anchor. the user won't be impacted by the KSK roll ✨🎀
  • (S S S): this means every resolver in the set does DNSSEC validation, every resolver knows about the sentinel mechanism, and none of them has loaded KSK-new as a local trust anchor. the user WILL be negatively impacted by the KSK roll 😭
the user will be negatively impacted in the (S S S) case, so this is the one to watch 👀

5. Security Considerations 🔐

this document describes a mechanism that lets users figure out the trust-anchor state of the root zone key signing keys in the DNS resolution system they use. if the user runs third-party code, then that third party may be able to see this information too 👀

the mechanism doesn't require resolvers to mark responses that weren't otherwise authenticated as authenticated 🙅‍♀️ it also doesn't change the security properties of DNSSEC when it comes to deciding whether responses marked as authenticated are authentic. DNSSEC stays exactly as safe as it was ✨

the mechanism doesn't need any significant extra processing of DNS responses either. the queries described in this document don't add any extra load that an attacker could exploit beyond the normal DNSSEC-validation load 🛡️

6. Privacy Considerations 🫣

the mechanism in this document lets third parties, whether they mean well or not, learn something about the security configuration of recursive DNS resolvers 👀 someone who can make an Internet user send specific DNS queries (for example through web-based advertisements or JavaScript in web pages) can, in certain specific circumstances, figure out which trust anchors are configured in those resolvers. that's only possible if they also know which resolvers the user's requests go through 🕵️‍♀️

without that extra knowledge, the third party can infer the aggregate capabilities of the user's DNS resolution environment, but they can't necessarily infer the trust configuration of any particular recursive name server 🌈

7. IANA Considerations 🎀

This document has no IANA actions. 💅

8. References 📚

8.1. Normative References

[RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
           STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
           <https://www.rfc-editor.org/info/rfc1034>.

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119,
           DOI 10.17487/RFC2119, March 1997,
           <https://www.rfc-editor.org/info/rfc2119>.

[RFC2308]  Andrews, M., "Negative Caching of DNS Queries (DNS
           NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998,
           <https://www.rfc-editor.org/info/rfc2308>.

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

[RFC5011]  StJohns, M., "Automated Updates of DNS Security (DNSSEC)
           Trust Anchors", STD 74, RFC 5011, DOI 10.17487/RFC5011,
           September 2007, <https://www.rfc-editor.org/info/rfc5011>.

[RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
           2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
           May 2017, <https://www.rfc-editor.org/info/rfc8174>.

8.2. Informative References

[RFC7719]  Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
           Terminology", RFC 7719, DOI 10.17487/RFC7719, December
           2015, <https://www.rfc-editor.org/info/rfc7719>.

[RFC8145]  Wessels, D., Kumari, W., and P. Hoffman, "Signaling Trust
           Anchor Knowledge in DNS Security Extensions (DNSSEC)",
           RFC 8145, DOI 10.17487/RFC8145, April 2017,
           <https://www.rfc-editor.org/info/rfc8145>.

Appendix A. Protocol Walk-Through Example

Okay bestie, gather round because this appendix is the cutest walkthrough ever 🎀✨ It's not normative (no pressure!) and it's written in a chatty tone so it's easier to follow 💅 Everyone in this story has just one resolver, or a bunch of resolvers that all act the same, so no drama there 🌸

Meet Alice 👑, who is in charge of the DNS root KSK (Key Signing Key). She wants to roll (replace) the key with a new one 🔄. She publishes the new KSK, but she really wants to predict or measure the impact before she removes or revokes the old key 🙈. The current KSK has Key Tag 11112, and the new KSK has Key Tag 02323. Users want to check that their resolver won't break once Alice rolls the root KSK, which means it starts signing with just the KSK whose Key Tag is 02323 💖

Next up are Bob, Charlie, Dave, and Ed 🫶, all users who get their DNS recursive resolvers from their ISPs. They want to confirm that their ISPs have picked up the new KSK. Bob's ISP doesn't validate at all 💀. Charlie's ISP does validate, but its resolvers haven't been upgraded to support this mechanism yet 😭. Dave and Ed's resolvers have been upgraded to support this mechanism 🦋. Dave's resolver has the new KSK, but Ed's resolver hasn't managed to install the 02323 KSK in its trust store yet 🥲

Then there's Geoff 🧚, a researcher. He wants to give Bob, Charlie, Dave, and Ed a way to run tests, and he also wants to do Internet-wide measurements of what the impact will be (and report back to Alice) 📊 Iconic behaviour from a researcher, honestly 🔥

Geoff sets up an authoritative DNS server for example.com and also a web server at www.example.com 🌈 He adds three address records to example.com:

bogus.example.com.  IN AAAA 2001:db8::1

root-key-sentinel-is-ta-02323.example.com.  IN AAAA 2001:db8::1

root-key-sentinel-not-ta-11112.example.com.  IN AAAA 2001:db8::1

Quick heads up: the use of "example.com" names and these addresses are just examples, and "bogus" intentionally has invalid DNSSEC signatures 🙈 In a real deployment, the domain names need to be under the control of the researcher, and the addresses must be real, reachable addresses 💅

Next, Geoff DNSSEC signs the example.com zone and makes the bogus.example.com record have bogus validation status on purpose. He does this by editing the signed zone and entering garbage for the signature 😭💀 He also configures his web server to listen on 2001:db8::1 and serve a resource (for example, a 1x1 GIF, 1x1.gif) for all of these names ✨ The web server also serves a web page (www.example.com) with links to these three resources:

http://bogus.example.com/1x1.gif
http://root-key-sentinel-is-ta-02323.example.com/1x1.gif
http://root-key-sentinel-not-ta-11112.example.com/1x1.gif

Then Geoff asks Bob, Charlie, Dave, and Ed to browse to www.example.com 🍓 Using the methods described in this document, the users can figure out what their fate will be when the 11112 KSK is removed 🔮

Bob is not using a validating resolver 🌸 That means he can resolve bogus.example.com and fetch the 1x1 GIF. This tells him the KSK roll doesn't affect him, so he's OK 💖

Charlie's resolvers are validating, but they haven't been upgraded to support the KSK sentinel mechanism 😬 Charlie can't fetch http://bogus.example.com/1x1.gif, because the bogus.example.com record is bogus and none of his resolvers will resolve it 💀 He can fetch both of the other resources, and from that he knows (see the logic in the body of this document) that he's using validating resolvers, but at least one of them isn't configured to do sentinel processing 🙈 The KSK sentinel method can't give him a definitive answer on whether he'll be impacted by the KSK roll 🥺

Dave's resolvers implement the sentinel method and have picked up the new KSK 🦋 For the same reason as Charlie, he can't fetch the "bogus" resource 💀 His resolver resolves root-key-sentinel-is-ta-02323.example.com normally (it contacts the example.com authoritative servers, etc.). Since it supports the sentinel mechanism, just before Dave's recursive resolver sends the reply to Dave's stub, it performs the KSK sentinel check 🔍 The QNAME starts with "root-key-sentinel-is-ta-", and the recursive resolver does have a key with Key Tag 02323 in its root trust store 🎉 So this part of the check passes (it is true that Key Tag 02323 is in the trust-anchor store), and the recursive resolver replies normally with the answer from the authoritative server 💅

Dave's recursive resolver then resolves root-key-sentinel-not-ta-11112.example.com 🧐 Once again it does the normal resolution process, but because it implements KSK sentinel (and the QNAME starts with "root-key-sentinel-not-ta-"), just before sending the reply it performs the KSK sentinel check. Since it has the key with Key Tag 11112 in its trust-anchor store, the answer to "is this not a trust anchor" is false 🚫 So the recursive resolver does not reply with the answer from the authoritative server. Instead, it replies with a SERVFAIL 💀 (Note that replying with SERVFAIL instead of the original answer is the only mechanism KSK Sentinel uses ✨) This means Dave can't fetch "bogus", he can fetch "root-key-sentinel-is-ta-02323", but he can't fetch "root-key-sentinel-not-ta-11112" 🙃 From this, Dave knows he's behind a collection of resolvers that all validate, that all have the key with Key Tag 11112 loaded, and that at least one of them has loaded the key with Key Tag 02323 into its local trust-anchor cache 🫶 Dave will not be impacted by the KSK roll 🎀🌈

Just like Charlie and Dave, Ed can't fetch the "bogus" record 💀 That tells him his resolvers are validating 🔍 When his (sentinel-aware) resolvers perform the KSK sentinel check for "root-key-sentinel-is-ta-02323", none of them have loaded the new key with Key Tag 02323 into their local trust-anchor store 😱 So the check fails, and Ed's recursive resolver turns the (valid) answer into a SERVFAIL error response 🙈 It does the same check for root-key-sentinel-not-ta-11112.example.com, and since all of Ed's resolvers both perform DNSSEC validation and recognize the sentinel label, Ed can't fetch the "root-key-sentinel-not-ta-11112" resource either 💔 This tells Ed that his resolvers haven't installed the new KSK, so he will be negatively impacted by the KSK roll 😭

Geoff wants to do a large-scale test and send the information back to Alice 📈 He uses some mechanism, such as getting lots of users to visit a web page so they all try to resolve the three resources 🌐 Then he analyses the results to work out what percentage of users will be affected by the KSK rollover event 💜

This description is a simplified example 🧸 It's not expected that Bob, Charlie, Dave, and Ed will actually look for the absence or presence of web resources. Instead, the web page they load would probably contain JavaScript (or something similar) that displays the test results, sends them to Geoff, or both 💻 And the sentinel mechanism doesn't rely on the web at all! It can equally be used by trying to resolve the names (for example, with the common "dig" command) and checking which names result in a SERVFAIL 🫧

Acknowledgements

This document has borrowed extensively from [RFC8145] for the introductory text, and the authors would like to acknowledge and thank the authors of that document, both for some text excerpts and for the more general stimulation of thoughts about monitoring the progress of a roll of the KSK of the root zone of the DNS 🙏💖

The authors would like to thank Joe Abley, Mehmet Akcin, Mark Andrews, Richard Barnes, Ray Bellis, Stephane Bortzmeyer, David Conrad, Ralph Dolmans, John Dickinson, Steinar Haug, Bob Harold, Wes Hardaker, Paul Hoffman, Matt Larson, Jinmei Tatuya, Edward Lewis, George Michaelson, Benno Overeinder, Matthew Pounsett, Hugo Salgado-Hernandez, Andreas Schulze, Mukund Sivaraman, Petr Spacek, Job Snijders, Andrew Sullivan, Ondrej Sury, Paul Vixie, Duane Wessels, and Paul Wouters for their helpful feedback 🥰👑

The authors would like to especially call out Paul Hoffman and Duane Wessels for providing comments in the form of pull requests 🔥 Joe Abley also helpfully provided extensive review and OLD / NEW text 💅

Petr Spacek wrote some very early implementations and provided significant feedback, including pointing out when the test bed didn't match the document! 😭✨

Authors' Addresses

Geoff Huston Email: gih@apnic.net URI: http://www.apnic.net

Joao Silva Damas Email: joao@apnic.net URI: http://www.apnic.net

Warren Kumari Email: warren@kumari.net

📦 where this page comes from