Summary

  • DNS Cookies add a lightweight, stateless signal to UDP DNS. A valid Server Cookie weakly binds a prior exchange to a Client Cookie and source IP address; it does not identify a person, organization or resolver, authenticate DNS data, hide a query or defeat an on-path observer.
  • RFC 9018 makes the server construction interoperable: version 1 uses a 16-byte Server Cookie, SipHash-2-4, an explicit timestamp and a configurable secret. In anycast, every node must recognize the same active epochs, so secret distribution becomes an operational authority surface.
  • Evidence must connect the exact COOKIE bytes to validation reason, source-address view, anycast node, secret epoch, BADCOOKIE behavior, local defence relaxed or retained, response limits and packet outcome. “Cookie valid” is a conclusion, not the audit trail.

The query that looked known

Imagine an authoritative DNS anycast service receiving a surge of UDP queries for a large signed answer. Most packets claim to come from addresses that never asked the question. The service limits those first-contact requests because a generous response would amplify the attack. One resolver returns with the Client Cookie it chose earlier and the Server Cookie the service issued. Validation succeeds, so the server treats that source as a previously reached client and permits a fuller answer.

Minutes later, the same source address belongs to traffic emerging from a different subscriber behind carrier-grade NAT. Or an on-path observer has copied the option. Or one anycast node still accepts an old secret after its peers have retired it. The bytes remain acceptable somewhere, but the organizational story attached to them has changed.

None of those cases makes DNS Cookies defective. They show why the mechanism calls its assurance weak. The token answers a bounded packet question: has someone able to receive at this apparent source address obtained a server-generated value bound to this Client Cookie within the accepted time and secret epoch? It does not answer who that someone is, whether the endpoint remains under the same control, whether the query is benign, or whether the requested answer should escape every other defence.

The leadership issue begins at the policy that consumes the answer. A cookie validator can supply one fact. A rate limiter, response-size controller or abuse system decides what power that fact receives.

Two tokens with unequal jobs

IANA assigns EDNS option code 10 to COOKIE. Under RFC 7873, the client begins with an eight-byte Client Cookie when it does not yet know the server's value. The server responds with that Client Cookie plus a Server Cookie. In later requests, the pair allows each side to reject some off-path forgery without establishing per-client state at the server.

The Client Cookie is not a credential issued by a central authority. RFC 9018 says it should carry 64 bits of entropy and differ for different server IP addresses. It should change when the client IP changes and should not survive a program restart. The client recognizes its own value; the server does not learn an identity from it.

The Server Cookie has the stronger construction but the narrower audience. RFC 9018 version 1 fixes it at 16 bytes. Together with the eight-byte Client Cookie, the complete option is exactly 24 bytes. Its hash is SipHash-2-4 over the Client Cookie, version, reserved bytes, timestamp and client IP, keyed by a secret held by the server or an anycast set. The timestamp is visible; the keyed hash makes a fresh acceptable value difficult for an off-path party to invent.

That design avoids a server-side table for every client. The request itself carries the material needed for verification. Statelessness reduces memory pressure under attack, yet it moves importance into the secret, accepted time window and exact input encoding. A single “cookies enabled” checkbox says almost nothing about whether those three controls are coherent across the service.

What valid means—and what it cannot mean

A valid Server Cookie weakly assures the server that the request came from a client at the source IP that is using the included Client Cookie and had received an earlier server response. That is enough to distinguish many genuine repeat clients from spoofed-source floods. It may justify sending a response that the service would withhold, truncate, rate-limit or move to TCP for an unproven source.

Validity does not authenticate the subscriber behind an address. NAT may make many users appear as one source. Address reassignment may give a later user an earlier network location. An on-path actor can observe a valid cookie and reuse it while it remains accepted. A compromised resolver can send harmful traffic with perfectly valid tokens. The cookie does not name the software, operator, account, jurisdiction or purpose of the query.

It also does not authenticate DNS data. DNSSEC validates signed RRsets and authenticated denial under a separate chain. Transaction entropy, source-port randomization and matching question fields remain relevant to forged replies. DNS over TLS, HTTPS or QUIC provides transport properties that a visible UDP option does not. A cookie is not encryption, not confidentiality and not a substitute for channel authentication.

This separation prevents a common controls failure: one green signal erases all other uncertainty. “Valid cookie” should modify only the safeguards whose threat model it directly addresses—principally off-path source spoofing and forged responses. It should not bypass query-class restrictions, access control, recursion policy, DNSSEC validation, response-rate ceilings, anomaly detection or incident blocks unless a separately documented rule justifies that choice.

Anycast turns a secret into shared operating authority

At one DNS service address, anycast may deliver consecutive requests to different machines, cities, implementations or operators. A client cannot be expected to know which node answered. For a Server Cookie to remain useful, the node receiving the next request must verify the value created by another node at the same address.

RFC 9018 therefore requires the Server Secret to be configurable and defines interoperable version-1 construction. The gain is mixed-vendor operation. The cost is a real custody problem: every participating node that validates the common cookie must possess material capable of generating acceptable tokens for the set.

The RFC prescribes a three-stage rotation. First, deploy the new secret everywhere while nodes still generate with the previous one and verify both. Second, generate with the new secret while retaining the old one for verification. Third, retire the old secret after clients have had time to refresh. The order matters. Generating before every node can verify creates BADCOOKIE churn by geography. Retiring before traffic has crossed the new epoch turns valid repeat clients back into strangers. Keeping the old key indefinitely widens the exposure window.

The shared secret should not silently become a universal credential across unrelated anycast addresses, environments or customers. Scope it to the smallest operational set that must interoperate. Record which nodes learned, activated and retired each epoch. Use independent readiness measurements rather than assuming that configuration delivery equals activation.

BADCOOKIE is recovery, not success

An invalid Server Cookie can mean expiration, a changed client address or Client Cookie, inconsistent anycast configuration, or attempted spoofing. The server can return BADCOOKIE with a fresh value. When the Client Cookie in the response matches, the client can retry using the new Server Cookie.

That retry path is an essential compatibility mechanism. It is also a place where a local fault can multiply load. Repeated BADCOOKIE responses must not create an infinite loop. Operators should measure first-contact requests, valid cookies, stale or malformed cookies, BADCOOKIE responses, successful retries and clients that fall back to another transport.

A dashboard that counts only validation successes conceals the most valuable failure pattern. If one anycast site produces a high BADCOOKIE rate for values accepted elsewhere, the problem may be secret epoch drift rather than hostile traffic. If one client population churns after address changes, NAT or mobility may be the explanation. If malformed lengths rise across every site, parser abuse becomes more plausible.

The response to each cause differs. The protocol error is observable; authority requires the organization not to collapse it immediately into blame.

A minimum common layer with local refusal

The architecture illustrates Heng Lu's Minimum Initial Specification. The common layer fixes a small set of interoperable facts: option code, wire lengths, construction method, timestamp semantics, BADCOOKIE and validation rules. It does not prescribe one global response-size policy, rate limiter, customer class or key-custody organization.

Localized Future Decision remains visible at both ends. A client may use cookies with one server and not another. A server may treat a first-contact request conservatively, accept a valid cookie for one bounded relaxation, or require TCP under pressure. A deployment that does not implement cookies remains part of DNS; non-adoption is not a declaration of invalidity.

Voluntary Adoption is proven by packets, not the publication date of an RFC. Option 10 in the IANA registry is symbolic coordination. A correctly parsed 24-byte version-1 option is protocol state. A policy decision to send a larger response is executable authority. The resulting packet and amplification ratio are consequence. Those layers must remain distinguishable.

Running-code primacy does not grant moral legitimacy to whatever code happened to do. It requires claims to be tested against the actual implementation. If an operator says cookies protect its authoritative service, it must show that clients receive and return them, every anycast node validates the intended epochs, off-path forgeries lose privilege, on-path replay remains inside the documented residual risk, and fallback does not become an outage.

Sources