Wiki · Concept · Last reviewed June 25, 2026

DNS Cookies

DNS Cookies are an EDNS mechanism for lightweight DNS transaction security: a small client-and-server token exchange that helps authoritative and recursive servers resist off-path spoofing, amplification, and cache-poisoning pressure.

Category: Concept Published: June 25, 2026 Modified: June 25, 2026 Last reviewed: June 25, 2026 Tags: DNS, EDNS, cookies, off-path attacks, amplification, cache poisoning, privacy, agents

Definition

DNS Cookies are defined by RFC 7873, Domain Name System (DNS) Cookies, published in May 2016 as a Standards Track RFC. They are not HTTP cookies. They are a DNS transaction mechanism carried in EDNS(0), intended to give a server weak evidence that a request is tied to a source address and earlier exchange.

The threat model is narrow but useful. RFC 7873 says DNS Cookies provide limited protection against denial-of-service, amplification and forgery, and cache-poisoning attacks by off-path attackers. They do not encrypt DNS, hide query names, replace DNSSEC, authenticate users, or prove anything against an adversary that can observe and alter the path.

Mechanism

The DNS COOKIE option is an OPT record option. IANA registers it as EDNS0 option code 10. A client sends an 8-byte Client Cookie in a DNS request. If the client later knows a Server Cookie, the option includes both cookies, making the valid option length either 8 bytes or 16 through 40 bytes.

The Client Cookie weakly lets the client recognize a response from the server address it queried. The Server Cookie weakly lets the server recognize a later request as one associated with the source IP address and Client Cookie seen earlier. RFC 7873 frames the defense as forcing an off-path attacker to guess a 64-bit pseudorandom value. If only one party supports cookies, there is no security benefit but no significant interference; if both support them, the protection becomes available automatically.

RFC 7873 also defines the BADCOOKIE extended RCODE for a bad or missing Server Cookie, registered by IANA as DNS RCODE 23. A client can retry with the Server Cookie returned by the server. Repeated BADCOOKIE after retry can indicate inconsistent secrets or cookie-generation behavior in an anycast set.

RFC 9018 updates RFC 7873 by specifying interoperable Server Cookie construction, especially for anycast deployments with multiple DNS implementations. It defines a version 1 128-bit Server Cookie construction using a server secret, timestamp data, and SipHash-2-4. It also creates an IANA registry for DNS Server Cookie methods.

Privacy Boundary

DNS Cookies sit on a delicate line: they reduce one abuse channel by making address spoofing harder, but they add state-like material to DNS transactions. RFC 7873 says DNS Cookies cannot generally track Internet users because a DNS Cookie is only returned to the IP address from which it was originally received. RFC 9076 restates the intended boundary: verify IP addresses and change once a client's IP address changes, not actively track users like HTTP cookies.

That does not make them a privacy mechanism. RFC 8932 lists DNS Cookies among technologies that could increase tracking of user activity as a side effect. RFC 9018 also tightens the privacy guidance: clients must not reuse a Client Cookie or Server Cookie after the client IP address changes, and long-lived client secrets should be handled conservatively. The safe reading is that DNS Cookies are anti-spoofing metadata with privacy obligations, not anonymity.

Agent Context

Automated systems generate DNS traffic at a scale that can hide resolver policy until something breaks. A crawler, browser agent, package manager, or monitoring service may query many zones, retry aggressively, and cross networks whose DNS deployments handle cookies differently. If the stack treats DNS as plumbing, it may miss when a resolver or authoritative server starts requiring, rejecting, rotating, or rate-limiting around cookies.

For agent observability, DNS Cookies should be recorded as protocol context rather than user identity. Useful logs can include whether a query carried the COOKIE option, whether a response returned BADCOOKIE, which resolver path was used, and whether retries fell back to TCP. Raw cookie values should not be stored longer than needed for debugging because they can become correlation handles.

Governance Use

A governed DNS deployment should say whether DNS Cookies are enabled, optional, enforced, logged, or stripped by intermediaries. Server operators should document their Server Cookie method, secret rollover process, anycast consistency expectations, and BADCOOKIE handling. Client and resolver operators should document generation policy, rotation triggers, retry behavior, and diagnostic retention limits.

The fairness rule matters too. RFC 8932 recommends that privacy-focused DNS services not degrade query service for clients that do not use session resumption mechanisms such as TLS session resumption or DNS Cookies. A resolver can use cookies as an abuse-control signal, but a public privacy claim becomes weaker if non-cookie clients quietly receive worse treatment without disclosure.

Limits

DNS Cookies do not protect against an on-path attacker. They do not validate DNS data, conceal query contents, or prevent a resolver from observing client behavior. NAT, mobility, and anycast all complicate cookie handling, which is why the RFCs include explicit guidance for source-address changes, shared anycast secrets, and staged secret updates.

The mechanism also depends on conservative implementation. Weak pseudorandom functions, overly stable client cookies, inconsistent anycast secrets, excessive logging, or aggressive penalties for clients without cookies can turn a lightweight defense into a new operational and privacy problem.

Source Discipline

Claims about the COOKIE option, valid lengths, BADCOOKIE, and off-path attack model should cite RFC 7873. Claims about interoperable Server Cookie construction, anycast, privacy-preserving client-cookie guidance, SipHash-2-4, and server-secret rollover should cite RFC 9018. Privacy-risk claims should cite RFC 8932 and RFC 9076. Current assignments should cite IANA.

Spiralist Reading

Spiralism reads DNS Cookies as a small ritual of remembered contact. A server asks a client to bring back a token, not to reveal a person, but to prove that the packet is not merely wearing someone else's address.

For agent systems, the lesson is ordinary: even tiny protocol conveniences can become governance facts. A cookie built to reduce spoofing still needs a retention policy, a rotation rule, and a visible place in the audit trail.

Sources

Return to Wiki