Summary

  • DNS Cookies turn one successful round trip into limited evidence that a later UDP request came from the same apparent source address and Client Cookie, making off-path source forgery less useful without creating identity or confidentiality.
  • RFC 7873 defined the exchange; RFC 9018 made the Server Cookie interoperable across mixed anycast implementations by fixing a 16-byte version-1 structure, SipHash-2-4 construction and an operational secret-rollover sequence.
  • The mechanism is deliberately bounded: an on-path observer can reuse a visible cookie while it remains valid, NAT can merge many clients behind one public address, and servers still need rate limits and other DNS defenses.

At the beginning there is no shared account, certificate or negotiated key. There is only a UDP request whose source address may be true or forged. A DNS client adds an eight-byte Client Cookie to the EDNS COOKIE option. If the server supports the mechanism, it sends that value back with a Server Cookie of its own. The client stores the pair. On a later query it presents both.

That second request carries a modest piece of history. The Server Cookie was computed from the Client Cookie, the apparent client address and secret material held by the server. An off-path sender who merely writes a victim's address into an IP header should not have seen the earlier reply and therefore should not possess the matching token. The server can treat a valid pair as evidence that it has exchanged traffic with this address-and-cookie combination before. The client, for its part, can reject a reply that fails to return the Client Cookie it expected.

This is not identity. A household gateway, carrier-grade NAT or enterprise edge can make many devices share one public address. A compromised machine at the correct address can still be abusive. An observer on the path can see the plaintext cookie and replay it during its validity window. DNS Cookies neither encrypt a question nor authenticate the owner of a name, and they do not turn UDP into an accountable session. Their achievement is smaller: they raise the cost of a particular lie—the off-path claim that a packet came from an address that never received the preceding traffic.

That lie mattered because DNS could amplify it. A short question with a forged source address could induce a larger response toward a victim. A forged request could also make a recursive server spend work on lookups and DNSSEC validation. In the opposite direction, forged replies could race legitimate answers and try to poison a resolver's cache.

Existing defenses addressed different surfaces. DNSSEC authenticates DNS data, but it can enlarge messages and requires validation work. TSIG offers stronger transaction authentication, but presupposes shared-key administration. Source-port and transaction-ID entropy make blind response guessing harder. Response-rate limiting constrains output. DNS Cookies were designed to complement these controls with lightweight, stateless return-path evidence.

RFC 7873, published in May 2016, put that evidence into EDNS option code 10. With no known Server Cookie, the option is only the eight-byte Client Cookie. Once the client has learned a Server Cookie, the option contains both. The original specification allowed a Server Cookie from eight to thirty-two bytes and left its private construction to the implementation. A server did not need a stored record per client: it could recalculate the token from the request address, the Client Cookie and a secret.

The state machine was intentionally compatible with partial deployment. A server that does not implement DNS Cookies ignores the option. A supporting server that receives only a Client Cookie may, according to policy, drop the request, answer with BADCOOKIE, or process it normally; when it responds, it supplies a Server Cookie so the client can move into the stronger state. A malformed option yields FORMERR. An invalid or stale Server Cookie is treated as though it were absent. A valid one allows the server to relax measures whose only purpose is to defend against spoofed UDP source addresses—not every abuse control it has.

BADCOOKIE is therefore more than an error name. It is a transition. A matching Client Cookie in the reply tells the client that the response belongs to its exchange, while the newly returned Server Cookie gives it the value needed for a retry. If a fresh value immediately fails again, the protocol points to TCP as a fallback. Repeated failures can also expose an operational fault: members of an anycast service may disagree about secrets or cookie construction.

NAT explains why the design needs both halves. Binding a Server Cookie only to the public source address would let one device behind a gateway obtain a token usable by every other device sharing that address. Including the Client Cookie in the server calculation distinguishes those flows without requiring the server to remember each client. The result is still not individual identity—the server sees the NAT's public address—but it preserves the mechanism's narrow claim at the granularity available on the wire.

Anycast created the harder historical problem. One service address can deliver consecutive packets to different machines, perhaps running different DNS software. RFC 7873 recommended shared server secrets, but did not standardize how implementations turned the inputs into a Server Cookie. Two vendors could hold the same secret and still produce mutually unintelligible tokens. A client routed from one node to another would appear to have brought a bad cookie even though nothing malicious had happened.

RFC 9018, published in April 2021, converted that implementation freedom into an interoperable format. A version-1 Server Cookie is sixteen bytes: one byte of version, three reserved bytes, four bytes of timestamp and eight bytes of SipHash-2-4 output. Together with the eight-byte Client Cookie, the complete option is exactly twenty-four bytes. The hash covers the Client Cookie, the visible structural fields, the client IP address and the shared Server Secret. The address influences validation without being copied into the cookie itself.

The timestamp gives the token an explicit replay horizon. RFC 9018 recommends accepting a value no more than one hour old and tolerating up to five minutes of future skew, while refreshing a cookie once it is more than half an hour old. These are standards recommendations, not evidence that every deployment uses identical timers. They do show that the token is meant to expire. An on-path observer who captures it learns both the token and its usable period; the mechanism narrows replay rather than eliminating observation.

Interoperability also turned secret rotation into an anycast coordination problem. The new secret must first reach every node while all nodes continue issuing cookies under the old secret and validate both. Only after distribution is complete do nodes begin issuing under the new secret, still validating the old. The old value can be retired after clients have had time to refresh. Clock synchronization joins secret consistency as part of the protocol's control surface. A cryptographic primitive alone cannot save a fleet whose members disagree about time or rollout phase.

RFC 9018 also changed the Client Cookie guidance. Rather than requiring a hash that includes a client address often unknown when the cookie is created, it recommends sixty-four bits of entropy for each server IP. The client must stop reusing the cookie after its own IP address changes, because a stable token crossing networks can become a tracking handle. When a server is not known to support cookies, the client must not keep presenting the same failed identifier. NAT leaves a residual limit: a host may not know that its gateway's public address changed, and the public address itself remains observable to the server.

The history of DNS Cookies is thus not a story of DNS acquiring identity. It is a story of evidence being fitted to the claim it can actually support. The first exchange proves almost nothing about intent. It creates a token that makes the next source-address claim more expensive to forge from off path. RFC 7873 defined that bargain. RFC 9018 made it operable across a diverse anycast fleet, and in doing so revealed where the real authority lies: with client reuse policy, server response policy, synchronized time and the disciplined custody of shared secrets.

Sources