RFC 8310

Usage Profiles for DNS over TLS and DNS over DTLS

📅 published March 2018, from ietf

RFC 8310: Usage Profiles for DNS over TLS and DNS over DTLS 🎀

okay bestie, this is RFC 8310, and it's giving "how to keep DNS private without breaking everything" 🦋 It's from March 2018 and the authors are S. Dickinson (Sinodun), D. Gillmor (ACLU), and T. Reddy (McAfee). It's a Standards Track document, which means it's an actual Internet standard and not just an idea 💅 The ISSN is 2070-1721. It updates RFC 7858 ✨ and the header has no Obsoletes line, so it doesn't obsolete anything 🌸

Abstract

okay so the abstract says this doc talks about usage profiles 💖 A usage profile is a set of rules for how a client uses one or more authentication mechanisms when it runs DNS over Transport Layer Security (TLS), or over Datagram TLS (DTLS) 🧚 Using these profiles can make DNS transactions more private than plain old cleartext DNS 🔒

The doc also brings in new authentication mechanisms 🔥 It describes several ways a DNS client can use an authentication domain name to check a (D)TLS connection to a DNS server. On top of that, it defines a (D)TLS protocol profile for DNS clients and servers that do DNS over (D)TLS 👑 And again, it updates RFC 7858 🫶

Status of This Memo

this section just says it's an Internet Standards Track document 📜 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) ✨ If you want more on Internet Standards, check Section 2 of RFC 7841 💜

The current status, any errata, and feedback info live at https://www.rfc-editor.org/info/rfc8310 🎀

the copyright is Copyright (c) 2018 IETF Trust and the persons identified as the document authors, all rights reserved 💅 The doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents, which you can find at https://trustee.ietf.org/license-info as of the publication date 📚 Read those carefully, bestie, because they cover your rights and restrictions 🙈

Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions. They're provided without warranty, as described in the Simplified BSD License 💖

Table of Contents

1. Introduction ....................................................4
2. Terminology .....................................................6
3. Scope ...........................................................7
4. Discussion ......................................................8
5. Usage Profiles ..................................................8
   5.1. DNS Resolution ............................................11
6. Authentication in DNS over (D)TLS ..............................11
   6.1. DNS-over-(D)TLS Startup Configuration Problems ............11
   6.2. Credential Verification ...................................12
   6.3. Summary of Authentication Mechanisms ......................12
   6.4. Combining Authentication Mechanisms .......................15
   6.5. Authentication in Opportunistic Privacy ...................15
   6.6. Authentication in Strict Privacy ..........................16
   6.7. Implementation Guidance ...................................16
7. Sources of Authentication Domain Names .........................17
   7.1. Full Direct Configuration .................................17
   7.2. Direct Configuration of ADN Only ..........................17
   7.3. Dynamic Discovery of ADN ..................................17
        7.3.1. DHCP ...............................................18
8. Credential Verification Based on Authentication Domain Name ....18
   8.1. Authentication Based on PKIX Certificate ..................18
   8.2. DANE ......................................................19
        8.2.1. Direct DNS Meta-Queries ............................20
        8.2.2. TLS DNSSEC Chain Extension .........................20
9. (D)TLS Protocol Profile ........................................20
10. IANA Considerations ...........................................21
11. Security Considerations .......................................21
   11.1. Countermeasures to DNS Traffic Analysis ..................22
12. References ....................................................22
   12.1. Normative References .....................................22
   12.2. Informative References ...................................24
Appendix A. Server Capability Probing and Caching by DNS Clients ..26
Acknowledgments ...................................................27
Authors' Addresses ................................................27

1. Introduction ✨

okay so DNS privacy problems are discussed in [RFC7626] 🔍 The specific issues from [RFC7626] that matter most here are:

  • Passive attacks that eavesdrop on cleartext DNS transactions on the wire (Section 2.4 of [RFC7626]) and
  • Active attacks that redirect clients to rogue servers to monitor DNS traffic (Section 2.5.3 of [RFC7626]).

Fixing these attacks makes DNS transactions more private 🦋 Plenty of the other issues from [RFC7626] still apply though, so this isn't a magic fix 💀

Two documents give ways to increase DNS privacy between DNS clients and DNS servers 💜

  • "Specification for DNS over Transport Layer Security (TLS)" [RFC7858], which this doc just calls "DNS over TLS".
  • "DNS over Datagram Transport Layer Security (DTLS)" [RFC8094], which this doc just calls "DNS over DTLS". Heads up, [RFC8094] is an Experimental specification 🧪

Both of those only cover communication between stub clients and recursive resolvers, and this document keeps that same scope (see Sections 2 and 3) 🌸 The proposals here might be adapted or extended later for recursive clients and authoritative servers. But that was out of scope for the DNS PRIVate Exchange (dprive) Working Group charter when this doc was published 🙈

This document specifies two usage profiles, Strict Privacy and Opportunistic Privacy, for DTLS [RFC6347] and TLS [RFC5246] 🔥 They give better mitigation for the attacks above than plain cleartext DNS does 👑

Section 5 gives a general discussion of usage profiles 🎀 It separates the usage profile, which is based purely on the security properties it gives the user, from the specific mechanism (or mechanisms) used for DNS server authentication 💅 The profiles are:

  • A Strict Privacy profile, which requires an encrypted connection and successful authentication of the DNS server. This mitigates both passive eavesdropping and client redirection, at the cost of providing no DNS service if an encrypted, authenticated connection isn't available ⭐
  • An Opportunistic Privacy profile, which will attempt encryption and successful authentication but does not require them. So it gives limited or no mitigation for those attacks, but it maximizes the chance of getting DNS service 🍓

Both usage profiles try to authenticate the server with at least one authentication mechanism 🫶 Section 6.4 talks about how to combine mechanisms to get the overall authentication result 🧚 Based on that overall result (and on whether encryption is available), the usage profile decides whether the connection should proceed, fall back, or fail 💖

One authentication mechanism is already described in [RFC7858] ✨ [RFC7858] specifies an authentication mechanism for DNS over TLS based on Subject Public Key Info (SPKI), in the specific case of a Strict Privacy profile that uses that one mechanism 🌈 So the "out-of-band key-pinned privacy profile" from [RFC7858] would count as a "Strict Privacy profile" that uses SPKI pinning for authentication 🔐

This document extends SPKI pin set authentication so it's a general mechanism that works with either DNS-over-(D)TLS usage profile 🦋 In other words, the SPKI pin set mechanism from [RFC7858] MAY be used with DNS over (D)TLS 🎀

This document also describes a bunch more authentication mechanisms 💜 All of them explain how a DNS client should authenticate a DNS server based on an "authentication domain name". Specifically, the doc covers:

  • How a DNS client can get the combo of an authentication domain name and IP address for a DNS server. See Section 7 🗺️
  • What acceptable credentials a DNS server can present to prove its identity for (D)TLS authentication based on a given authentication domain name. See Section 8 🪪
  • How a DNS client can check that a given credential matches the authentication domain name it got for a DNS server. See Section 8 🔎

Last but not least, this doc defines a (D)TLS protocol profile for DNS, see Section 9 👑 The profile sets the configuration options and protocol extensions that both parties need in order to (1) speed up connection setup and session resumption for carrying DNS, and (2) support all currently specified authentication mechanisms 💅 Part 1 of 5, bestie, and we're just getting started 🔥

2. Terminology 💖

okay bestie, first the official key words. "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" mean what BCP 14 [RFC2119] [RFC8174] says they mean, but ONLY when they're written in ALL CAPS like that. 🙈 lowercase versions are just regular words, no cap 💅

Now some terms that this doc uses in a very specific way ✨

  • DNS client 💁‍♀️: A DNS stub resolver or forwarder. If it's a forwarder, "DNS client" refers to the side that sends the queries.
  • DNS server 🏠: A DNS recursive resolver or forwarder. If it's a forwarder, "DNS server" refers to the side that answers the queries. Heads up, this doesn't include authoritative servers 🙅‍♀️
  • Privacy-enabling DNS server 🔐: A DNS server that does DNS over TLS [RFC7858] and may optionally do DNS over DTLS [RFC8094]. It should also offer at least one of the credentials from Section 8 and implement the (D)TLS profile from Section 9. so main character energy 👑
  • (D)TLS 🎀: Just shorthand for both Transport Layer Security [RFC5246] and Datagram Transport Layer Security [RFC6347]. When something only applies to one of them, the doc will say which one.
  • DNS over (D)TLS 🦋: Also shorthand, for both DNS over TLS [RFC7858] and DNS over DTLS [RFC8094]. Same deal, specific names get used when a thing only applies to one.
  • Authentication domain name 🪪: A domain name you can use to authenticate a privacy-enabling DNS server. Where these come from is covered in Section 7.
  • SPKI pin sets 📌: [RFC7858] talks about using cryptographic digests to "pin" public key info, kind of like HTTP Public Key Pinning (HPKP) [RFC7469]. An SPKI pin set is a group of these pins that constrains a DNS server 🧚
  • Authentication information 🗝️: Info a DNS client can use as the basis for an authentication mechanism. In this context it can be either
    • an SPKI pin set or
    • an authentication domain name
  • Reference identifier 🔖: A reference identifier, as described in [RFC6125], that the DNS client builds when it does TLS authentication of a DNS server.
  • Credential 🪄: Info a DNS server has that proves who it is for authentication purposes. The credentials discussed here are
    • a PKIX certificate
    • a DNSSEC-validated chain to a TLSA record

but they can also include SPKI pin sets.

3. Scope 🌸

this doc is only going to cover

  • Usage profiles based on general authentication mechanisms.
  • The details of domain-name-based authentication of DNS servers by DNS clients (as defined in Section 2).
  • The (D)TLS profiles needed to support authentication in DNS over (D)TLS.

and these things are totally out of scope, not my problem here 🙅‍♀️

  • Authentication of authoritative servers by recursive resolvers.
  • Authentication of DNS clients by DNS servers.
  • The details of how to do authentication based on SPKI pin sets. That's defined in [RFC7858].
  • Any server identifier other than domain names, including IP addresses, organizational names, country of origin, etc.

4. Discussion 🧠

one way to stop passive attackers from eavesdropping on cleartext DNS is to encrypt the query (and the response) 🔒 Encryption like that usually gives you integrity protection as a bonus, so on-path attackers can't just inject bogus DNS responses anymore. but to also stop active attackers who are pretending to be the server, the client MUST authenticate the (D)TLS connection to the server. 🫶

this doc talks about usage profiles, which give DNS clients different levels of attack mitigation based on the requirements for authentication and encryption, no matter the context (like which network the client is connected to) 🌐 A usage profile is NOT the same thing as a usage policy or usage model. A usage policy or model might decide which profile should be used in a certain context (enterprise vs. coffee shop ☕), with a certain set of DNS servers, or with reference to other outside factors. Describing all the variety of usage policies is out of scope here, but it could be future work 📚

the term "privacy-enabling DNS server" shows up all over this doc. It's a DNS server that

  • MUST implement DNS over TLS [RFC7858].
  • MAY implement DNS over DTLS [RFC8094].
  • SHOULD offer at least one of the credentials described in Section 8.
  • Implements the (D)TLS profile described in Section 9.

5. Usage Profiles 💅

a DNS client gets to pick from a few usage profiles to boost the privacy of its DNS transactions ✨ Both [RFC7858] and [RFC8094] briefly talk about this choice. Here are the profiles 👇

  • Strict Privacy profile 🛡️: The DNS client REQUIRES an encrypted AND authenticated connection to a privacy-enabling DNS server. If that isn't available, it's a hard failure, no exceptions 💀 This means the client has to securely get authentication information it can use to authenticate the server. This profile protects against both passive and active attacks, so it gives the client the best privacy for DNS available. Section 6.6 goes into this one in detail 🔥
  • Opportunistic Privacy profile 🦋: The DNS client uses Opportunistic Security as described in [RFC7435].
    • "... the use of cleartext as the baseline communication security policy, with encryption and authentication negotiated and applied to the communication when available."

As [RFC7435] describes, this could end up as

  • an encrypted and authenticated connection
  • an encrypted connection
  • a cleartext connection

depending on the client's fallback logic, the authentication info it has, and what the DNS server can do. In every one of these cases the DNS client is fine continuing with the connection to the DNS server and resolving queries 🙌 The point of Opportunistic Privacy is to help privacy roll out gradually, with the bigger goal of everyone eventually using Strict Privacy ✨ It SHOULD be used when the DNS client might otherwise settle for cleartext. It gives the most protection available, depending on the combo of factors above. If ALL the configured DNS servers are privacy servers, it can protect against passive attacks and might protect against active ones too 🫧

Both profiles can include an initial meta-query (done using Opportunistic Privacy) to get the IP address of the privacy-enabling DNS server the client will connect to next 🔍 The reason this is allowed for Strict Privacy is that making those meta-queries also use Strict Privacy would create some serious deployment obstacles 🚧 BUT heads up, an active attack on the meta-query IS possible in this case 😬 That attack could make a Strict Privacy client connect to a server it can't authenticate (so no DNS service at all), or make an Opportunistic Privacy client connect to a server the attacker controls. DNSSEC validation can catch the attack on the meta-query, and that might mean the client gets no DNS service (for both profiles), depending on its DNSSEC validation policy. See Section 7.2 for more on this.

To compare the two profiles, Table 1 shows a successful Strict Privacy connection next to the three possible outcomes of an Opportunistic Privacy connection 📊 In the best case for Opportunistic Privacy (an authenticated and encrypted connection), it's the same as Strict Privacy. In the worst case, it's the same as cleartext. Clients using Opportunistic Privacy SHOULD aim for the best case, but MAY fall back to the intermediate case and eventually the worst case, so they can still get a response. One reason to fall back without trying every available privacy-enabling DNS server is if latency matters more than attack mitigation; see Appendix A ⏱️ So Opportunistic Privacy gives varying protection depending on what kind of connection is actually used, and that includes no attack mitigation at all 😭

Quick note: Opportunistic Security does NOT require telling the user what type of connection is actually used. The "detection" described below only works if that connection info is available 🕵️‍♀️ BUT if it IS available and the user is told an unencrypted connection was used to reach a server, then the user should assume (detect) that the connection is open to both active and passive attacks, since the DNS queries went out in cleartext 🚨 This could be super useful if a new connection to a certain server is unencrypted when all the previous connections were encrypted. Same vibe if the user is told an encrypted but unauthenticated connection was used. Then they can detect that the connection might be open to active attacks. So basically, for the cases where no protection is given against an attacker (N), it's possible to detect that an attack might be happening (D). This is discussed in Section 6.5 🫣

    +---------------+------------+------------------+-----------------+
    | Usage Profile | Connection | Passive Attacker | Active Attacker |
    +---------------+------------+------------------+-----------------+
    |     Strict    |    A, E    |        P         |        P        |
    | Opportunistic |    A, E    |        P         |        P        |
    | Opportunistic |     E      |        P         |       N, D      |
    | Opportunistic |            |       N, D       |       N, D      |
    +---------------+------------+------------------+-----------------+

     P == Protection; N == No protection; D == Detection is possible;
         A == Authenticated connection; E == Encrypted connection

     Table 1: Attack Protection by Usage Profile and Type of Attacker

The Strict Privacy profile gives the best attack mitigation, so it MUST... wait, correction bestie, the original says it SHOULD always be implemented in DNS clients that implement the Opportunistic Privacy profile. 💅 So: the Strict Privacy profile gives the best attack mitigation and therefore SHOULD always be implemented in DNS clients that implement the Opportunistic Privacy profile 🏆

A DNS client that does DNS over (D)TLS SHOULD NOT be configured by default to use only cleartext 🚫

Which profile to pick depends on a few factors, including which one matters more to the client 🤔

  • DNS service, at the cost of no attack mitigation (Opportunistic Privacy), or
  • Best available attack mitigation, at the potential cost of no DNS service (Strict Privacy).

On top of that, the two profiles need different levels of configuration (or a trusted relationship with a provider) and different DNS server capabilities, so DNS clients will need to carefully pick which profile fits their communication needs 🧩

A DNS server that does DNS over (D)TLS SHOULD provide at least one credential (Section 2) so the DNS clients that want the Strict Privacy profile can actually use it 🥹🎀

5.1. DNS Resolution 💅

Okay bestie, a DNS client SHOULD pick a usage profile when it resolves a query 💖. It MUST NOT fall back from Strict Privacy to Opportunistic Privacy while resolving a given query, because that could totally wreck the protection against attackers 😭. The plan is that a DNS client sticks with one usage profile for all queries to all of its configured servers, until an operational issue or policy update says it's time to switch 🦋.

6. Authentication in DNS over (D)TLS 🔐

This section is all about authentication, and how it works with Strict or Opportunistic Privacy for DNS over (D)TLS 🫶.

6.1. DNS-over-(D)TLS Startup Configuration Problems 🥺

Lots of (D)TLS clients use PKIX authentication [RFC6125] based on an authentication domain name for the server they're contacting. These clients usually look up the server's network address in the DNS before they make the connection. So a DNS client has a bootstrap problem, because it will typically only know the IP address of its DNS server 🙈.

In this case, before connecting to a DNS server, a DNS client needs to learn the authentication domain name it should associate with that IP address for authentication purposes. Sources of authentication domain names are discussed in Section 7 ✨.

One advantage of this domain-name-based approach is that it encourages stable, human-recognizable identifiers for secure DNS service providers. Iconic 👑.

6.2. Credential Verification 🔍

Verification of SPKI pin sets is discussed in [RFC7858].

When it comes to domain-name-based verification, once an authentication domain name is known for a DNS server, a choice of authentication mechanisms can be used for credential verification. Section 8 goes deep on these mechanisms, namely PKIX certificate-based authentication and DNS-Based Authentication of Named Entities (DANE) 🧚.

Note that using DANE adds requirements on the client's ability to get validated DNSSEC results. This is covered in more detail in Section 8.2 🌸.

6.3. Summary of Authentication Mechanisms 📋

This section gives you an overview of the authentication mechanisms. Table 2 below shows how the DNS client gets the info it uses for authentication for each option: either statically via direct configuration, or dynamically. Of course, the Opportunistic Privacy profile does not require authentication, so a client using that profile may choose to connect to a privacy-enabling DNS server based on just an IP address 🦋.

+---+------------+-------------+------------------------------------+
| # | Static     | Dynamically | Short name: Description            |
|   | Config     | Obtained    |                                    |
+---+------------+-------------+------------------------------------+
| 1 | SPKI + IP  |             | SPKI: SPKI pin set(s) and IP       |
|   |            |             | address obtained out of band       |
|   |            |             | [RFC7858]                          |
|   |            |             |                                    |
| 2 | ADN + IP   |             | ADN: ADN and IP address obtained   |
|   |            |             | out of band (see Section 7.1)      |
|   |            |             |                                    |
| 3 | ADN        | IP          | ADN only: Opportunistic Privacy    |
|   |            |             | meta-queries to a NP DNS server    |
|   |            |             | for A/AAAA (see Section 7.2)       |
|   |            |             |                                    |
| 4 |            | ADN + IP    | DHCP: DHCP configuration only (see |
|   |            |             | Section 7.3.1)                     |
|   |            |             |                                    |
| 5 | [ADN + IP] | [ADN + IP]  | DANE: DNSSEC chain obtained via    |
|   |            | TLSA record | Opportunistic Privacy meta-queries |
|   |            |             | to NP DNS server (see Section      |
|   |            |             | 8.2.1)                             |
|   |            |             |                                    |
| 6 | [ADN + IP] | [ADN + IP]  | TLS extension: DNSSEC chain        |
|   |            | TLSA record | provided by PE DNS server in TLS   |
|   |            |             | DNSSEC chain extension (see        |
|   |            |             | Section 8.2.2)                     |
+---+------------+-------------+------------------------------------+

                SPKI == SPKI pin set(s); IP == IP Address;
        ADN == Authentication Domain Name; NP == Network-Provided;
        PE == Privacy-Enabling; [ ] == Data may be obtained either
                         statically or dynamically

              Table 2: Overview of Authentication Mechanisms

The next bit sums up some key attributes of each mechanism (using the "Short name" from Table 2). Attractive attributes get a +, and the undesirable ones get a - 🍓.

  1. SPKI ✨
    • + Minimal leakage (note that the ADN is always leaked in the Server Name Indication (SNI) field in the ClientHello in TLS when communicating with a privacy-enabling DNS server)
    • - Overhead of ongoing key management required
  2. ADN 🎀
    • + Minimal leakage
    • + One-off direct configuration only
  3. ADN only 🌈
    • + Minimal one-off direct configuration; only a human-recognizable domain name needed
    • - A/AAAA meta-queries leaked to network-provided DNS server that may be subject to active attack (attack can be mitigated by DNSSEC validation)
  4. DHCP 💜
    • + No static config
    • - Requires a non-standard or future DHCP option in order to provide the ADN
    • - Requires secure and trustworthy connection to DHCP server if used with a Strict Privacy profile
  5. DANE 🔥 The ADN and/or IP may be obtained statically or dynamically, and the relevant attributes of that method apply.
    • + DANE options (e.g., matching on entire certificate)
    • - Requires a DNSSEC-validating stub implementation (the deployment of which is limited at the time of this writing)
    • - DNSSEC chain meta-queries leaked to network-provided DNS server that may be subject to active attack
  6. TLS extension 👑 The ADN and/or IP may be obtained statically or dynamically, and the relevant attributes of that method apply.
    • + Reduced latency compared with DANE
    • + No network-provided DNS server required if ADN and IP statically configured
    • + DANE options (e.g., matching on entire certificate)
    • - Requires a DNSSEC-validating stub implementation

6.4. Combining Authentication Mechanisms 🧩

This document doesn't make explicit recommendations about how an SPKI-pin-set-based mechanism should be combined with a domain-based mechanism from an operator's point of view. However, it's easy to picture a DNS server operator wanting to make both an SPKI pin set and an authentication domain name available, so clients can pick which mechanism to use. So the text below gives guidance on how clients ought to behave if they choose to configure both, which HPKP [RFC7469] also allows 💅.

A DNS client that's configured with both an authentication domain name and an SPKI pin set for a DNS server SHOULD match on both a valid credential for the authentication domain name and a valid SPKI pin set (if both are available) when connecting to that DNS server. In this case, the client SHOULD treat individual SPKI pins as specified in Section 2.6 of [RFC7469] with regard to user-defined trust anchors. The overall authentication result SHOULD only be considered successful if both authentication mechanisms are successful ✨.

6.5. Authentication in Opportunistic Privacy 🕵️‍♀️

An Opportunistic Privacy Profile (based on Opportunistic Security [RFC7435]) that MAY be used for DNS over (D)TLS is described in [RFC7858], and this document specifies it further 🦋.

DNS clients that issue queries under an Opportunistic Privacy profile, and that know authentication information for a given privacy-enabling DNS server, SHOULD try to authenticate the server using the mechanisms described here. This is useful for detecting (but not preventing) active attacks, because the fact that authentication info is available tells you the server is a privacy-enabling DNS server it should be possible to reach over an authenticated and encrypted connection. In this case, a client can't know the reason for an authentication failure, but from a security standpoint it should consider an active attack in progress and proceed under that assumption 😭. For example, a client that implements a nameserver selection algorithm which preferentially uses nameservers that successfully authenticated (see Section 5) might stop using the failing server if alternative servers are available 🙈.

Attempting authentication is also useful for debugging or diagnostics, if there are ways to report the result. This info can help a DNS client switch to the (preferred) Strict Privacy profile where it's viable, e.g., where all the configured servers support DNS over (D)TLS and authenticate successfully 🌸.

6.6. Authentication in Strict Privacy 🔒

To authenticate a privacy-enabling DNS server, a DNS client needs to know authentication information for each server it's willing to contact. This is necessary to protect against active attacks that try to redirect clients to rogue DNS servers 💀.

A DNS client requiring Strict Privacy MUST use either (1) one of the sources listed in Section 7 to get an authentication domain name for the server it contacts, or (2) an SPKI pin set as described in [RFC7858].

A DNS client requiring Strict Privacy MUST only attempt to connect to DNS servers for which at least one piece of authentication information is known. The client MUST use the available verification mechanisms described in Section 8 to authenticate the server, and MUST abort connections to a server when no verification mechanism succeeds 🛑.

With Strict Privacy, the DNS client MUST NOT commence sending DNS queries until at least one of the privacy-enabling DNS servers becomes available ⏳.

A privacy-enabling DNS server may be temporarily unavailable when configuring a network. For example, for clients on networks that require registration through web-based login (a.k.a. "captive portals"), that registration may rely on DNS interception and spoofing 🙃. Techniques such as those used by dnssec-trigger [dnssec-trigger] MAY be used during network configuration, with the intent to transition to the designated privacy-enabling DNS servers after captive-portal registration. If using a Strict Privacy profile, the system MUST alert by some means that the DNS is not private during such a bootstrap operation 🚨.

6.7. Implementation Guidance 🛠️

Section 9 describes the (D)TLS profile for DNS over (D)TLS. Additional considerations relating to general implementation guidelines are discussed in both Section 11 and Appendix A 🌟.

7. Sources of Authentication Domain Names 🌈

7.1. Full Direct Configuration 💖

okay so this is the easiest setup of all 🎀 DNS clients can be handed the authentication domain name of every privacy-enabling DNS server directly and securely, like through a client-specific config file or an API ✨

so the whole direct setup is an IP address and an authentication domain name for each server, and both come through an out-of-band mechanism (basically a side channel) 🦋

7.2. Direct Configuration of ADN Only 🌸

a DNS client may be configured directly and securely with just the authentication domain name of each of its privacy-enabling DNS servers, like through a client-specific config file or API 💅

now here's the fun bit 🙈 a DNS client might learn about a default recursive DNS resolver from an untrusted source (like DHCP's DNS Recursive Name Server option [RFC3646]). it can then send meta-queries using an Opportunistic Privacy profile to that untrusted recursive DNS resolver, to figure out the IP address of the intended privacy-enabling DNS resolver by looking up A/AAAA records. a DNSSEC-validating client SHOULD apply the same validation policy to the A/AAAA meta-queries as it does to other queries. a client that does not validate DNSSEC SHOULD apply the same policy (if any) to the A/AAAA meta-queries as it does to other queries. after that, private DNS resolution can happen against the pre-configured privacy-enabling DNS resolver, using the IP address it got from the untrusted DNS resolver. the glow-up is real 🌈

a DNS client that's set up this way and successfully connects to a privacy-enabling DNS server MAY choose to cache the server's host IP addresses locally, so it doesn't have to repeat the meta-query 🧚

7.3. Dynamic Discovery of ADN 🔥

this section covers the general case, where a DNS client discovers both the authentication domain name and the IP address dynamically. as of writing, this isn't possible by any standard means 😭 but a future DHCP extension could (in principle) provide this, so the required security properties of such mechanisms are laid out here 💜

when using a Strict Privacy profile, the dynamic discovery technique used as a source of authentication domain names MUST be considered secure and trustworthy. this requirement does not apply when using an Opportunistic Privacy profile, since that profile comes with its own security expectations ✨

7.3.1. DHCP 🎀

in the typical case today, a DHCP server [RFC2131] [RFC3315] gives you a list of IP addresses for DNS resolvers (see Section 3.8 of [RFC2132]), but it doesn't give you an authentication domain name for the DNS resolver. so most of the authentication methods described here are blocked (all of the ones based on a mechanism with ADN; see Table 2) 🥲

this document doesn't specify or request any DHCP extension to provide authentication domain names. but if one gets developed in future work, the issues outlined in Section 8 of [RFC7227] should be taken into account, and so should the security considerations discussed in Section 23 of [RFC3315] 🫶

this document also doesn't try to describe secured and trusted relationships to DHCP servers, because that's purely a DHCP issue (and still open, as of writing). some implementation work is in progress to secure IPv6 connections for DHCP, while IPv4 connections have gotten little or no implementation attention in this area 🍓

8. Credential Verification Based on Authentication Domain Name ✨

8.1. Authentication Based on PKIX Certificate 🦋

when a DNS client configured with an authentication domain name connects to its configured DNS server over (D)TLS, the server may present a PKIX certificate. to make sure authentication is actually proper, DNS clients MUST verify the entire certification path per [RFC5280]. the DNS client also uses the validation techniques in [RFC6125] to compare the domain name against the certificate it was given 👑

a DNS client builds one reference identifier for the server from the authentication domain name: a DNS-ID, which is simply the authentication domain name itself 💖

if the reference identifier is found (as described in Section 6 of [RFC6125]) in the PKIX certificate's subjectAltName extension, the DNS client should accept the certificate for the server ✨

a compliant DNS client MUST only inspect the certificate's subjectAltName extension for the reference identifier. in particular, it MUST NOT inspect the Subject field itself 🙅‍♀️

8.2. DANE 🔐

DANE [RFC6698] provides various mechanisms that use DNSSEC to anchor trust for certificates and raw public keys. however, this requires the DNS client to have an authentication domain name (which must be obtained via a trusted source) for the DNS privacy server 🧐

this section assumes you already have a solid understanding of both DANE [RFC6698] and DANE operations [RFC7671]. a few pertinent issues covered in those docs are outlined here as handy pointers, but being familiar with both of them in their entirety is expected 📚

note that [RFC6698] says:

Clients that validate the DNSSEC signatures themselves MUST use standard DNSSEC validation procedures. Clients that rely on another entity to perform the DNSSEC signature validation MUST use a secure mechanism between themselves and the validator.

note that [RFC7671] covers the following topics:

  • Sections 4.1 ("Opportunistic Security and PKIX Usages") and 14 ("Security Considerations") of [RFC7671], which both discuss the use of schemes based on trust anchors and end entities (PKIX-TA(0) and PKIX-EE(1), respectively) for Opportunistic Security.
  • Section 5 ("Certificate-Usage-Specific DANE Updates and Guidelines") of [RFC7671] -- specifically, Section 5.1 of [RFC7671], which outlines the combination of certificate usage DANE-EE(3) and selector SPKI(1) with raw public keys [RFC7250]. Section 5.1 of [RFC7671] also discusses the security implications of this mode; for example, it discusses key lifetimes and specifies that validity period enforcement is based solely on the TLSA RRset properties for this case.
  • Section 13 ("Operational Considerations") of [RFC7671], which discusses TLSA TTLs and signature validity periods.

the specific DANE record for a DNS privacy server would take the form:

_853._tcp.[authentication-domain-name] for TLS

_853._udp.[authentication-domain-name] for DTLS

8.2.1. Direct DNS Meta-Queries 🔍

the DNS client MAY choose to perform the DNS meta-queries to retrieve the required DANE records itself. the DNS meta-queries for those DANE records MAY use the Opportunistic Privacy profile or be in the clear, to avoid trust recursion 🌀 the records MUST be validated using DNSSEC as described in [RFC6698] 🫶

8.2.2. TLS DNSSEC Chain Extension 🔗

the DNS client MAY offer the TLS extension described in [TLS-DNSSEC-Chain-Ext]. if the DNS server supports this extension, it can provide the full chain to the client in the handshake 🤝

if the DNS client offers the TLS DNSSEC chain extension, it MUST be capable of validating the full DNSSEC authentication chain down to the leaf. if the supplied DNSSEC chain does not validate, the client MUST ignore the DNSSEC chain and validate only via other supplied credentials 🫣

9. (D)TLS Protocol Profile 💜

this section defines the (D)TLS protocol profile of DNS over (D)TLS 🎀

clients and servers MUST adhere to the (D)TLS implementation recommendations and security considerations of [RFC7525], except with respect to the (D)TLS version 📜

since encrypting DNS with (D)TLS is a greenfield deployment (a brand-new one, basically), DNS clients and servers MUST implement only (D)TLS 1.2 or later. for example, implementing (D)TLS 1.3 [TLS-1.3] [DTLS-1.3] is also an option ✨

implementations MUST NOT offer or provide TLS compression, since compression can leak significant amounts of information, especially to a network observer capable of forcing the user to do an arbitrary DNS lookup in the style of the Compression Ratio Info-leak Made Easy (CRIME) attacks [CRIME] 💀

implementations compliant with this profile MUST implement the following items:

  • TLS session resumption without server-side state [RFC5077], which eliminates the need for the server to retain cryptographic state for longer than necessary. (This statement updates [RFC7858].) 🌸
  • Raw public keys [RFC7250], which reduce the size of the ServerHello and can be used by servers that cannot obtain certificates (e.g., DNS servers on private networks). A client MUST only indicate support for raw public keys if it has an SPKI pin set pre-configured (for interoperability reasons). 🔑

implementations compliant with this profile SHOULD implement the following items:

  • TLS False Start [RFC7918], which reduces round trips by allowing the TLS second flight of messages (ChangeCipherSpec) to also contain the (encrypted) DNS query. 🏎️
  • The Cached Information Extension [RFC7924], which avoids transmitting the server's certificate and certificate chain if the client has cached that information from a previous TLS handshake. 🧠

guidance specific to TLS is provided in [RFC7858], and guidance specific to DTLS is provided in [RFC8094] 📖

10. IANA Considerations 🌈

this document does not require any IANA actions 🙌

11. Security Considerations 🚨

security considerations discussed in [RFC7525], [RFC8094], and [RFC7858] apply to this document. this one is serious, bestie 😭

DNS clients SHOULD implement (1) support for the mechanisms described in Section 8.2 and (2) offering a configuration option that limits authentication to using only those mechanisms (i.e., with no fallback to pure PKIX-based authentication), so that authenticating solely via the PKIX infrastructure can be avoided 🛡️

11.1. Countermeasures to DNS Traffic Analysis 🕵️‍♀️

this section makes suggestions for measures that can reduce an attacker's ability to infer information about encrypted client queries by other means (e.g., via an analysis of encrypted traffic size, or via monitoring the unencrypted traffic from a DNS recursive resolver to an authoritative server) 👀

DNS-over-(D)TLS clients and servers SHOULD implement the following relevant DNS extensions:

  • Extension Mechanisms for DNS (EDNS(0)) padding [RFC7830], which allows encrypted queries and responses to hide their size, making analysis of encrypted traffic harder. 🎭

guidance on padding policies for EDNS(0) is provided in [EDNS0-Pad-Policies] 📝

DNS-over-(D)TLS clients SHOULD implement the following relevant DNS extensions:

  • Privacy election per [RFC7871] ("Client Subnet in DNS Queries"). If a DNS client does not include an edns-client-subnet EDNS0 option with SOURCE PREFIX-LENGTH set to 0 in a query, the DNS server may potentially leak client address information to the upstream authoritative DNS servers. A DNS client ought to be able to inform the DNS resolver that it does not want any address information leaked, and the DNS resolver should honor that request. 🙊

12. References 📚

12.1. Normative References 💖

okay so these are the docs the spec needs you to have read, bestie 📚 no skipping!!

12.2. Informative References 🌸

these ones are the extra reading, the "ooh tell me more" pile 🦋

Appendix A. Server Capability Probing and Caching by DNS Clients 🧚

this bit is non-normative, so it's just a friendly chat about how DNS clients can probe for and cache what privacy-enabling DNS servers can do 🔍✨

rollout of both DNS over TLS and DNS over DTLS is gonna be gradual 🐢 not every server will support one or both of these protocols, and the well-known port might get blocked by some middleboxes 🙈 so clients are expected to keep track of servers that support DNS over TLS and/or DNS over DTLS, plus the ones they've previously authenticated 📝

if there's no server capability info available, then (unless the configuration of the DNS client says otherwise) clients that implement both TLS and DTLS should try to authenticate using both protocols before failing or falling back to an unauthenticated or cleartext connection 💅 and clients using an Opportunistic Privacy profile should try all available servers (possibly in parallel) to get an authenticated and encrypted connection before falling back 🫶

RATIONALE: this can make latency go up while the client is figuring out server capabilities, BUT it maximizes the chance of sending the query over an authenticated and encrypted connection. worth it, periodt 💖

Acknowledgments 🎀

huge thanks to the authors of both [RFC8094] and [RFC7858] for laying the groundwork for this doc and for reviewing the contents 🙌 the authors would also like to thank John Dickinson, Shumon Huque, Melinda Shore, Gowri Visweswaran, Ray Bellis, Stephane Bortzmeyer, Jinmei Tatuya, Paul Hoffman, Christian Huitema, and John Levine for reviewing and discussing the ideas in here 🫶💜

Authors' Addresses 🦋

Sara Dickinson
Sinodun Internet Technologies
Magdalen Centre
Oxford Science Park
Oxford  OX4 4GA
United Kingdom

Email: sara@sinodun.com
URI:   https://www.sinodun.com/


Daniel Kahn Gillmor
ACLU
125 Broad Street, 18th Floor
New York, NY  10004
United States of America

Email: dkg@fifthhorseman.net


Tirumaleswar Reddy
McAfee, Inc.
Embassy Golf Link Business Park
Bangalore, Karnataka  560071
India

Email: TirumaleswarReddy_Konda@McAfee.com

the end!! you made it 🌈👑✨

📦 where this page comes from