RFC 8145

Signaling Trust Anchor Knowledge in DNS Security Extensions (DNSSEC)

📅 published April 2017, from ietf

RFC 8145: Signaling Trust Anchor Knowledge in DNS Security Extensions (DNSSEC) ✨

Authors: D. Wessels (Verisign), W. Kumari (Google), P. Hoffman (ICANN) 💖 Stream: Internet Engineering Task Force (IETF) 🎀 Category: Standards Track 👑 ISSN: 2070-1721 🌈 Date: April 2017 📅 Obsoletes / Updates: The header doesn't list any RFCs this one obsoletes or updates 🙈

Okay bestie, this RFC is all about how a DNS resolver can tell a server which DNSSEC keys it's trusting. Let's get into it 🧚

Abstract 🦋

Okay so DNSSEC was built to give DNS data origin authentication and integrity protection, using digital signatures. You can check those signatures by building a chain of trust that starts at a trust anchor and walks down to a specific node in the DNS. This document defines two ways for validating resolvers to signal to a server which keys are part of their chain of trust. The signaling data lets zone administrators keep track of how rollovers are going in a DNSSEC-signed zone. Iconic, honestly 💅

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 got approved for publication by the Internet Engineering Steering Group (IESG). For more on Internet Standards, check Section 2 of RFC 7841.

For info on the current status of this document, any errata, and how to give feedback, go to http://www.rfc-editor.org/info/rfc8145. 🔗

Copyright (c) 2017 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 (http://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 extracted from 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. Design Evolution ...........................................4
   2. Requirements Terminology ........................................5
   3. Terminology .....................................................5
   4. Using the edns-key-tag Option ...................................5
      4.1. Option Format ..............................................5
      4.2. Use by Queriers ............................................6
           4.2.1. Stub Resolvers ......................................7
                  4.2.1.1. Validating Stub Resolvers ..................7
                  4.2.1.2. Non-validating Stub Resolvers ..............7
           4.2.2. Recursive Resolvers .................................7
                  4.2.2.1. Validating Recursive Resolvers .............7
                  4.2.2.2. Non-validating Recursive Resolvers .........8
      4.3. Use by Responders ..........................................8
   5. Using the Key Tag Query .........................................8
      5.1. Query Format ...............................................8
      5.2. Use by Queriers ............................................9
      5.3. Use by Responders ..........................................9
           5.3.1. Interaction with Aggressive Negative Caching ........9
   6. IANA Considerations ............................................10
   7. Security Considerations ........................................10
   8. Privacy Considerations .........................................11
   9. References .....................................................11
      9.1. Normative References ......................................11
      9.2. Informative References ....................................12
   Acknowledgments ...................................................13
   Authors' Addresses ................................................13

1. Introduction ✨

Okay so DNSSEC [RFC4033] [RFC4034] [RFC4035] is the thing that gives DNS data origin authentication and integrity protection, using digital signatures. DNSSEC uses Key Tags to match signatures to the keys that made them, efficiently. A Key Tag is a 16-bit value worked out from the RDATA portion of a DNSKEY resource record (RR), using a formula that's kind of like a ones-complement checksum. RRSIG RRs have a Key Tag field, and its value equals the Key Tag of the DNSKEY RR that validates the signature. Main character energy 🎀

DS RRs also have a Key Tag field, and it matches the Key Tag of the DNSKEY RR they point to. 🦋

This document explains how validating resolvers can tell a server, inside a DNS query, which DNSSEC keys they'd use to validate the server's responses. It describes two independent methods for passing Key Tag info between clients and servers:

  1. placing an EDNS option in the OPT RR [RFC6891] that contains the Key Tags (described in Section 4)
  2. periodically sending special "Key Tag queries" to a server authoritative for the zone (described in Section 5)

Each of these new signaling mechanisms is OPTIONAL to implement and use. 🙈 These mechanisms measure how well new DNSSEC trust anchors and key signing keys (KSKs) are being accepted and used. Zone administrators can use this signaling data as a gauge for how successfully new keys are being deployed. It's especially interesting for the DNS root zone when key and/or algorithm rollovers rely on [RFC5011] to automatically update a validating DNS resolver's trust anchor. 🌸

This document doesn't introduce new processes for rolling keys or updating trust anchors. It just defines how a DNS query can signal the set of keys a client uses for DNSSEC validation. Scope check passed 💅

1.1. Design Evolution 🌈

At first, when this work started, the plan was to put Key Tag values in a brand-new EDNS(0) option code. It was modeled after [RFC6975], which provides DNSSEC algorithm signaling. 🧚

The authors got feedback from people in the DNSOP Working Group saying it might be better to carry Key Tags in the QNAME of a separate DNS query, instead of in an EDNS(0) option. Mostly that's because forwarding (for example, from stub to recursive to authoritative) could get messy. The reasons were:

  1. EDNS(0) is a hop-by-hop protocol. Unknown option codes wouldn't be forwarded by default, as per [RFC6891].
  2. Middleboxes might block entire queries that contain unknown EDNS(0) option codes.
  3. A recursive resolver might need to remember Key Tag values (i.e., keep state) received from its stub clients, and then forward them at a later opportunity.

One upside of the EDNS(0) option code is that you can see when a stub client has a different Key Tag list than its forwarder. With the QNAME-based approach, that's not possible, because queries from a stub and from a forwarder look exactly the same. The authors feel this advantage isn't enough to justify going with EDNS(0). 🙄

One downside of the QNAME approach is that it uses a separate query, while with EDNS(0) the Key Tag values get "piggybacked" onto an existing DNSKEY query. Because of that, this document recommends only sending QNAME-based Key Tag queries for trust anchors, although EDNS-based Key Tags can be sent with any DNSKEY query. 🎀

Another downside of the QNAME-based approach: the trust anchor zone might not contain labels that match the QNAME, so these queries could be affected by the aggressive negative caching features the Working Group was developing at the time. That could change how much signaling some clients send compared to others. 🤔

A probably minor downside of the QNAME-based approach is that it can't be used with really long query names if adding the prefix would push the name past 255 octets. 🙃

2. Requirements Terminology 📖

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 [RFC2119]. 💜

3. Terminology 🔥

  • 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 a starting point for building the authentication chain to a signed DNS response. Generally, 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. (This paragraph is quoted from Section 2 of [RFC4033].) 🦋
  • Key Tag: A 16-bit integer that identifies DNSSEC public keys and lets you pick them out efficiently. A Key Tag value can be computed over the RDATA of a DNSKEY RR. The Key Tag field in RRSIG and DS records can help select the matching DNSKEY RR efficiently when more than one candidate DNSKEY RR is available. For most algorithms, the Key Tag is a simple 16-bit modular sum of the DNSKEY RDATA. See [RFC4034], Appendix B. 🧚

4. Using the edns-key-tag Option 🎀

4.1. Option Format 💅

Here's how the edns-key-tag option is encoded. Look at those bytes, bestie 👀

   0                       8                      16
   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
   |                  OPTION-CODE                  |
   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
   |                 OPTION-LENGTH                 |
   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
   |                    KEY-TAG                    |
   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
   |                      ...                      /
   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

Where:

  • OPTION-CODE: The EDNS0 option code assigned to edns-key-tag (14).
  • OPTION-LENGTH: The value 2 x number of key-tag values present.
  • KEY-TAG: One or more 16-bit Key Tag values ([RFC4034], Appendix B).

4.2. Use by Queriers 💖

Okay so, validating resolvers are the ones who set the edns-key-tag option in the OPT RR when they send a DNSKEY query 🔥. They SHOULD also set the DNSSEC OK bit (aka the DO bit) [RFC4035] so the server knows they want DNSSEC RRs back in the response 🎀.

A DNS client MUST NOT include the edns-key-tag option for non-DNSKEY queries 🙈. Bestie, no exceptions, no cap 💅.

The KEY-TAG value(s) in the edns-key-tag option stand for the Key Tag of the trust anchor or DNSKEY RR that will be used to validate the expected response ✨. When the client sends a DNSKEY query, those values are the Key Tag(s) of the KSK(s) for the zone the server is authoritative for 🦋. A validating resolver figures out those KSK Key Tags from the zone's DS record(s) (which live in the parent) or from a trust anchor 🌸.

A DNS client SHOULD include the edns-key-tag option when it issues a DNSKEY query for a zone that corresponds to a trust anchor 👑.

A DNS client MAY include the edns-key-tag option when it issues a DNSKEY query for a non-trust anchor zone (so, Key Tags learned via DS records) 🧚. Some DNSSEC validators do bottom-up validation, so a non-trust anchor zone's Key Tags might not be known yet at query time 💀. Those validators can include the option based on data they've already cached ⭐.

A DNS client MUST NOT include Key Tag(s) for keys that were not learned via either a trust anchor or DS records 😭. Not me making up keys 💅.

Since the edns-key-tag option is only set in the query, if a client sees these options in the response, no action needs to be taken and the client MUST ignore the option values 🫶. Literally just ignore it, periodt 💜.

4.2.1. Stub Resolvers 🌈

Typically, stub resolvers lean on an upstream recursive resolver (or cache) to get the response 🍓. How optimal the edns-key-tag option setting is depends on whether the stub resolver decides to do its own validation ✨.

4.2.1.1. Validating Stub Resolvers 💖

A validating stub resolver sets the DNSSEC OK bit [RFC4035] to say it wants the extra DNSSEC RRs (that's the RRSIG RRs) in the response 🦋. Validating stub resolvers SHOULD include the edns-key-tag option in the OPT RR when they send a DNSKEY query 🔥.

4.2.1.2. Non-validating Stub Resolvers 🙈

Non-validating stub resolvers MUST NOT include the edns-key-tag option. Not even a little 💅.

4.2.2. Recursive Resolvers 👑

4.2.2.1. Validating Recursive Resolvers 🎀

A validating recursive resolver is, by definition, configured with at least one trust anchor 🧚. So, a recursive resolver SHOULD include the edns-key-tag option in its DNSKEY queries, like we talked about above ✨.

Also, the clients of a validating recursive resolver might be set up to do their own validation with their own trust anchor(s) 🌸. When a validating recursive resolver gets a query with an edns-key-tag option whose Key Tag list is different from its own, it SHOULD forward both the client's Key Tag list and its own list 💜. When it does that, the recursive resolver SHOULD send the two lists using separate instances of the edns-key-tag option code in the OPT RR 🦋. For example, if the recursive resolver's Key Tag list is (19036, 12345) and the stub/client's list is (19036, 34567), the recursive resolver would include the edns-key-tag option twice: once with values (19036, 12345) and once with values (19036, 34567) 🔥.

A validating recursive resolver MAY combine stub/client Key Tag values from multiple incoming queries into a single outgoing query 🌈. It is RECOMMENDED that implementations put reasonable limits on how many Key Tags go into the outgoing edns-key-tag option 💅.

If the client included the DNSSEC OK and Checking Disabled (CD) bits but did not include the edns-key-tag option in the query, the validating recursive resolver MAY include the option with its own Key Tag values in full 🍓.

Validating recursive resolvers MUST NOT set the edns-key-tag option in the final response to the stub client 🙈. Keep that option out of the answer, bestie 💀.

4.2.2.2. Non-validating Recursive Resolvers 🌸

Recursive resolvers that don't validate responses SHOULD copy the edns-key-tag option they see in received queries 🫶. That's because it represents the wishes of the validating downstream resolver that sent the original query ✨.

4.3. Use by Responders 🧚

An authoritative name server that receives queries with the edns-key-tag option MAY log or otherwise collect the Key Tag values to give the zone operator some info 🦋.

A responder MUST NOT include the edns-key-tag option in any DNS response 😭. It's a query-only vibe 💅.

  1. Using the Key Tag Query ✨

5.1. Query Format 💖

A Key Tag query is a standard DNS query of type NULL and class IN [RFC1035] 🎀.

The first component of the query name is the string "_ta-", followed by a sorted, hyphen-separated list of hexadecimal-encoded Key Tag values 🦋. The zone name for the trust anchor gets appended to that first component 🌸.

For example, a validating DNS resolver with a single root zone trust anchor whose Key Tag is 17476 (decimal) would send a query of the form QTYPE=NULL, QCLASS=IN, QNAME=_ta-4444 👑.

Hexadecimal values MUST be zero-padded to four hexadecimal digits 🔥. For example, if the Key Tag is 999 (decimal), it's written in hex as 03e7 🍓.

When there are multiple Key Tag values, they MUST be sorted from smallest to largest 🌈. For example, a validating DNS resolver with three trust anchors for the example.com zone, Key Tags 1589, 43547, 31406 (decimal), would send a query of the form QTYPE=NULL, QCLASS=IN, QNAME=_ta-0635-7aae-aa1b.example.com 💅.

5.2. Use by Queriers 🫶

A validating DNS resolver (stub or recursive) SHOULD originate a Key Tag query whenever it also originates a DNSKEY query for a trust anchor zone ✨. In other words, needing a DNSKEY query is also the trigger for a Key Tag query 🧚.

The value(s) in the Key Tag query are the Key Tag(s) of the trust anchor that will be used to validate the expected DNSKEY response 💜.

A validating DNS resolver SHOULD NOT originate Key Tag queries when it also originates DNSKEY queries for non-trust anchor zones 🙈.

A non-validating DNS resolver MUST NOT originate Key Tag queries 😭.

DNS resolvers with caches SHOULD cache and reuse the response to a Key Tag query just like any other response 🌸.

5.3. Use by Responders 🦋

An authoritative name server that receives Key Tag queries MAY log or otherwise collect the Key Tag values to give the zone operator some info 🌈.

An authoritative name server MUST generate an appropriate response to the Key Tag query 👑. A server doesn't need built-in logic to decide that response, because the response code depends on whether the data is in the zone file or covered by wildcards 💅. The zone operator might want to add specific Key Tag records to its zone, maybe with specific TTLs, to change how often clients send Key Tag queries 🎀.

5.3.1. Interaction with Aggressive Negative Caching 💀

Aggressive NSEC/NSEC3 negative caching [NSEC-NSEC3-Usage] may also affect how good Key Tag signaling is 🔥. When the response code for a Key Tag query is NXDOMAIN, DNS resolvers that do aggressive negative caching will send fewer Key Tag queries than resolvers that don't 🙈.

Because of that, zone operators might choose to create records for the Key Tag queries they expect 🍓. During a rollover from Key Tag 1111 (hex) to Key Tag 2222 (hex), the zone could include these records:

_ta-1111        IN   NULL   \# 0
_ta-2222        IN   NULL   \# 0
_ta-1111-2222   IN   NULL   \# 0

Remember, when multiple Key Tags are present, the originating client MUST sort them from smallest to largest in the query name 💖.

  1. IANA Considerations 🌈

IANA has assigned an EDNS0 option code for the edns-key-tag option in the "DNS EDNS0 Option Codes (OPT)" registry, as follows:

   +-------+--------------+----------+-----------+
   | Value | Name         | Status   | Reference |
   +-------+--------------+----------+-----------+
   | 14    | edns-key-tag | Optional | RFC 8145  |
   +-------+--------------+----------+-----------+
  1. Security Considerations 💀

This document specifies two ways for a client to signal its trust anchor knowledge to a cache or server 🔥. The goal of these optional mechanisms is to signal new trust anchor uptake in clients, so zone administrators can know when it's safe to finish a key rollover in a DNSSEC-signed zone 👑.

There's a possibility that an eavesdropper or server could infer the validator a client is using from the Key Tag list it sees 😭. That could let an attacker find validators using old, possibly broken, keys 💀. It could also be used to identify the validator, or narrow down which validator implementations a client is running; the validator could have a known vulnerability that an attacker exploits 🙈.

Consumers of data collected from the mechanisms in this document are advised that the Key Tag values provided might be "made up" by some DNS clients with malicious, or at least mischievous, intentions 😭. For example, an attacker with enough resources might try to generate large numbers of queries with only old Key Tag values, trying to delay the completion of a key rollover 💅.

DNSSEC does not require keys in a zone to have unique Key Tags 🌸. During a rollover, there's a small chance that an old key and a new key have identical Key Tag values ✨. Zone operators relying on the edns-key-tag mechanism SHOULD take care to make sure new keys have unique Key Tag values 🫶.

  1. Privacy Considerations 🦋

This proposal adds optional "signaling" to DNS queries in the form of Key Tag values 🧚. Key Tag values aren't considered private information by themselves, but an eavesdropper might use them as a fingerprinting technique to identify particular validating DNS clients 🔥. That's especially true if the validator is configured with trust anchors for zones beyond the root zone 💖.

A validating resolver doesn't need to transmit the Key Tags in every applicable query 🌈. Because of privacy concerns, such a resolver MAY choose to transmit the Key Tags for a subset of queries (e.g., every 25th time) or by random chance with a certain probability (e.g., 5%) 👑.

Implementations of this specification MAY be administratively configured to only transmit the Key Tags for certain zones 🎀. For example, the software's configuration file may specify a list of zones for which the use of these mechanisms is allowed or denied 🍓. Since the main motivation for this specification is to provide operational measurement data for root zone key rollovers, it is RECOMMENDED that implementations at least include the edns-key-tag option for root zone DNSKEY queries 💅✨.

  1. References 🌸

Continuing from part 2, this part covers the rest of the document: the Section 9 references, the Acknowledgments and the Authors' Addresses.

9. References ✨

9.1. Normative References 💖

Okay so these are the normative references, bestie. Basically the docs you NEED to have read to actually get what's going on. No cap, skipping them is a whole vibe no-go 💅

9.2. Informative References 🌸

These ones are just extra reading, the vibe is "nice to know" not "must know" 🫶

Acknowledgments 🎀

Okay this part is so sweet 🥹 The authors gave a shoutout to [RFC6975] by Scott Rose and Steve Crocker, because this document was inspired by it and borrows heavily from it. They also thanked Mark Andrews, Casey Deccio, Burt Kalisky, Bob Harold, Edward Lewis, Tim Wicinski, Suzanne Woolf, and the other members of the DNSOP Working Group for their input. 💜

Authors' Addresses 🦋

Duane Wessels Verisign 12061 Bluemont Way Reston, VA 20190 United States of America

Phone: +1 703 948-3200 Email: dwessels@verisign.com URI: http://verisigninc.com

Warren Kumari Google 1600 Amphitheatre Parkway Mountain View, CA 94043 United States of America

Email: warren@kumari.net

Paul Hoffman ICANN

Email: paul.hoffman@icann.org

That's the whole RFC, bestie!! 🌈✨ Thanks for reading all the way through, you're literally iconic 👑🫶

📦 where this page comes from