UDP makes DNS efficient, but its source address can be forged by an off-path sender. A small query carrying a victim’s address can trigger a larger response toward that victim, creating reflection and amplification. Forged replies also matter to resolvers because an attacker may try to inject an answer before the legitimate response arrives.
DNS Cookies add a lightweight transaction token to this boundary. RFC 7873 defines the COOKIE EDNS option, while RFC 9018 updates the server-side construction so implementations can interoperate, including in multi-vendor anycast deployments. The mechanism is deliberately limited: it raises the cost of off-path forgery, but it is not encryption, DNS data authentication, or protection from an adversary that can observe traffic on path.
The exchange starts with a Client Cookie
A client that supports DNS Cookies sends an eight-byte Client Cookie in the COOKIE option. RFC 9018 specifies that the value needs to be unguessable, recommends 64 bits of entropy, and requires a different Client Cookie for each server IP address.
A first exchange can be represented as:
client server
| |
| query + Client Cookie -------------------> |
| |
| <--- response + Client Cookie + Server Cookie
| |
| query + Client Cookie + Server Cookie ---> |The client checks that responses carry the Client Cookie it expects. An off-path system that cannot observe the exchange has to guess that value to manufacture a response that passes this check.
The Client Cookie is not a shared credential. The server does not need prior provisioning of a client secret, and different clients can choose their own construction. This keeps deployment separate from account identity or application authentication.
The Server Cookie ties a token to the apparent source
After receiving a Client Cookie, a supporting server returns a Server Cookie. On later queries, the client sends both values. The server can then validate that the token corresponds to the request’s apparent source address and Client Cookie.
RFC 9018 defines an interoperable version 1 Server Cookie. Its hash field is computed with SipHash-2-4 over the Client Cookie, version and reserved fields, timestamp, and client IP address, keyed by a Server Secret. The complete version 1 Server Cookie is 16 bytes, so a request carrying an eight-byte Client Cookie plus that Server Cookie has a 24-byte COOKIE option.
The design can remain stateless with respect to individual clients. A server that possesses the secret can recompute the expected value instead of storing a session record for every requester. That property is valuable at DNS scale, where maintaining handshake-style state for arbitrary UDP sources would create another resource pressure point.
Validation changes the amplification decision
The security value appears when a server distinguishes requests with a valid Server Cookie from requests that merely claim a source IP address.
An off-path attacker can send an initial query with a forged victim address, but the resulting Server Cookie goes to the victim, not to the attacker. Without observing that response, the attacker lacks the token needed to demonstrate receipt at the claimed address. A server can therefore apply stricter response behavior to requests that do not present a valid cookie.
RFC 7873 describes this as limited protection against DNS amplification, denial-of-service forgery, and cache-poisoning attempts from off-path attackers. Cookie enforcement can restrict forged requests to short, rate-limited error responses rather than allowing them to trigger large answers toward a victim.
This does not make every large DNS response safe. Deployment policy, response-rate controls, recursion exposure, EDNS behavior, and other DNS hardening measures remain relevant. DNS Cookies provide one signal: evidence that a requester previously received a server token at the source address represented by the exchange.
Anycast requires consistent validation
RFC 7873 recommended sharing a Server Secret among nodes in an anycast set, but it left the cookie algorithm largely implementation-specific. That created an interoperability problem: one node could issue a cookie that another implementation at the same anycast address could not validate.
RFC 9018 resolves that issue by defining the version 1 construction and requiring Server Cookie implementations to use it. The Server Secret must be configurable so nodes in an anycast deployment can produce consistent validation results.
Secret rotation also needs coordination. RFC 9018 describes a staged transition in which a new secret is distributed before it is used for generation, and the prior secret remains temporarily valid for verification. This avoids turning normal anycast routing changes into avoidable cookie failures during rotation.
The boundary stops at an on-path observer
DNS Cookies travel in DNS messages and do not provide confidentiality. An adversary able to observe the exchange can see cookie values and is outside the off-path threat model that gives the mechanism its main benefit.
They also do not replace DNSSEC. DNSSEC authenticates signed DNS data through its trust model; DNS Cookies provide lightweight transaction-level resistance to off-path forgery. TSIG and SIG(0) serve different authenticated-message use cases as well.
NAT introduces another boundary. Multiple clients can appear behind one external address. RFC 7873 discusses cases in which a host behind the same NAT may obtain a Server Cookie associated with that external address. Client Cookie checking still contributes resistance to forged responses, but the source-address signal is less granular than an individual internal host.
A small token creates a useful precondition
DNS Cookies do not turn UDP into an authenticated transport. Their useful property is narrower: a server can demand evidence that the requester received an earlier token at the claimed source address, while a client can require its own unpredictable token to return in responses.
That precondition is inexpensive, incrementally deployable, compatible with NAT and anycast when implemented correctly, and focused on a common DNS abuse pattern. For off-path reflection and response forgery, forcing an attacker to possess values delivered through the real network path changes a blind spoofing problem into one that requires information the attacker is not expected to have.