Domain Name System (DNS) Cookies
updated by
- rfc-9018 — Interoperable Domain Name System (DNS) Server Cookies
Extracted elements (28)
DNS Cookies provide the services that TSIG and SIG(0) do not: lightweight message authentication of both requests and responses with no requirement for pre-configuration or per-client server-side state. TSIG requires key pre-agreement and time synchronization; SIG(0) does not authenticate requests and requires public-key cryptography.
The Client Cookie's inputs are intentionally limited to the Server IP Address and slowly-changing quantities (Client Secret) rather than per-request data like request ID. This keeps the Client Cookie stable across a session, which is required because the Server Cookie is derived from the Client Cookie; a changing Client Cookie would force each request to be sent twice—once to learn the new Server Cookie, once to use it.
The Server Cookie is computed as a PRF of the request source IP address and the Client Cookie (in addition to the Server Secret) so that different clients behind the same NAT box—sharing one external IP address—produce distinct Server Cookies. Without including the Client Cookie, an attacker behind the same NAT could reuse a legitimately obtained Server Cookie against forged source addresses of other hosts behind that NAT.
The Server Cookie is NOT used as an input to the Client Cookie (asymmetric dependency) because doing so would create an almost infinite series of errors in anycast environments: each retry would generate a new Client Cookie, requiring a new Server Cookie, causing perpetual BADCOOKIE loops. The Client Cookie is therefore derived solely from stable client-side state.
DNS Cookies are designed for incremental deployment: a Cookie-aware server or client interoperates successfully with a non-implementing peer, merely forgoing the security benefit. Servers that do not implement the COOKIE option ignore it and respond normally; Cookie-aware clients and servers gain mutual security benefits only when both sides support it.
DNS Cookies are tolerant of NAT and NAT-PT address translation as long as the external IP mapping is relatively stable; an occasional address change is treated similarly to a Client Secret rollover. Port-mapping NAT requires the Server Cookie to incorporate the Client Cookie to distinguish co-located clients.
A client MUST send Client Cookies that will usually be different for any two servers at different IP addresses, to provide minimal authentication.
A DNS client MUST discard a response if it contains an illegal COOKIE option length or an incorrect Client Cookie value. If the client expected a COOKIE option and it is absent, the response MUST also be discarded.
A server MUST send Server Cookies that will usually be different for clients at any two different IP addresses or with different Client Cookies, to provide minimal authentication.
Clients and servers MUST NOT continue to use the same secret in new requests and responses for more than 36 days, and SHOULD NOT continue to do so for more than 26 hours.
For anycast server clusters, it is RECOMMENDED that all server clones share the same Server Secret. If time skew exists during secret updates, servers SHOULD accept Server Cookies based on either the old or new secret for the maximum likely skew period.
If the COOKIE option is shorter than 8 bytes, longer than 8 but shorter than 16, or longer than 40 bytes, the server MUST respond with FORMERR. Valid cookie option lengths are exactly 8 or in the range 16–40 inclusive.
It is RECOMMENDED that a server retain its previous secret after rollover for a configurable period of 1–300 seconds (default 150 seconds), treating requests with old-secret Server Cookies as valid during that window. When responding with an old cookie, the server MUST include a new Server Cookie.
Servers MUST, at least occasionally, respond to requests containing only a Client Cookie (no Server Cookie) so that a client can bootstrap to the secure state with a recognized Server Cookie. A server need not maintain per-client state to achieve this.
The cookie computation algorithm SHOULD be based on a pseudorandom function at least as strong as 64-bit FNV, since an excessively weak algorithm could allow adversaries to guess cookies. Stronger algorithms such as HMAC-SHA-256 truncated to 64 bits are acceptable but impose additional computational load.
To avoid rollover synchronization and predictability, it is RECOMMENDED that pseudorandom jitter in the range of plus-zero to minus-at-least-40% be applied to the scheduled rollover time of a COOKIE secret.
When a BADCOOKIE response is received and the Client Cookie in the reply matches what was sent, the client SHOULD retry the request using the new Server Cookie from the response. If BADCOOKIE persists after retrying with the new cookie, the client SHOULD fall back to TCP.
A client may query explicitly for a Server Cookie by sending a QUERY with an empty Question Section (QDCOUNT=0) and an OPT RR containing a COOKIE option. The server responds with an empty Answer Section and a COOKIE option containing the Client Cookie and a valid Server Cookie; RCODE is NOERROR if the submitted Server Cookie was valid, BADCOOKIE if it was invalid.
The Client Cookie SHOULD be a pseudorandom function of the Client IP Address, Server IP Address, and a Client Secret with at least 64 bits of entropy. The selection of the PRF is private to the client, as only the client needs to recognize its own cookies.
The DNS COOKIE option is an EDNS0 OPT RR option (OPTION-CODE 10) carried in the RDATA of an OPT RR in both requests and responses. It uses two distinguished formats—client-only and client-plus-server—that share the same option code and are distinguished solely by length.
The Server Cookie SHOULD consist of or include a 64-bit-or-larger pseudorandom function of the request source IP address, a Server Secret (at least 64 bits entropy), and the Client Cookie. Inclusion of the Client Cookie distinguishes multiple clients sharing the same NAT-translated IP address.
IANA assigned DNS extended RCODE value 23 with name BADCOOKIE and description 'Bad/missing Server Cookie', referencing RFC 7873 as an early allocation per RFC 7120.
IANA assigned EDNS0 option code 10 with name COOKIE and status Standard, referencing RFC 7873.
Attackers who do not know a valid Server Cookie can omit the COOKIE option or send a random one; servers must apply independent rate-limiting of error responses to mitigate amplification and denial-of-service under these conditions. Increased rates of bad cookies should prompt more frequent secret rollover.
DNS Cookies provide no protection against on-path adversaries who can observe plaintext DNS traffic, such as on-path routers, bridges, or devices on a shared link. The mechanism protects only against off-path attackers who cannot observe request/response messages.
When a DNS server with Cookies enabled receives a request, it follows five branches: (1) no OPT/COOKIE—respond normally; (2) malformed COOKIE—return FORMERR; (3) only Client Cookie—silently discard, send BADCOOKIE, or process normally per policy; (4) Client Cookie plus invalid Server Cookie—treat as case (3); (5) Client Cookie plus valid Server Cookie—process and include COOKIE in response.
When a client does not know the Server Cookie, the COOKIE option carries only an 8-byte Client Cookie; OPTION-CODE is 10 and OPTION-LENGTH is 8.
When a Server Cookie is known, the COOKIE option carries the 8-byte Client Cookie followed by a variable-length Server Cookie of 8 to 32 bytes, making OPTION-LENGTH 16 to 40 inclusive. Valid lengths are therefore 8 and 16–40; any other length is malformed.