Interoperable Domain Name System (DNS) Server Cookies
updates
- rfc-7873 — Domain Name System (DNS) Cookies
Extracted elements (24)
RFC 7873 left the precise Server Cookie construction algorithm to implementations, resulting in incompatible implementations across vendors that made DNS Cookies impractical on multi-vendor anycast networks. This document standardizes an exact algorithm so diverse implementations sharing a secret will interoperate.
The original RFC 7873 recommendation included the Client IP address as input to Client Cookie construction to prevent cross-link tracking. Multiple DNS vendors found this impractical because the Client Cookie is typically computed before the Client IP address is known, so the IP input requirement was removed and replaced with mandatory cookie invalidation on IP change.
The Reserved Sub-Field in the Server Cookie structure is intentionally not enforced to be zero on verification; this allows future versions to use those bits while remaining backward-compatible, as long as the Hash is computed over the received Reserved value.
Client Cookies do not need to be interoperable across different implementations because each client need only recognize its own cookies; the interoperability requirement applies only to Server Cookies in anycast deployments.
Enforcing the received COOKIE option to be exactly 24 bytes for version 1 ensures the SipHash-2-4 input is an injective function of its elements, specifically preventing a 36-byte COOKIE option from an IPv4 client from being mistakenly validated as if it came from an IPv6 client (data substitution attack).
A client MUST use a different Client Cookie for each different Server IP address to provide minimal authentication of the targeted server and complicate spoofing. The Client Cookie SHOULD have 64 bits of entropy.
All comparisons involving Timestamp fields MUST use serial number arithmetic as defined in RFC 1982, which handles relative time windows less than 68 years at any future date.
Clients MUST NOT reuse a Client or Server Cookie after the Client IP address has changed, in order to prevent tracking of devices across links and avoid circumventing IPv6 Privacy Extensions.
On construction, the Reserved Sub-Field MUST be set to zero octets. On Server Cookie verification, the server MUST NOT enforce those fields to be zero; the Hash must be computed with the received Reserved value as-is.
SipHash-2-4 is REQUIRED as the mandatory and default algorithm for DNS Cookies in a compliant DNS server to ensure interoperability between DNS implementations.
The interoperable Server Cookie algorithm specified in Section 4 of this document MUST be used by all Server Cookie implementations, replacing the example algorithm from Appendix B.2 of RFC 7873.
The Server Secret MUST be configurable to ensure that servers in an anycast network return consistent, mutually verifiable Server Cookies.
The simple Client Cookie and Server Cookie algorithms in Appendices A.1 and B.1 of RFC 7873 MUST NOT be used, as the resulting cookies are too weak against modern security standards.
The Timestamp value MUST be checked by the server to be within a defined period; servers SHOULD allow cookies within a 1-hour window in the past and a 5-minute window into the future to accommodate low-volume clients and clock skew in anycast sets.
When a DNS server receives a version 1 Server Cookie for validation, the length of the received COOKIE option MUST be precisely 24 bytes (8-byte Client Cookie plus 16-byte Server Cookie); this length verification is REQUIRED to guarantee correct SipHash-2-4 input lengths.
When a server does not support DNS Cookies, the client MUST NOT send the same Client Cookie to that same server again; it is recommended to wait a period (e.g., five minutes) before retrying with a new Client Cookie.
To prevent client tracking when the client IP changes, a new Client Cookie MUST be created on IP address change, and a client MUST NOT send a previously sent Client Cookie to a server that has not been observed to support DNS Cookies. Tracking of the public IP of a NAT device is explicitly out of scope.
IANA created the 'DNS Server Cookie Methods' registry under 'Domain Name System (DNS) Parameters', with Expert Review assignment policy. The registry maps (Version, Size) pairs to construction methods; Version 1 / 16 bytes is assigned to SipHash-2-4 per RFC 9018 Section 4.
DNS Cookies provide no protection against on-path adversaries who can observe plaintext DNS traffic. An on-path attacker observing a Server Cookie can use it for denial-of-service amplification, forgery, or cache-poisoning attacks against the observed client for the full lifetime of that Server Cookie.
Servers validating version 1 Server Cookies require access to a reliable, attacker-unalterable time value. All servers in an anycast set must have their clocks synchronized to correctly validate Timestamp Sub-Fields.
The cleartext Timestamp Sub-Field in version 1 Server Cookies is visible to on-path observers and reveals the exact time window during which the observed Server Cookie remains valid for use in attacks against the client.
Deploying a new Server Secret MUST be done in three stages: Stage 1 — distribute new secret, keep generating with old, accept both; Stage 2 — begin generating with new secret, still accept both; Stage 3 — remove old secret. The operator SHOULD wait at least the longest zone TTL plus 1 hour between Stage 2 and Stage 3.
The 128-bit Server Cookie consists of four Sub-Fields: a 1-octet Version, a 3-octet Reserved, a 4-octet Timestamp (Unix epoch, unsigned, network byte order), and an 8-octet Hash. The total COOKIE option for version 1 is exactly 24 bytes (8-byte Client Cookie plus 16-byte Server Cookie).
The Version 1 Hash Sub-Field is computed as SipHash-2-4(Client Cookie | Version | Reserved | Timestamp | Client-IP, Server Secret), where Client-IP is 4 bytes for IPv4 or 16 bytes for IPv6, yielding a total input of exactly 20 bytes (IPv4) or 32 bytes (IPv6).