RFC 9704

Establishing Local DNS Authority in Validated Split-Horizon Environments

📅 published January 2025, from ietf

RFC 9704: Establishing Local DNS Authority in Validated Split-Horizon Environments 🎀

Okay bestie, so the title block tells us this is RFC 9704 💖 and it's on the Standards Track 🔥. It's from the IETF (ISSN 2070-1721) and was published in January 2025. Four people wrote it: T. Reddy.K from Nokia, D. Wing from Citrix, K. Smith from Vodafone, and B. Schwartz from Meta. The title block doesn't list anything it obsoletes or updates, so nothing gets replaced or patched here 🦋

Abstract

Okay so, when a network runs split-horizon DNS, some domain names get answered authoritatively by the DNS resolver the network gives you 🌸 Clients that don't use that resolver by default can still ask it about those specific domains only. This spec defines a way for domain owners to tell DNS clients which local resolvers are allowed to answer authoritatively for certain subdomains. It's giving authorization, 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 reflects the consensus of the IETF community. It went through public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more info on Internet Standards, check out Section 2 of RFC 7841 🧚

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

Copyright (c) 2025 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) as they stand on the date of publication. Please read these carefully, because they explain your rights and restrictions for this document. Code Components pulled out of this document need to include the Revised BSD License text described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as laid out in the Revised BSD License 🫶

Table of Contents

   1.  Introduction
   2.  Terminology
   3.  Scope
   4.  Requirements
   5.  Establishing Local DNS Authority
     5.1.  Example
     5.2.  Conveying Authorization Claims
       5.2.1.  Using DHCP
       5.2.2.  Using Provisioning Domains
   6.  Validating Authority over Local Domain Hints
     6.1.  Using a Preconfigured External Resolver
     6.2.  Using DNSSEC
   7.  Delegating DNSSEC Across Split DNS Boundaries
   8.  Example Split-Horizon DNS Configuration
     8.1.  Verification Using an External Resolver
     8.2.  Verification Using DNSSEC
   9.  Operational Efficiency in Split-Horizon Deployments
   10. Validation with IKEv2
   11. Authorization Claim Update
   12. Security Considerations
   13. IANA Considerations
     13.1.  New DHCP Authentication Algorithm for Split DNS
     13.2.  New PvD Additional Information Type for Split DNS
     13.3.  New PvD Split DNS Claims Registry
       13.3.1.  Guidelines for the Designated Experts
     13.4.  DNS Underscore Name
   14. References
     14.1.  Normative References
     14.2.  Informative References
   Acknowledgements
   Authors' Addresses

1. Introduction ✨

To resolve a DNS query, an implementation can do one of three main things: (1) answer from a local database, (2) query the relevant authorities and their parents, or (3) ask a server to query those authorities and hand back the final answer 💖 Implementations that do these are called "authoritative nameservers", "full/recursive resolvers", and "forwarders" (or "stub resolvers"), in that order. An implementation can also mix these behaviors depending on local policy, for each query. That kind is called a "hybrid resolver" 🦋

Most DNS resolvers are hybrids of some kind, lowkey all of them 🌸 For example, stub resolvers support a local "hosts file" that gets checked before forwarding happens, and most DNS forwarders and full resolvers can also serve answers from a local zone file. Other standardized hybrid behaviors include using a local root [RFC8806], Multicast DNS (mDNS) [RFC6762], and NXDOMAIN synthesis for .onion [RFC7686] 🧚

Networks usually give clients a DNS resolver through things like DHCP offers or IPv6 Router Advertisements (RAs). Even though this resolver is formally specified as a recursive resolver (see Section 5.1 of [RFC8106], for example), some networks actually provide a hybrid resolver instead 👀 If this resolver acts as an authoritative server for some names and, depending on who's asking, gives different answers for those domains, the network is using "split-horizon DNS". Those names only resolve that way from inside the network, so it's giving secret-garden energy 🌈

Clients that use pure stub resolution, sending every query to the network-provided resolver, will always get the split-horizon results. On the flip side, clients that send everything to a different resolver or do pure full resolution locally will never see them. Clients that strictly do either of those are out of scope for this spec. Instead, this spec lets hybrid clients get split-horizon results from a network-provided hybrid resolver, while using a different resolution method for some or all other names 💅

There are already a bunch of mechanisms that let a network give clients "local domain hints", which are lists of domain names that get special treatment on that network. Some examples: "Recursive DNS Server (RDNSS) selection" [RFC6731], "access network domain name" [RFC5986], and "Client Fully Qualified Domain Name (FQDN)" [RFC4702] [RFC4704] in DHCP; "dnsZones" in Provisioning Domains (PvDs) [RFC8801]; and "INTERNAL_DNS_DOMAIN" [RFC8598] in Internet Key Exchange Protocol Version 2 (IKEv2). The tea, though: none of the local domain hint mechanisms let clients check whether the domain owner actually authorized that special treatment. These specs make clients decide for themselves whether to trust and rely on those hints 🙈

This document describes a mechanism between domain names, networks, and clients. It lets the network establish its authority over a domain to a client (Section 5). Clients can use this protocol to confirm that a local domain hint was authorized by the domain owner (Section 6), which might change how they process that hint. This whole process needs the local DNS zone and the public zone to cooperate 🫶

In this specification, network operators securely identify the local DNS servers, and clients check each local domain hint against a globally valid parent zone. Main character energy for the parent zone, no cap 👑

2. 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. Those are the only capitalized ones that count as keywords, so read them carefully 🙈

This document uses the terms defined in [RFC9499], e.g., "global DNS". The following extra terms show up throughout the doc:

  • Encrypted DNS: A DNS protocol that gives you an encrypted channel between a DNS client and server (e.g., DNS over TLS (DoT) [RFC7858], DNS (queries) over HTTPS (DoH) [RFC8484], DNS over QUIC (DoQ) [RFC9250]) 🔐
  • Encrypted DNS Resolver: A DNS resolver that supports any encrypted DNS scheme 💜
  • Split-Horizon DNS: The DNS service a resolver provides when it also acts as an authoritative server for some names, giving results that are meaningfully different from what you'd get in the global DNS. (See the definition of "split DNS" in Section 6 of [RFC9499].) 🌸
  • Validated Split Horizon: A split-horizon configuration that the parents of the affected names authorize and the client confirms. That authorization generally covers the entire subtree of names below the authorization point ✨

In this document, "owner" and "operator" are used interchangeably. They both mean the individual or entity in charge of managing and maintaining domains 💅

3. Scope 🦋

The protocol in this document is designed so a domain owner can create or authorize a split-horizon view of their own domain 💖 It does not support split-horizon views made by any other entity. So DNS filtering is not enabled by this protocol, bestie, just FYI 🚫

The protocol applies to any type of network that offers split-horizon DNS configuration. The endpoint doesn't need any prior configuration to confirm that a local domain hint was actually authorized by the domain 🧚

All of the Special-Use Domain Names registered with IANA [RFC6761], most notably home.arpa., resolver.arpa., ipv4only.arpa., and local., are never unique to one DNS server's authority 😭 All Special-Use Domain Names are outside the scope of this document and MUST NOT be validated using the mechanism described in this document. Do not try it, periodt 💀

The use of this specification is limited to DNS servers that support authenticated encryption and to split-horizon DNS names rooted in the global DNS 🌈

4. Requirements 👑

This solution is trying to meet the following requirements:

  • No loss of security: No unauthorized party can impersonate a zone unless they could already do it without this specification. Security glow-up, not a downgrade 🔥
  • Least privilege: Local resolvers don't hold any secrets that could weaken the security of the public zone if they get compromised 🫶
  • Local zone confidentiality: The specification doesn't leak local network subdomains to anyone outside the network 🙈
  • Flexibility: The specification can represent and authorize a split DNS zone structure ✨
  • DNSSEC compatibility: The specification supports DNSSEC-based object security for local zone contents per [RFC9364] 💖

Part 2 is next, bestie, and it's where the actual mechanism lives 🦋💅

5. Establishing Local DNS Authority ✨

Okay bestie, so the network has to offer at least one encrypted resolver through DHCP and Router Advertisement options 💅. That's how clients find it, using Discovery of Network-designated Resolvers (DNR) [RFC9463], Discovery of Designated Resolvers (DDR) [RFC9462], or an equivalent mechanism (see Section 10). The network MUST do this, no skipping 🫶.

Now for the main event. To set up local authority, the network MUST send one or more "authorization claims" to the client 🎀. An authorization claim is an abstract structure (think of it as a little bundle of info) with these pieces:

  • An Authentication Domain Name (ADN) of a local encrypted resolver.
  • The DNS name of the authorizing parent zone.
  • A set of subdomains of this parent zone that are claimed by the named local resolver (this can include the entire parent zone). To claim the entire parent zone, the claimed subdomain is written as an asterisk symbol ("*").
  • A ZONEMD Hash Algorithm (Section 5.3 of [RFC8976]). For interoperability purposes, implementations MUST support the "mandatory to implement" hash algorithms defined in Section 2.2.3 of [RFC8976]. Non-negotiable, periodt 💀.
  • A high-entropy salt, up to 255 octets 🧂.

If the local encrypted resolver is identified by name (for example, using DNR), that identifying name MUST be the name used in any matching authorization claim. Otherwise (for example, DDR using IP addresses), the resolver MUST present a validatable certificate with a subjectAltName that matches the authorization claim, using the validation techniques for matching described in [RFC9525] 🔐.

Next, the network hands each authorization claim to the parent zone operator. If the contents are approved, the parent zone operator computes a "Verification Token" using this procedure 🧮:

  1. Convert all subdomains into canonical form and sort them in canonical order (Section 6 of [RFC4034]).
  2. Replace the suffix corresponding to the parent zone with a zero octet.
  3. Let $X be the concatenation of the resulting pseudo-FQDNs.
  4. Let len($SALT) be the number of octets of salt, as a single octet.
  5. Let $TOKEN = hash(len($SALT) || $SALT || $X), where || denotes concatenation and hash is the ZONEMD Hash Algorithm.

Then the zone operator publishes a "Verification Record" with the structure below, following the best practices in Sections 5.2 and 5.3 of [DOMAIN-VERIFICATION-TECHNIQUES] ✨:

  • Type = TXT
  • Owner Name = Concatenation of the ADN, "_splitdns-challenge", and the parent zone name
  • Contents = "key/value" pairs, e.g., "token=base64url($TOKEN)" (without padding)

Publishing this record is how the parent zone says "yep, this resolver can serve these subdomains authoritatively" 👑.

5.1. Example

Let's look at a worked example 🦋. Consider this authorization claim:

  • ADN = "resolver17.parent.example"
  • Parent = "parent.example"
  • Subdomains = "payroll.parent.example", "secret.project.parent.example"
  • Hash Algorithm = SHA-384 [RFC6234]
  • Salt = "example salt octets (should be random)"

To approve this claim, the zone operator would publish the following record:

NOTE: '' line wrapping per RFC 8792

  resolver17.parent.example._splitdns-challenge.parent.example. \
  IN TXT "token=z1qyK7QWwQPkT-ZmVW-tAQbsNyYenTNBPp5ogYB8S1wesVCR\
  -KJDv2eFwfJcWQM"

5.2. Conveying Authorization Claims

Here's the thing: the authorization claim is just an abstract structure, so it has to be encoded in some concrete syntax before it can travel from the network to the client 📦. This section defines some of those encodings 🌸.

5.2.1. Using DHCP

In DHCP, each authorization claim is encoded as a DHCP Authentication option ([RFC3118] and Section 21.11 of [RFC8415]), using the Protocol value 4, "Split-horizon DNS" 🧚. In DHCPv4 [RFC2131], the mechanism for splitting long options described in Section 8 of [RFC3396] MUST be used if the Authentication option exceeds the maximum DHCPv4 option size of 255 octets. The Algorithm field holds the ZONEMD Hash Algorithm, represented by its registered Value. The Replay Detection Method value MUST be 0x00. The Authentication Information MUST contain the following information, concatenated:

  1. The ADN in canonical form.
  2. The parent name in canonical form.
  3. A one-octet "salt length" field.
  4. The salt value.
  5. The $X value as defined in Section 5.

5.2.2. Using Provisioning Domains

When using PvDs [RFC8801], the authorization claims are represented by the PvD Additional Information key "splitDnsClaims", whose value is a JSON array 🍓. Each entry in the array MUST be a JSON object with the following structure:

  • "resolver": The ADN as a dot-separated name.
  • "parent": The parent zone name as a dot-separated name.
  • "subdomains": An array containing the claimed subdomains, as dot-separated names with the parent suffix already removed, in canonical order. To claim the entire parent zone, the claimed subdomain is written as an asterisk symbol ("*").
  • "algorithm": The hash algorithm, represented by its "Mnemonic" string from the "ZONEMD Hash Algorithms" registry (Section 5.3 of [RFC8976]).
  • "salt": The salt, encoded in base64url [RFC4648].

Future specifications that want to define new keys will need to add them to the IANA registry defined in Section 13.3. DNS client implementations will ignore any keys they don't recognize, but they may also report unknown keys 🙈.

6. Validating Authority over Local Domain Hints 🔍

Time to check the receipts 🧾. To validate an authorization claim the network provided, DNS clients MUST resolve the Verification Record for that name. If the resolution produces an RRset containing the expected token for this claim, the client SHALL regard the named resolver as authoritative for the claimed subdomains 👑. Clients MUST ignore any unrecognized keys in the Verification Record.

Each validation of authority applies only to a specific ADN. If a network offers multiple encrypted resolvers, each claimed subdomain may be authorized for a distinct subset of the network-provided resolvers 🌈.

A zone is termed a "Validated Split-Horizon zone" after successful validation using a "tamperproof" DNS resolution method, meaning a method that the local network operator can't interfere with 🛡️. Two possible tamperproof resolution methods are presented below.

6.1. Using a Preconfigured External Resolver

This method only applies if the client is already configured with a default resolution strategy that sends queries to a resolver outside of the network over an encrypted transport 🚀. That strategy counts as tamperproof because anyone who could modify the response could already modify all of the user's other DNS responses, so it's not like this adds a new weak spot. If the client can't get a response from the external resolver within a reasonable timeframe, it MUST consider the verification process to have failed ⏰.

To make sure this assumption holds, clients MUST NOT relax the acceptance rules they would otherwise apply when using this resolver 🙅‍♀️. For example, if the client would check the Authenticated Data (AD) bit or validate RRSIGs locally when using this resolver, it must also do so when resolving TXT records for this purpose. The client MAY perform DNSSEC validation for the verification query even if it has disabled DNSSEC validation for other DNS queries 💜.

6.2. Using DNSSEC

The client resolves the Verification Record using any resolution method it likes (for example, querying one of the network-provided resolvers, or doing iterative resolution locally), then performs full DNSSEC validation locally [RFC6698] 🧐. The result is processed based on its DNSSEC validation state (Section 4.3 of [RFC4035]):

  • Secure: The response is used for validation. ✅
  • Bogus or Indeterminate: The response is rejected, and validation is considered to have failed. ❌
  • Insecure: The client SHOULD retry the validation process using a different method, such as the method described in Section 6.1, to make sure it works with unsigned names 🥺. If the client chooses not to retry (for example, there's no configured policy to validate the authorization claim using an external resolver), it MUST consider validation to have failed.

7. Delegating DNSSEC Across Split DNS Boundaries 🦋

okay so bestie, this is the part where we figure out how DNSSEC works when the local zone and the public zone are not the same thing 🧚 when the local zone can be signed with globally trusted keys for the parent zone, life is easy. you just put a zone cut at the parent zone and drop a suitable DS record in there for the local resolver's DNSKEY. zones set up this way look exactly the same to validating stubs whether or not they implement this specification. no drama, no cap 💅

but what if the local resolver doesn't have keys that are valid for the parent zone? 🙈 we don't want it holding DNSSEC private keys for the parent, that would be a whole mess. so parent zones MAY add a ds=... key to the Verification Record. the value is the RDATA of a single DS record, encoded in base64url. that DS record authorizes a DNSKEY whose owner name is resolver.arpa. ✨ iconic, right?

here's how the client validates it. first it fetches and validates the Verification Record. if that's valid and has a ds key, the client MAY send a DNSKEY query for resolver.arpa. to the local encrypted resolver. at least one resulting DNSKEY Resource Record (RR) MUST match the DS RDATA from the ds key in the Verification Record. and all local resolution results for subdomains in this claim MUST offer RRSIGs that chain to a DNSKEY whose RDATA is identical to one of these approved DNSKEYs. very strict, very serious, very giving 👑

the ds key MAY show up multiple times in a single Verification Record, so you can authorize multiple DNSKEYs for this local encrypted resolver. 🌈

💀 heads up: if the local resolver does NOT have a globally trusted DNSKEY, then any claimed subdomains MUST be marked as unsigned in the public DNS. otherwise validating stubs that don't implement this spec will reject the local resolution results. no one wants that. 😭

here's the example zone setup from the RFC. it's a lot but we're gonna vibe through it 🎀

   ;; Parent zone.
   $ORIGIN parent.example.

   ; Parent zone's public Key Signing Key (KSK)
   ; and Zone Signing Key (ZSK).
   @ IN DNSKEY 257 3 5 ABCD...=
   @ IN DNSKEY 256 3 5 DCBA...=

   ; Verification Record containing DS RDATA for the local
   ; resolver's KSK.  This is an ordinary public TXT record,
   ; secured by RRSIGs from the public ZSK.
   resolver.example._splitdns-challenge IN TXT "token=abc...,ds=QWE..."

   ; NSEC record indicating that unsigned delegations are permitted at
   ; this subdomain.  This is required for compatibility with
   ; non-split-aware validating stub resolvers.  If the claimed label is
   ; confidential, the parent zone can conceal it using NSEC3 (with or
   ; without "opt-out").
   @ IN NSEC subdomain.parent.example. NS

   ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

   ;; Local zone, claiming "subdomain.parent.example".

   ; The local resolver's KSK, validated by the Verification Record.
   ; It may not have a corresponding RRSIG.
   resolver.arpa. IN DNSKEY 257 3 5 ASDF...=

   ; Each claimed subdomain duplicates the local resolver's KSK at its
   ; zone apex and uses it to sign the ZSK.
   subdomain.parent.example.        IN DNSKEY 257 3 5 ASDF...=
   subdomain.parent.example.        IN DNSKEY 256 3 5 FDSA...=
   subdomain.parent.example         IN RRSIG DNSKEY 5 3 ...  \
           (KSK key tag) subdomain.parent.example. ...
   subdomain.parent.example.        IN AAAA 2001:db8::17
   subdomain.parent.example         IN RRSIG AAAA 5 3 ...    \
           (ZSK key tag) subdomain.parent.example. ...
   deeper.subdomain.parent.example. IN AAAA 2001:db8::18
   deeper.subdomain.parent.example  IN RRSIG AAAA 5 3 ...    \
           (ZSK key tag) subdomain.parent.example. ...

                     Figure 1: Example Use of "ds=..."

8. Example Split-Horizon DNS Configuration 🍓

okay so now we get to see it in action! 🎀 picture an org that runs "example.com" and also has a different version of its global domain on its internal network. main character energy, honestly 🌸

first things first, the host and network both need to support one of the discovery mechanisms from Section 5. Figure 2 shows discovery using info from the DNR and the PvD. then validation happens using either an external resolver (Section 8.1) or DNSSEC (Section 8.2). ✨

Steps 1-2: the client figures out the network's DNS server (dns.example.net) and PvD ID (pvd.example.com) using DNR and a PvD, along with one of these: DNR Router Solicitation, DHCPv4, or DHCPv6. 💖

Steps 3-5: the client connects to dns.example.net over an encrypted transport, as indicated in DNR [RFC9463], and authenticates the server to its name using TLS (Section 8 of [RFC8310]). then it sends a query for the address of pvd.example.com. 🫶

Steps 6-7: the client connects to the PvD server, validates its certificate, and grabs the PvD Additional Information indicated by the associated PvD. the JSON object looks like this 👑

      {
        "identifier": "pvd.example.com",
        "expires": "2025-05-23T06:00:00Z",
        "prefixes": ["2001:db8:1::/48", "2001:db8:4::/48"],
        "splitDnsClaims": [{
          "resolver": "dns.example.net",
          "parent": "example.com",
          "subdomains": ["*"],
          "algorithm": "SHA384",
          "salt": "abc...123"
        }]
      }

the JSON keys identifier, expires, and prefixes are defined in [RFC8801]. ✨

   +---------+         +--------------------+  +------------+ +--------+
   | Client  |         | Network's          |  | Network    | | Router |
   |         |         | Encrypted Resolver |  | PvD Server | |        |
   +---------+         +--------------------+  +------------+ +--------+
      |                                     |         |            |
      | Router Solicitation or              |         |            |
      | DHCPv4/DHCPv6 (1)                   |         |            |
      |----------------------------------------------------------->|
      |                                     |         |            |
      |  Response with DNR ADN &            |         |            |
      |  PvD FQDN (2)                       |         |            |
      |<-----------------------------------------------------------|
      | ----------------------------\       |         |            |
      |-| now knows DNR ADN &       |       |         |            |
      | | PvD FQDN                  |       |         |            |
      | |---------------------------/       |         |            |
      |                                     |         |            |
      | TLS connection to dns.example.net (3)         |            |
      |------------------------------------>|         |            |
      | ---------------------------\        |         |            |
      |-| validate TLS certificate |        |         |            |
      | |--------------------------/        |         |            |
      |                                     |         |            |
      | resolve pvd.example.com (4)         |         |            |
      |------------------------------------>|         |            |
      |                                     |         |            |
      |            A or AAAA records (5)    |         |            |
      |<------------------------------------|         |            |
      |                                     |         |            |
      | https://pvd.example.com/.well-known/pvd (6)   |            |
      |---------------------------------------------->|            |
      |                                     |         |            |
      |  200 OK (JSON Additional Information) (7)     |            |
      |<----------------------------------------------|            |
      | ----------------------------------\ |         |            |
      |-| {..., "splitDnsClaims": [...] } | |         |            |
      | |---------------------------------/ |         |            |

       Figure 2: An Example of Learning Local Claims of DNS Authority

8.1. Verification Using an External Resolver 🌈

Figure 3 shows the steps for verifying the local claims of DNS authority using an external resolver. let's gooo 🚀

Steps 1-2: the client uses an encrypted DNS connection to an external resolver to send TXT queries for the Verification Records. the TXT lookup returns a token that matches the claim. 💜

Step 3: the client has validated that example.com has authorized dns.example.net to serve example.com. when the client connects using an encrypted transport as indicated in DNR [RFC9463], it authenticates the server to its name using TLS (Section 8 of [RFC8310]) and sends queries to resolve any names inside the claimed zones. 🦋

   +---------+                  +--------------------+  +----------+
   | Client  |                  | Network's          |  | External |
   |         |                  | Encrypted Resolver |  | Resolver |
   +---------+                  +--------------------+  +----------+
        |                                          |         |
        | TLS connection                           |         |
        |--------------------------------------------------->|
        | ---------------------------\             |         |
        |-| validate TLS certificate |             |         |
        | |--------------------------|             |         |
        |                                          |         |
        | TXT? dns.example.net.\                   |         |
        |   _splitdns-challenge.example.com (1)    |         |
        |--------------------------------------------------->|
        |                                          |         |
        |  TXT "token=ABC..." (2)                  |         |
        |<---------------------------------------------------|
        | --------------------------------\        |         |
        |-| dns.example.net is authorized |        |         |
        | ----------------------\---------|        |         |
        |-| finished validation |                  |         |
        | |---------------------|                  |         |
        |                                          |         |
        |  use dns.example.net when                |         |
        |  resolving example.com (3)               |         |
        |----------------------------------------->|         |
        |                                          |         |

           Figure 3: Verifying Claims Using an External Resolver

8.2. Verification Using DNSSEC 🔐✨

okay so, Figure 4 walks through how you check the local claims of DNS authority using DNSSEC, and it's giving careful but make it cute 🎀

Steps 1-2: the DNSSEC-validating client asks the network's encrypted resolver for TXT records at the Verification Records 🫶 The TXT answer comes back signed and contains the expected token. Then the client does the full DNSSEC validation itself, locally, no shortcuts bestie 💅

Step 3: if the DNSSEC validation works and the token matches, the authorization claim is validated 🎉 Then, once the client connects over an encrypted transport as DNR [RFC9463] says, it authenticates the server against its name using TLS (Section 8 of [RFC8310]) and sends queries for any names inside the claimed zones. Main character energy ✨

+---------+                                    +--------------------+
| Client  |                                    | Network's          |
|         |                                    | Encrypted Resolver |
+---------+                                    +--------------------+
  |                                                               |
  | DNSSEC OK (DO), TXT? dns.example.net.\                        |
  |   _splitdns-challenge.example.com (1)                         |
  |-------------------------------------------------------------->|
  |                                                               |
  | TXT token=DEF..., Signed Answer (RRSIG) (2)                   |
  |<--------------------------------------------------------------|
  | -------------------------------------\                        |
  |-| DNSKEY+TXT matches RRSIG, use TXT  |                        |
  | |------------------------------------|                        |
  | --------------------------------\                             |
  |-| dns.example.net is authorized |                             |
  | |-------------------------------|                             |
  | ----------------------\                                       |
  |-| finished validation |                                       |
  | |---------------------|                                       |
  |                                                               |
  | use encrypted network-designated resolver for example.com (3) |
  |-------------------------------------------------------------->|
  |                                                               |

Figure 4: An Example of Verifying Claims Using DNSSEC 📊

9. Operational Efficiency in Split-Horizon Deployments 🌸

in lots of split-horizon setups, all the non-public names get tucked into a separate child zone (like internal.example.com) 🦋 The message flow is basically the same as in Section 8.1, except queries for hosts outside that subdomain (like www.example.com) go to the external resolver instead of the resolver for internal.example.com.

As Section 8.1 says, the internal DNS server needs a certificate signed by a Certification Authority (CA) that the client trusts 🔐

Putting internal domains in a child domain isn't required to stop leaks 🙅‍♀️ but it does cut down how often the Verification Record has to change, which is so smart 🧠✨ This document recommends keeping internal domains in a child zone of the local domain hints the network advertises. For example, if the PvD "dnsZones" entry is "internal.example.com" and the network-provided DNS resolver is "ns1.internal.example.com", the network operator can name internal domains "private1.internal.example.com", "private2.internal.example.com", and so on 🧚 The network-designated resolver gets used to resolve subdomains of the local domain hint "*.internal.example.com" 💜

10. Validation with IKEv2 🔑

when the endpoint is on a VPN tunnel and that tunnel is IPsec, the encrypted DNS resolver hosted by the VPN provider can be discovered securely by the endpoint, using the ENCDNS_IP* IKEv2 Configuration Payload Attribute Types defined in [RFC9464] 💖 The VPN client can use the mechanism from Section 6 to check that the discovered encrypted DNS resolver is authorized to answer for the claimed subdomains.

Other VPN tunnel types have similar configuration abilities 🌈 but this document doesn't talk about those, so we're leaving them alone 🤷‍♀️

11. Authorization Claim Update 🔄

A Verification Record is only valid until it expires 💀 Expiry happens when the Time To Live (TTL) or the DNSSEC signature validity period ends. Shortly before a Verification Record expires, clients MUST fetch the Verification Records again and repeat the verification procedure. This keeps updated, valid Verification Records available, so nobody gets caught with stale records 😭

A new Verification Record must be added to the RRset before the matching authorization claim gets updated. After the claim is updated, these procedures can be used:

  1. DHCP reconfiguration can be started by a DHCP server that has already talked to a DHCP client and negotiated for that client to listen for Reconfigure messages. The server prompts the client to dynamically request the updated authorization claim 📮 This means the client doesn't have to wait for its current lease to finish and then ask for a new one, so the server drives the lease renewal itself 🎯
  2. The sequence number in the RA PvD Option can be incremented, which makes clients fetch PvD Additional Information from the HTTPS server because the sequence number changed in the new RA (Section 4.1 of [RFC8801]) 🚀
  3. The old Verification Record needs to stick around until the DHCP lease or the PvD Additional Information expires 🕰️

12. Security Considerations 🛡️

okay, serious moment incoming 🚨 The ADNs of authorized local encrypted resolvers are revealed in the owner names of Verification Records. This makes it easier for domain owners to see which resolvers they're currently authorizing for split DNS 👀 But this could create a confidentiality issue if the local encrypted resolver's name holds sensitive info or is part of a secret subdomain 😱 To soften the blow of that leak, local resolvers should get names that don't reveal anything sensitive 🤫

The security properties of hashing algorithms aren't fixed, so algorithm agility (see [RFC7696]) is the move 🔁 It's achieved by letting implementations choose hashing algorithms from the "ZONEMD Hash Algorithms" registry (Section 5.3 of [RFC8976]) 💅

The entropy of a salt depends on a high-quality pseudorandom number generator 🎲 For more on random number generation, see [RFC4086]. The salt MUST be regenerated whenever the authorization claim is updated 🧂✨

13. IANA Considerations 📋

13.1. New DHCP Authentication Algorithm for Split DNS 🎀

IANA added the following entry to the "Protocol Name Space Values" registry in the "Dynamic Host Configuration Protocol (DHCP) Authentication Option Name Spaces" registry group:

Value:  4

Description:  Split-horizon DNS

Reference:  RFC 9704

13.2. New PvD Additional Information Type for Split DNS 🌟

IANA added the following entry to the "Additional Information PvD Keys" registry in the "Provisioning Domains (PvDs)" registry group:

JSON key:  splitDnsClaims

Description:  Verifiable locally served domains

Type:  Array of Objects

Example:
   [{
     "resolver": "dns.example.net",
     "parent": "example.com",
     "subdomains": ["sub"],
     "algorithm": "SHA384",
     "salt": "abc...123"
   }]

Reference:  RFC 9704

13.3. New PvD Split DNS Claims Registry 🍓

IANA created a new registry called "PvD Split DNS Claims" within the "Provisioning Domains (PvDs)" registry group 🧁 This registry reserves JSON keys for use in sub-dictionaries under the splitDnsClaims JSON key. The initial contents, as discussed in Section 5.2.2, are listed below and have been added to the registry:

+==========+================+=======+===================+=========+
|JSON key  | Description    |Type   | Example           |Reference|
+==========+================+=======+===================+=========+
|resolver  | The            |String | "dns.example.net" |RFC 9704 |
|          | Authentication |       |                   |         |
|          | Domain Name    |       |                   |         |
+----------+----------------+-------+-------------------+---------+
|parent    | The parent     |String | "example.com"     |RFC 9704 |
|          | zone name      |       |                   |         |
+----------+----------------+-------+-------------------+---------+
|subdomains| An array       |Array  | ["sub"]           |RFC 9704 |
|          | containing the |of     |                   |         |
|          | claimed        |Strings|                   |         |
|          | subdomains     |       |                   |         |
+----------+----------------+-------+-------------------+---------+
|algorithm | The hash       |String | "SHA384"          |RFC 9704 |
|          | algorithm      |       |                   |         |
+----------+----------------+-------+-------------------+---------+
|salt      | The salt       |String | "abc...123"       |RFC 9704 |
|          | (base64url)    |       |                   |         |
+----------+----------------+-------+-------------------+---------+

                     Table 1: Split DNS Claims

The keys defined in this document are mandatory. Any new key assignments will be considered optional for the purpose of the mechanism described in this document 🙌

New assignments in the "PvD Split DNS Claims" registry will be administered by IANA through Expert Review [RFC8126]. Experts are requested to make sure that defined keys don't overlap in names or semantics 🔍

13.3.1. Guidelines for the Designated Experts 🧐

It is suggested that multiple designated experts be appointed for registry change requests 👯‍♀️

Criteria the designated experts should apply include determining whether the proposed registration duplicates existing entries, and whether the registration description is clear and fits the purpose of this registry 📝

Registration requests are evaluated within a three-week review period, on the advice of one or more designated experts. Within that review period, the designated experts will either approve or deny the request and communicate the decision to IANA ⏳ Denials should include an explanation and, if applicable, suggestions for how to make the request successful 💡

13.4. DNS Underscore Name 🌷

IANA added the following entry to the "Underscored and Globally Scoped DNS Node Names" registry in the "Domain Name System (DNS) Parameters" registry group:

RR Type:  TXT

_NODE NAME:  _splitdns-challenge

Reference:  RFC 9704

14. References 📚

14.1. Normative References

okay bestie, this is the reading list the spec leans on hardest 📚💅 every one of these is basically load-bearing, so here's the full lineup, details and all:

14.2. Informative References

these ones are the helpful sidekicks 🧚 not strictly required reading, but super worth a look if you want the full picture:

Acknowledgements

big thank-yous to everyone who helped make this happen 🫶

Thanks to Mohamed Boucadair, Jim Reid, Tommy Pauly, Paul Vixie, Michael Richardson, Bernie Volz, Éric Vyncke, and Vinny Parla for the discussion and comments. 💜

Thanks to Tianran Zhou for the opsdir review, Anthony Somerset for the dnsdir review, Watson Ladd for the secdir review, Bob Halley for the intdir review, and Mallory Knodel for the genart review. 🌈

Thanks to Mohamed Boucadair for the Shepherd review. 👑

Authors' Addresses

meet the squad who wrote it 💖

  • Tirumaleswar Reddy.K
  • Nokia
  • India
  • Email: kondtir@gmail.com 🧚
  • Dan Wing
  • Citrix Systems, Inc.
  • United States of America
  • Email: danwing@gmail.com 🦋
  • Kevin Smith
  • Vodafone Group
  • One Kingdom Street
  • London
  • United Kingdom
  • Email: kevin.smith@vodafone.com 🌸
  • Benjamin Schwartz
  • Meta Platforms, Inc.
  • Email: ietf@bemasc.net 💅
📦 where this page comes from