Usage Profiles for DNS over TLS and DNS over DTLS
updates
- rfc-7858 — Specification for DNS over Transport Layer Security (TLS)
Extracted elements (28)
Both Strict and Opportunistic Privacy profiles permit an initial meta-query (performed using Opportunistic Privacy) to obtain the IP address for the privacy-enabling DNS server. Requiring meta-queries to also use Strict Privacy would introduce significant deployment obstacles, though this leaves the meta-query subject to active attack.
Clients implementing an Opportunistic Privacy profile that know authentication information for a server SHOULD attempt authentication to detect (but not prevent) active attacks; an authentication failure signals a likely active attack in progress even though the client cannot determine the exact cause.
Opportunistic Privacy is intended to support incremental deployment of increased privacy with a view to widespread adoption of Strict Privacy. It should be employed when the client might otherwise settle for cleartext, providing maximum available protection depending on server capabilities.
The domain-name-based authentication approach encourages the association of stable, human-recognizable identifiers with secure DNS service providers, in contrast to SPKI pin sets which require ongoing key management.
This document updates RFC 7858 by requiring TLS session resumption without server-side state (RFC 5077) in compliant implementations, superseding the session-resumption guidance in the original DNS-over-TLS specification.
A DNS client implementing DNS over (D)TLS SHOULD NOT be configured by default to use only cleartext.
A DNS client MUST NOT fall back from Strict Privacy to Opportunistic Privacy during the resolution of a given query, as this could invalidate the protection offered against attackers.
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, MUST use available verification mechanisms to authenticate the server, and MUST abort connections when no verification mechanism succeeds.
A DNS client requiring Strict Privacy MUST use either (1) a source from Section 7 to obtain an authentication domain name for the server, or (2) an SPKI pin set as described in RFC 7858.
A DNS client that is configured with both an authentication domain name and an SPKI pin set for a DNS server SHOULD match on both when connecting, and the overall authentication result SHOULD only be considered successful if both mechanisms succeed.
DANE meta-queries for TLSA records MUST be validated using DNSSEC as described in RFC 6698; the DNS client may perform these meta-queries via Opportunistic Privacy or in the clear to avoid trust recursion.
DNS clients and servers MUST implement only (D)TLS 1.2 or later, and MUST adhere to the implementation recommendations and security considerations of RFC 7525 except with respect to (D)TLS version.
DNS clients MUST verify the entire certification path per RFC 5280 when a server presents a PKIX certificate, and MUST only inspect the certificate's subjectAltName extension for the reference identifier — they MUST NOT inspect the Subject field itself.
If a DNS client offers the TLS DNSSEC chain extension it MUST be capable of validating the full DNSSEC authentication chain to the leaf; if the supplied chain does not validate the client MUST ignore it and validate only via other supplied credentials.
Implementations compliant with the (D)TLS profile MUST implement TLS session resumption without server-side state (RFC 5077), which eliminates the need for the server to retain cryptographic state longer than necessary. This updates RFC 7858.
Implementations MUST implement raw public keys (RFC 7250); a client MUST only indicate support for raw public keys if it has an SPKI pin set pre-configured, for interoperability reasons.
Implementations MUST NOT offer or provide TLS compression, since compression can leak significant amounts of information (in the style of CRIME attacks) to a network observer capable of forcing the user to perform an arbitrary DNS lookup.
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.
With Strict Privacy, the DNS client MUST NOT commence sending DNS queries until at least one privacy-enabling DNS server becomes available. During captive-portal bootstrap the system MUST alert that DNS is not private.
DNS-over-(D)TLS clients SHOULD implement the RFC 7871 privacy election: if a client does not include an edns-client-subnet option with SOURCE PREFIX-LENGTH set to 0, the DNS server may leak client address information to upstream authoritative servers.
A privacy-enabling DNS server MUST implement DNS over TLS (RFC 7858), MAY implement DNS over DTLS (RFC 8094), SHOULD offer at least one credential from Section 8, and implements the (D)TLS profile from Section 9.
An authentication domain name (ADN) is a domain name used to authenticate a privacy-enabling DNS server. It may be obtained via full direct configuration (ADN+IP), ADN-only direct configuration with IP resolved via meta-queries, DHCP, or DNSSEC/DANE chain.
The DANE record for a DNS privacy server takes the form _853._tcp.[authentication-domain-name] for TLS and _853._udp.[authentication-domain-name] for DTLS, anchored via DNSSEC per RFC 6698.
The DNS client constructs a DNS-ID reference identifier from the authentication domain name and matches it against the server's PKIX certificate subjectAltName extension using RFC 6125 validation techniques.
The Opportunistic Privacy profile uses Opportunistic Security per RFC 7435, attempting but not requiring encryption and authentication. It may result in an authenticated+encrypted, encrypted-only, or cleartext connection depending on fallback logic, available authentication information, and server capabilities.
The Strict Privacy profile requires both an encrypted and authenticated connection to a privacy-enabling DNS server; a hard failure occurs if this is not available. It mitigates both passive eavesdropping and active client-redirection attacks, at the cost of providing no DNS service if an authenticated encrypted connection cannot be established.
DNS clients SHOULD implement DANE/DNSSEC authentication (Section 8.2) and offer a configuration option that limits authentication to those mechanisms with no fallback to pure PKIX-based authentication, to avoid sole reliance on the PKIX infrastructure.
DNS-over-(D)TLS clients and servers SHOULD implement EDNS(0) padding (RFC 7830) to hide the size of encrypted queries and responses, making traffic analysis harder for observers of encrypted DNS traffic.