UDP gives DNS low-overhead transport, but its source address can be forged and its replies can be imitated by an off-path sender. DNS Cookies add a small piece of client-generated state and, after contact with a supporting server, server-generated state. The mechanism raises the cost of off-path forgery without requiring a server to keep a session table for every client.

The mechanism is deliberately limited. RFC 7873 describes DNS Cookies as lightweight transaction security against off-path denial-of-service, amplification, forgery, and cache-poisoning attacks. It does not protect against an adversary that can observe the DNS exchange. RFC 9018 later tightened cookie construction so independently implemented anycast servers can interoperate.

DNS Cookies use EDNS option code 10. A client that has no Server Cookie sends an eight-byte Client Cookie. Once it has received a Server Cookie, later requests can carry both values.

first request:
  Client Cookie

server response:
  Client Cookie | Server Cookie

later request:
  Client Cookie | Server Cookie

The two fields serve different directions of the exchange. The Client Cookie gives the client a value to check in replies. The Server Cookie gives the server evidence that a sender at the apparent source address previously received a response associated with that Client Cookie.

A Client Cookie must differ across different server IP addresses. RFC 9018 specifies a 64-bit Client Cookie with 64 bits of entropy and recommends retaining it with the corresponding Server Cookie while the client IP address remains stable.

Server Cookies can be checked without per-client session state

A Server Cookie is not merely a random token stored in a lookup table. Its construction can bind it cryptographically to inputs that the server can recover when a later request arrives.

RFC 9018 defines an interoperable format with a version, reserved field, timestamp, and hash:

Server Cookie =
  Version | Reserved | Timestamp | Hash

For the defined version, the hash uses HMAC-SHA-256 truncated to 64, 128, 192, or 256 bits. Its inputs include the Client Cookie, version, reserved field, timestamp, and client IP address. The server can recompute the value from its secret and the request context rather than maintaining cookie state for each client.

That property matters for authoritative infrastructure receiving large volumes of UDP traffic. A validity check can remain tied to a server secret and request metadata instead of creating a long-lived allocation for every source address.

An off-path sender can place a victim’s address in the source field of a UDP request. Without another check, the DNS response goes to that victim.

A Server Cookie changes the useful state available to such a sender. To present a valid cookie for the forged address and Client Cookie, the sender needs a value produced for that context. A response carrying that value is sent toward the claimed source address, not toward an off-path sender using another address.

This is the basis for limiting amplification from spoofed requests. A server can apply stricter handling when a request has no valid Server Cookie and normal processing when a recognized cookie is present. RFC 7873 permits policy choices such as dropping a request, returning BADCOOKIE, or processing it when only a Client Cookie is supplied.

The mechanism does not make IP addresses identities. It provides a weak return-routability signal for a recent exchange.

BADCOOKIE bootstraps or refreshes server state

A client may have no Server Cookie, or a cached value may become invalid after secret rotation, an address change, or inconsistent anycast configuration. The protocol has an explicit recovery path.

A server can return a response containing the Client Cookie and a fresh Server Cookie. When the extended response code is BADCOOKIE, a client with a matching Client Cookie can retry using the new Server Cookie.

client  -> server : Client Cookie + stale Server Cookie
server  -> client : BADCOOKIE + fresh Server Cookie
client  -> server : Client Cookie + fresh Server Cookie

RFC 7873 also specifies fallback behavior involving TCP when a retry with a newly supplied cookie still receives BADCOOKIE. This avoids treating a cookie mismatch as permanent DNS failure.

Anycast can route successive packets for one server address to different backend instances. If those instances cannot validate one another’s Server Cookies, a client can enter repeated refresh cycles even though it is contacting the same advertised IP address.

RFC 9018 addresses this interoperability problem by defining a common Server Cookie construction. Servers in the same anycast set still need compatible secret-management behavior for cookies to validate across nodes. The specification also provides guidance for secret rollover.

The requirement is operational rather than a new trust model. DNS Cookies remain bound to the apparent network context; shared anycast handling keeps that context usable when routing changes the backend instance.

NAT is accounted for by combining address and client state

Many clients can appear behind one public NAT address. A Server Cookie based only on that address would give every client behind the NAT the same return-routability token.

DNS Cookies avoid that design by incorporating the Client Cookie into Server Cookie computation. Clients behind the same translated address can therefore carry different server-issued values.

This does not isolate hostile hosts that share the same network path in every case. It prevents the server from reducing all clients behind one translated address to a single cookie value solely because their external IP address is identical.

Cookies do not replace DNSSEC or encrypted DNS

DNS Cookies do not authenticate DNS records as signed data. DNSSEC provides origin authentication and integrity for signed DNS data through its chain of trust; DNS Cookies address a different transaction-level problem.

They also do not provide confidentiality. An on-path observer can see ordinary plaintext DNS traffic and the cookies carried with it. RFC 7873 explicitly excludes protection against on-path adversaries from the mechanism’s security boundary.

That boundary is central to deployment. DNS Cookies are useful as a lightweight filter for off-path spoofing and amplification, especially over UDP, but they are not a general replacement for record authentication, encrypted transport, TSIG, or SIG(0). Their security value comes from a narrower property: a request or reply can carry recent state that an off-path sender cannot simply derive from the visible DNS header and a forged source address.

Cybersecurity DNS DNS Cookies UDP Network Security