RFC 7901

CHAIN Query Requests in DNS

📅 published June 2016, from ietf

RFC 7901: CHAIN Query Requests in DNS 🦋

Part 1 of 3 💖 Okay bestie, let's get into it!

  • Author: P. Wouters, from Red Hat 🎀
  • Category: Experimental 🧪
  • Date: June 2016 🌸
  • ISSN: 2070-1721 ✨
  • Obsoletes / Updates: nothing is listed in the title block, so this doc doesn't say it obsoletes or updates any other document 🙈

Abstract ✨

okay so this doc defines an EDNS0 extension 💅 that a security-aware validating resolver can use when it's set up to forward its questions to another resolver. It sends one query and asks for the whole validation path plus the regular answer 🧚 Fewer queries means the latency can drop, and you don't need to blast a bunch of queries at once 🫶

It also says the extension mandates the use of source-IP-verified transport, like TCP or UDP with EDNS-COOKIE. Because of that, it can't be abused in amplification attacks 🛡️

Status of This Memo

This document is not an Internet Standards Track specification. It's published for examination, experimental implementation, and evaluation 🔬

It defines an Experimental Protocol for the Internet community. It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community 🌈 It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every doc the IESG approves is a candidate for any level of Internet Standard, so see Section 2 of RFC 7841 for that 🙃

For info on the current status, any errata, and how to give feedback, check http://www.rfc-editor.org/info/rfc7901. ✨

Copyright (c) 2016 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, at http://trustee.ietf.org/license-info, in effect on the date of publication. Please read these carefully, because they describe your rights and restrictions with respect to 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're provided without warranty as described in the Simplified BSD License.

Table of Contents 🗂️

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
  1.1.  Requirements Notation . . . . . . . . . . . . . . . . . .   3
2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
3.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   4
4.  Option Format . . . . . . . . . . . . . . . . . . . . . . . .   5
5.  Protocol Description  . . . . . . . . . . . . . . . . . . . .   6
  5.1.  Discovery of Support  . . . . . . . . . . . . . . . . . .   6
  5.2.  Generate a Query  . . . . . . . . . . . . . . . . . . . .   6
  5.3.  Send the Option . . . . . . . . . . . . . . . . . . . . .   6
  5.4.  Generate a Response . . . . . . . . . . . . . . . . . . .   7
6.  Protocol Considerations . . . . . . . . . . . . . . . . . . .   8
  6.1.  DNSSEC Considerations . . . . . . . . . . . . . . . . . .   8
  6.2.  NS Record Considerations  . . . . . . . . . . . . . . . .   8
  6.3.  Session Management  . . . . . . . . . . . . . . . . . . .   9
  6.4.  Negative Trust Anchors  . . . . . . . . . . . . . . . . .   9
  6.5.  Anycast Considerations  . . . . . . . . . . . . . . . . .   9
7.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
  7.1.  Additional Work and Bandwidth . . . . . . . . . . . . . .  10
  7.2.  Amplification Attacks . . . . . . . . . . . . . . . . . .  10
  7.3.  Privacy Considerations  . . . . . . . . . . . . . . . . .  10
8.  Examples  . . . . . . . . . . . . . . . . . . . . . . . . . .  10
  8.1.  CHAIN Query for "www.example.com" . . . . . . . . . . . .  10
  8.2.  Out-of-Path Query for "example.com" . . . . . . . . . . .  12
  8.3.  Nonexistent Data  . . . . . . . . . . . . . . . . . . . .  13
9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  14
  9.1.  EDNS0 Option Code for CHAIN . . . . . . . . . . . . . . .  14
10. Normative References  . . . . . . . . . . . . . . . . . . . .  14
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  16
Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  16

1. Introduction 🌷

Traditionally, a DNS client runs in stub mode. For every DNS question it needs answered, it sends a single query to an upstream recursive resolver and gets back a single DNS answer 📬 When DNSSEC [RFC4033] is deployed on those clients, validation means the client has to collect all the intermediate info from the DNS root all the way down to the host name it asked about. Only then can it validate the complete chain of trust 🔗

Right now, apps send out lots of UDP requests at the same time 😩 That eats up more resources on the DNS client when it comes to state (CPU, memory, battery) and bandwidth. There's also no guarantee that the first batch of UDP questions gets all the records needed for DNSSEC validation. Depending on the answers, you might need more round trips, and that really hurts on high-latency links 💀

This doc specifies an EDNS0 extension that lets a validating resolver, acting as a forwarding resolver, open a TCP connection to another resolver and request a DNS chain answer with one DNS query/answer pair ✨ That cuts the round trips down to two. If you combine it with long-lived TCP or [RFC7828], there's only one round trip 🏃‍♀️ The upstream resolver still has to do all the individual queries for the complete answer, but it usually has a much bigger cache and doesn't get slowed down much by last-mile latency 🧠

The extension also lets the forwarding resolver say which part of the DNS hierarchy it already has in its cache. That means less data has to be transferred, and the upstream recursive resolver has less work to do 🫧

This EDNS0 extension is only meant to be sent by forwarding resolvers to recursive resolvers. It MUST be ignored by authoritative servers 🚫

1.1. Requirements Notation 📝

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

2. Terminology 📚

The DNS terminology used here is the one from [RFC7719]. On top of that, these terms show up too:

  • Forwarding Resolver: A nameserver that does not do iterative resolution itself. Instead, it hands that job to another recursive resolver, called a "forwarder" in [RFC2308], Section 1. 🔁
  • Recursive Resolver: A nameserver that resolves domain names for clients by following the domain's delegation chain, starting at the root. Recursive resolvers often use caches so they can answer client queries quickly, as described in [RFC1035], Section 7. 🌳
  • Validating Resolver: A recursive nameserver that also does DNSSEC [RFC4033] validation. Also known as a "security-aware resolver." 🛡️

3. Overview 🦋

When DNSSEC is deployed on a host, it can't hand off all the DNS work to the upstream recursive resolver anymore 😭 Getting just the DNS answer isn't enough to validate it with DNSSEC. For DNSSEC validation, the DNS client needs a locally running validating resolver, so it can confirm validation of all the intermediary DNS answers 🎀 It can set itself up as a forwarding resolver if it gets the IP addresses of one or more recursive resolvers that are available. If it didn't get any working recursive resolvers, it can act as a stand-alone recursive resolver instead 🧚

Generating the queries needed for validation adds a big delay before the local app gets its answer. The app has to wait while the resolver validates all the intermediate answers, and every round trip adds more time to DNS resolution with validation. Honestly, that makes DNSSEC resolving impractical for devices on high-latency networks 🐢

This document defines the CHAIN option, which lets the resolver request all the intermediate DNS data it needs to resolve and validate a particular DNS answer in a single round trip 💫 The resolver could be part of the app, or it could be a recursive resolver running on the host 🌸

Servers answering with CHAIN data should ensure that the peer's IP address is not a spoofed source IP address. Check Section 7 for the details. This is how DNS amplification attacks get prevented 🛡️

Apps that support CHAIN internally can do validation without the host needing to run a recursive resolver. This is especially handy for virtual servers in a cloud or container-based deployment, where running a recursive resolver per virtual machine isn't something you'd want 🍓

The format of this option is described in Section 4. 📐

As Section 5.4 explains, a recursive resolver can use this EDNS0 option to put additional data it needs into the Authority Section of the DNS answer packet. The Answer Section stays the same as a traditional DNS answer and holds the answer plus the related DNSSEC entries 🧁

An empty CHAIN EDNS0 option MAY be sent over any transport as a discovery method. A DNS server that receives such an empty CHAIN option SHOULD add an empty CHAIN option to its answer to show that it supports the CHAIN option 🔍

CHAIN brings along some security concerns about extra work, bandwidth, amplification attacks, and privacy issues with the cache. Those are all covered in Section 7 🫶

4. Option Format 🧩

This document uses an EDNS0 option [RFC6891] to include client IP information in DNS messages. The option is structured like this:

                    1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-------------------------------+-------------------------------+
!         OPTION-CODE           !         OPTION-LENGTH         !
+-------------------------------+-------------------------------+
~                Closest Trust Point (FQDN)                     ~
+---------------------------------------------------------------+

Here's what each piece means 👀

  • OPTION-CODE, 2 octets, for CHAIN is 13. 🔢
  • OPTION-LENGTH, 2 octets, contains the length of the payload (everything after Option-length) in octets. 📏
  • Closest trust point is a variable-length Fully-Qualified Domain Name (FQDN) in DNS wire format. It's the requested start point of the chain. This entry is the "lowest" known entry in the DNS chain that the recursive server knows about, the one it's asking a CHAIN answer for and already has a validated Delegation Signer (DS) and DNSKEY record for. The endpoint of the chain comes from the DNS Query Section itself. No DNS name compression is allowed for this value. 🪡

5. Protocol Description 🎀

Part 2 is up next, bestie, and it picks up right here with Section 5 and everything after it! 💜

5.1. Discovery of Support ✨

Okay so a forwarding resolver is allowed to pop a zero-length CHAIN option into a regular query over any transport 🦋, just to check whether the DNS server can do CHAIN. Recursive resolvers that support CHAIN and are willing to take CHAIN queries over a source IP verified transport reply to a zero-length CHAIN by putting a zero-length CHAIN option in the answer 💅. If the forwarder isn't already on a source-IP-verified transport, it MAY switch to one and start sending queries with the CHAIN option to ask for a CHAIN response from the recursive resolver 🌸. Examples of source-IP-verified transports are the three-way TCP handshake and UDP with DNS cookies [RFC7873]. Iconic setup, honestly 🫶

5.2. Generate a Query

Here's the vibe: in this option value, the forwarding resolver sets the closest trust point in the chain (the one furthest from the root) that it already has a DNSSEC-validated (secure or not) answer for in its cache 🧚. The upstream recursive resolver doesn't need to include any part of the chain from the root down to this option's FQDN. A complete example is described in Section 8.1 ✨

The CHAIN option should generally be sent by system forwarding resolvers and resolvers inside an application that also does DNSSEC validation 💜

5.3. Send the Option

When CHAIN is available, the downstream recursive resolver can adjust its query strategy based on the queries it wants and what's sitting in its cache 👑

A forwarding resolver can request the CHAIN option with every outgoing DNS query. However, it is RECOMMENDED that forwarding resolvers remember which upstream recursive resolvers did not return the option (and additional data) with their response 🙈 The forwarding resolver SHOULD fall back to regular DNS for later queries to those recursive resolvers. It MAY switch to another recursive resolver that does support the CHAIN option, or try again later to see if the server has become less loaded and is now willing to answer with CHAIN queries 🦋 A fallback strategy similar to the one described in [RFC6891], Section 6.2.2 SHOULD be employed to avoid persistent interference due to non-clean paths. That's the kind of plan that keeps things from getting stuck 💖

5.4. Generate a Response

When a query containing a non-zero CHAIN option comes in from a forwarding resolver, the upstream recursive resolver supporting CHAIN MAY respond by confirming that it's returning a CHAIN ✨ To do so, it MUST set the CHAIN option to the lowest trust point sent as part of the chain, with its corresponding OPTION-LENGTH. It extends the Authority Section in the DNS answer packet with the DNS RRsets required for validating the answer 🎀 The added DNS RRsets start with the first chain element below the received closest trust point, up to and including the NS and DS RRsets that represent the zone cut (authoritative servers) of the QNAME. The added RRsets MAY be added in matching hierarchical order, but a DNS client MUST NOT depend on the order of the added RRsets for validation. The actual DNS answer to the question in the Query Section goes in the DNS Answer Section, identical to the traditional DNS answer 🍓 All required DNSSEC-related records must be added to their appropriate sections. This includes records needed for proof of nonexistence of regular and/or wildcard records, such as NextSECure (NSEC) or NSEC3 records 🔥

Recursive resolvers that haven't implemented or enabled support for the CHAIN option, or that are otherwise unwilling to do the extra work for a CHAIN query because of workload, may safely ignore the option in incoming queries. Such a server MUST NOT include a CHAIN option when it sends DNS answer replies back, which signals that it isn't able or willing to support CHAIN queries at this time 😭

Requests with wrongly formatted options (i.e., bogus FQDN) MUST be rejected. A FORMERR response must be returned to the sender, as described by [RFC6891] 💀

Requests that would result in chains the receiving resolver is unwilling to serve can be rejected by answering the query as a regular DNS reply but with an empty CHAIN payload. Replying with an empty CHAIN can be used for chains that would be too big, or for chains that would reveal too much information considered private 🌈

At any time, a recursive resolver that has determined it's running low on resources can refuse CHAIN queries by replying with a regular DNS reply that has an empty CHAIN payload 🧚

If a CHAIN answer would be bigger than the recursive resolver is willing to serve, it SHOULD send a partial chain starting with the data closest to the top of the chain. The client MAY resend the query with an updated closest trust point until it has received the full chain. The CHAIN response will contain the lowest closest trust point that was included in the CHAIN answer 🦋

If the DNS request results in a CNAME or DNAME for the Answer Section, the recursive resolver MUST return these records in the Answer Section, similar to regular DNS processing. The CNAME or DNAME target MAY be placed in the Additional Section only if all supporting records for DNSSEC validation of the CNAME or DNAME target are also added to the Authority Section 💅

The response from a recursive resolver to a resolver MUST NOT contain the CHAIN option if none was present in the resolver's original request. Not adding stuff nobody asked for, iykyk 🙅‍♀️

A DNS query that contains the CHAIN option MUST also have the "DNSSEC OK" (DO) bit set. If this bit is not set, or if the "Checking Disabled" (CD) bit is set, the CHAIN option received MUST be ignored. Bit flags are so picky, bestie 😤

6. Protocol Considerations 🎀

6.1. DNSSEC Considerations

The presence or absence of an OPT resource record containing a CHAIN option in a DNS query doesn't change how the records and mechanisms are used to provide data origin authentication and data integrity to the DNS, as described in [RFC4033], [RFC4034], and [RFC4035] 🔐

6.2. NS Record Considerations

CHAIN responses SHOULD include the authoritative NS RRset with its RRSIG records required for validation. They MUST NOT include the NS RRset from the parent zone, since this RRset is not signed 🙅‍♀️ If the size of the answer is an important factor, the NS RRset MAY be omitted 🍓

When a DNSSEC chain is supplied via CHAIN, the forwarding resolver is no longer required to use the NS RRset, because it can build the validation path via the DNSKEY and DS RRsets without it 🧩 However, the forwarding resolver might be forced to switch from forwarding resolver mode to recursive resolver mode because of a network topology change. In recursive resolver mode, NS RRsets are needed to find and query authoritative servers directly. It is RECOMMENDED that the DNS forwarding resolver populate its cache with this information, so it doesn't need future queries to fetch missing NS records. Therefore, CHAIN responses MUST include the NS RRset from the child zone, including the RRSIG records required for validation ✨

6.3. Session Management

Using TCP keepalive [RFC7828] on DNS TCP sessions is RECOMMENDED. Thus, TCP sessions should not be closed right after the DNS answer to the first query is received 💖

Both DNS clients and servers have resource constraints that limit how much CHAIN queries can be run. Effective limits for the number of active sessions that can be kept on individual clients and servers should be set either as configuration options or by checking the process limits imposed by the operating system 🌸

If there's more demand for CHAIN queries than can be handled, DNS servers may stop advertising the CHAIN option in successive DNS messages. This lets clients with other candidate servers open new sessions with different servers, hoping those servers still allow CHAIN queries 🧚

6.4. Negative Trust Anchors

If a CHAIN answer would intersect with a negative trust anchor [RFC7646], a partial CHAIN up to the node above the negative trust anchor should be returned 🦋

6.5. Anycast Considerations

Recursive resolvers of various types are commonly deployed using anycast [RFC4786] 🌍

Successive DNS transactions between a client and server using UDP transport may involve responses generated by different anycast nodes, and the use of anycast inside a DNS server is effectively undetectable by the client 👀 The CHAIN option SHOULD NOT be included in responses using UDP transport from servers provisioned with anycast, unless all anycast server nodes can process the CHAIN option 🚫

Since DNS queries using CHAIN may result in longer TCP sessions, network topology changes may disrupt them more often. Anycast servers MAY make use of Multipath TCP [RFC6824] to anchor the server side of the TCP connection to an unambiguously unicast address, so topology changes don't cause disruption 🫶

7. Security Considerations 🔥

Okay, this section is serious business, so read it carefully, bestie 🚨

7.1. Additional Work and Bandwidth

Producing CHAIN answers adds load and bandwidth on the recursive resolver. At any time, a recursive resolver may decide to stop answering with CHAIN answers and fall back to traditional DNS answers 💪

7.2. Amplification Attacks

CHAIN queries can potentially send very large DNS answers. Attackers could abuse this with spoofed source IP addresses to launch large distributed denial-of-service attacks, using CHAINS as an amplification vector in their attack 😱 While TCP isn't vulnerable to this type of abuse, the UDP protocol is 💀

A recursive resolver MUST NOT return CHAIN answers to clients over UDP without source IP address verification. An example of UDP-based source IP address verification is [RFC7873]. A recursive resolver refusing a CHAIN option MUST respond with a zero-length CHAIN option to indicate support for CHAIN queries when a proper transport is used. It MUST NOT send an RCODE of REFUSED 🚨

7.3. Privacy Considerations

A client producing CHAIN queries reveals a little more about its cache contents than regular DNS clients do. This could be used to fingerprint a client across network reconnections 🕵️‍♀️ If DNS privacy is a concern, a CHAIN query client MAY try to use a DNS transport that provides privacy, such as [RFC7858], or a trusted DNS server that's contacted through a VPN connection such as IPsec 🔒

8. Examples 🍓

8.1. CHAIN Query for "www.example.com" 🎀

  • okay so a web browser on a client machine asks the forwarding resolver running on the local host to resolve the A record of www.example.com. by sending a regular DNS UDP query on port 53 to 127.0.0.1. 💖
  • the resolver on the client checks its cache and sees it already has a DNSSEC-validated entry of com., including the DNSKEY RRset with its RRSIG records. so according to its cache, .com is DNSSEC validated as "secure" and can be used to keep a DNSSEC-validated chain going. ✨
  • the resolver on the client opens a TCP connection to its upstream recursive resolver on port 53. it adds the CHAIN option like this:
    • Option-code, set to 13
    • Option-length, set to 5
    • Closest trust point set to "com." (0x03 0x63 0x6f 0x6d 0x00)
  • the upstream recursive resolver gets a DNS query over TCP with the CHAIN closest trust point set to "com.". once it accepts the query, it starts building a DNS reply packet. 🧚
  • the upstream recursive resolver does all the regular work to get every answer to the query for the A record of www.example.com.. it does this without using the CHAIN option -- unless it is also set up as a forwarding resolver. the answer could be the actual A record, the DNSSEC proof of nonexistence, or an insecure NXDOMAIN response. 🔥
  • the upstream recursive resolver adds the CHAIN option to the DNS response like this:
    • Option-code, set to 13
    • Option-length, set to 5
    • The closest trust point is set to "com." (0x03 0x63 0x6f 0x6d 0x00)
  • the upstream recursive resolver builds the DNS Authority Section and fills it (in any order) with:
    • The DS RRset for example.com. and its corresponding RRSIGs (made by the com. DNSKEY(s))
    • The DNSKEY RRset for example.com. and its corresponding RRSIGs (made by the example.com. DNSKEY(s))
    • The authoritative NS RRset for example.com. and its corresponding RRSIGs (from the child zone)

if the answer does not exist and the zone uses DNSSEC, it also adds the proof of nonexistence, such as NSEC or NSEC3 records, to the Authority Section. 🌸

  • the upstream recursive resolver builds the DNS Answer section and fills it with:
    • The A record of www.example.com. and its corresponding RRSIGs.

if the answer does not exist (NODATA or NXDOMAIN), the Answer Section stays empty. for the NXDOMAIN case, the RCODE of the DNS answer packet is set to NXDOMAIN. otherwise, it stays as NOERROR. 💅

  • the upstream recursive resolver sends the DNS answer back over the existing TCP connection. when all the data is sent, it SHOULD keep the TCP connection open so it can handle more incoming DNS queries -- as long as it has enough resources to do that. 🦋
  • the resolver on the client gets the DNS answer. it processes the Authority and Answer Sections and puts the info in its local cache. it makes sure no data gets into the cache without proper DNSSEC validation. it MAY do this by looping over the entries in the Authority and Answer Sections. when an entry is validated for the cache, it's removed from the processing list. if an entry can't be validated, it stays in the list. when the end of the list is reached, the list gets processed again until either everything is in the cache or the leftover items can't be cached because they fail validation. those entries get thrown out. 🙈
  • if the cache has a valid answer to the application's query, that answer gets returned to the application in a regular DNS answer packet. this packet MUST NOT contain a CHAIN option. if no valid answer can be returned, normal error processing happens. for example, an NXDOMAIN or an empty Answer Section could come back depending on the error condition. 💀

8.2. Out-of-Path Query for "example.com" 🌈

a recursive resolver gets a query for the A record for "example.com". it includes the CHAIN option with these parameters:

  • Option-code, set to 13
  • Option-length, set to 14
  • The closest trust point set to "unrelated.ca." (0x09 0x75 0x6e 0x72 0x65 0x6c 0x61 0x74 0x65 0x64 0x03 0x63 0x61 0x00)

there's no chain that leads from "unrelated.ca." to "example.com.", so the resolving nameserver answers with an empty CHAIN, specified using:

  • Option-code, set to 13
  • Option-length, set to 0x00 0x00
  • The closest trust point is omitted (zero length)
the regular answer is still there, just like it would be for a query that didn't specify the CHAIN option. 🫶

8.3. Nonexistent Data ✨

a recursive resolver gets a query for the A record for "ipv6.toronto.redhat.ca". it includes the CHAIN option with these parameters:

  • Option-code, set to 13
  • Option-length, set to 0x00 0x03
  • The closest trust point set to "ca."

using regular UDP queries toward authoritative nameservers, it finds the NS RRset for "toronto.redhat.ca.". when it queries for the A record, it gets a reply with RCODE "NoError" and an empty Answer Section. the Authority Section has NSEC3 and RRSIG records proving there's no A RRTYPE for the QNAME "ipv6.toronto.redhat.ca". 🔍

the recursive resolver builds a DNS reply with these CHAIN option parameters:

  • Option-code, set to 13
  • Option-length, set to 0x00 0x00
  • The closest trust point is omitted (zero length)

the RCODE is set to "NoError". the Authority Section gets filled with:

  • The DS RRset for "redhat.ca." plus RRSIGs
  • The DNSKEY RRset for "redhat.ca." plus RRSIGs
  • The NS RRset for "redhat.ca." plus RRSIGs (e.g., ns[01].redhat.ca)
  • The A RRset for "ns0.redhat.ca." and "ns1.redhat.ca." plus RRSIGs
  • The DS RRset for "toronto.redhat.ca." plus RRSIGs
  • The NS RRset for "toronto.redhat.ca." plus RRSIGs (e.g., ns[01].toronto.redhat.ca)
  • The DNSKEY RRset for "toronto.redhat.ca." plus RRSIGs
  • The A RRset and/or AAAA RRset for "ns0.toronto.redhat.ca." and "ns1.toronto.redhat.ca." plus RRSIGs
  • The NSEC record for "ipv6.toronto.redhat.ca." (proves what RRTYPEs do exist; does not include A)
  • The NSEC record for "toronto.redhat.ca." (proves no wildcard exists)

the Answer Section is empty. the RCODE is set to NOERROR. 🦋

9. IANA Considerations 👑

9.1. EDNS0 Option Code for CHAIN 💜

IANA has assigned option code 13 in the "DNS EDNS0 Option Codes (OPT)" registry to CHAIN. 🎀

10. Normative References 📚

Acknowledgments 🫶

Andrew Sullivan pointed out that we do not need any new data formats to support DNS chains. Olafur Gudmundsson made sure the RRsets get returned in the proper sections. Thanks to Tim Wicinski for his thorough review! 💖

Author's Address 🌸

Paul Wouters

Red Hat

Email: pwouters@redhat.com ✨

📦 where this page comes from