Summary

  • DNS Cookies provide deliberately limited protection against off-path amplification, forgery and cache poisoning by linking a request to a Client Cookie, source address and prior server response.
  • A valid Server Cookie does not identify a person or durable device. NAT can place many clients behind one public address, address changes require Cookie rotation, and an on-path observer can reuse an observed Cookie during its valid lifetime.
  • Operations should preserve Cookie method, age, source-address context, anycast validation domain and retry result, while keeping access control, account attribution and per-person rate limits on a separate authenticated principal.

The resolver dashboard says the request was “authenticated” because its Server Cookie validated. A downstream access system turns that label into a subscriber identity and exempts the request from a control intended for anonymous traffic. The conclusion sounds plausible: the server minted the Cookie, the requester returned it, and the source address matches. Yet a carrier NAT may place thousands of customers behind that address, a shared recursive resolver may originate traffic for an entire organisation, and an observer on the path may have seen the same Cookie while it remained valid.

Nothing in that chain makes the Cookie useless. It makes the word authenticated too broad. DNS Cookies answer a narrower and operationally important question: does this request present evidence that a client at this source address, using this Client Cookie, received an earlier response from this server or interoperable anycast set? That is a return-path and transaction claim. Identity is a different claim with a different owner.

A valid Server Cookie supports evidence of a prior exchange, not who made it

RFC 9018, Section 1 calls DNS Cookies a lightweight transaction-security mechanism with limited protection against denial-of-service amplification, forgery and cache-poisoning attacks by off-path attackers. The qualifier is architectural, not modest wording. The mechanism is designed to make a forged source address less useful when the attacker cannot observe the traffic between the purported client and the DNS service.

The two Cookie fields play different roles. The client constructs an unguessable Client Cookie and must use a different value for every different server IP address. RFC 9018 recommends 64 bits of entropy. The server does not issue this field as an account credential; it receives a value selected by the client and later returns it. The per-server choice gives the client minimal assurance that a reply corresponds to the targeted server address and makes it harder for one DNS server to spoof replies from another.

The Server Cookie is the server’s return-path token. RFC 9018 describes it as effectively a message authentication code calculated from the Client Cookie, the client IP address, defined version and time fields, and a secret known to the server or to servers at the same anycast address. When a request returns a valid Server Cookie, the server is weakly assured that a client at the source address, using that Client Cookie, received a previous response carrying the value. In an interoperable anycast service, another member of the same validation set may have issued it.

The word weakly matters. The evidence attaches to an address-and-Cookie context, not to a natural person, subscriber, browser profile or hardware root of trust. RFC 7873, Section 5.2 lets a server with a valid Server Cookie assume that it has spoken to this client context before and relax defenses aimed at spoofed UDP requests. It does not turn the DNS option into a general authentication protocol. Nothing in the Cookie proves that the requester is entitled to a protected zone view, a billing account, a policy exemption or a per-user quota.

Address sharing makes the distinction concrete. Behind NAT, many independent clients can appear to the DNS server under one public address. RFC 9018 notes that the client may be unable to detect a change in that public address and that the server may track the NAT device’s public address; preventing such tracking is outside the document’s scope. A valid Server Cookie can therefore support a source-address return-path decision while remaining unable to distinguish the people or devices sharing that source.

Mobility and privacy create the inverse problem. To avoid following a device across links and bypassing IPv6 privacy addresses, RFC 9018 requires clients not to reuse Client or Server Cookies after their client IP address changes. A Cookie that changes is not evidence that the user changed; it may be the correct privacy response to an address transition. A Cookie that persists is not necessarily a durable identity either; it may simply reflect a stable process and network attachment.

The threat boundary is equally explicit. DNS Cookies provide no protection against an on-path adversary that can observe plaintext DNS traffic. An observer who sees a valid Server Cookie can reuse it against that client during the Cookie’s lifetime. The MAC protects the server’s construction from an off-path guesser who lacks the secret; it does not hide the value in flight or authenticate every actor able to transmit from the observed path.

The operational label should follow the protocol claim. Record “valid Server Cookie for source address, Client Cookie and validation set at this time”, not “authenticated user”. If an access, billing or accountability decision requires a person or account, join the DNS receipt to a separate authenticated principal and preserve the join evidence. The Cookie may strengthen the transaction record, but it must not silently become the identity record.

Shared addresses break the identity shortcut

NAT makes the distinction visible without any adversary. A household gateway, enterprise edge, carrier-grade NAT or shared recursive resolver can place many independent clients behind the source address observed by the DNS server. The Server Cookie calculation can correctly incorporate that public address and still say nothing about which device or person behind it originated a particular application action.

The limit appears directly in RFC 9018’s privacy discussion. A client behind a routing device performing NAT may be unable to detect a change in its public address. The server may track the public address of that NAT device, and preventing that tracking is outside the RFC’s scope. Address-bound evidence can therefore be accurate at the server’s network boundary and too coarse for subscriber attribution at the same time.

Using a valid Server Cookie as a per-person rate-limit key would merge unrelated users behind the same visible context. Using it as a billing identity would assign durable responsibility to a value whose protocol lifecycle follows network attachment and process state. The problem is not that the Cookie failed. The policy asked it to distinguish principals that it was never designed to name.

Mobility creates the reverse error. RFC 9018 requires a client not to reuse a Client or Server Cookie after its client IP address changes, in part to avoid tracking a device across links and defeating IPv6 Privacy Extensions. A new Cookie after a handover is therefore compatible with the same person and device. A stable Cookie is compatible with a stable address and process, not proof that the human principal remained the same.

The identity shortcut fails in both directions: one address can represent many clients, and one client can legitimately use many addresses and Cookies. A durable identity system needs a credential and lifecycle that survive—or intentionally end across—those changes. DNS Cookie semantics should not be stretched to fill that role.

BADCOOKIE records a branch, not a culprit

An invalid Server Cookie is also narrower evidence than its name may suggest. RFC 7873 lists several causes: the Cookie may be too old; the client address or Client Cookie may have changed; an anycast cluster may be inconsistently configured; or a spoofing attempt may have occurred. The server processes the request as though the invalid Server Cookie were absent. The protocol outcome does not choose one cause on behalf of the operator.

BADCOOKIE provides a recovery path. A client that receives the extended error with its matching Client Cookie retries using the new Server Cookie supplied in the response. If the fresh value produces another BADCOOKIE, inconsistent shared secrets or Cookie-generation methods in the anycast set become a plausible explanation. RFC 7873 then directs the client toward a TCP retry because the server may accept TCP’s transaction properties instead.

That sequence carries far more information than a counter of invalid Cookies. The useful receipt preserves the old Cookie’s age and method, the address seen at each side, the anycast validation domain, the newly issued value, the next response, and whether TCP changed the outcome. A single BADCOOKIE event cannot distinguish ordinary expiry, mobility, incomplete secret rotation and hostile traffic.

The ambiguity matters during secret changes. RFC 9018 requires staged rotation across an anycast set: members learn and validate the new secret before they begin issuing with it, then retain the previous secret during the transition. If one member moves early or forgets the prior secret, clients can alternate between valid and invalid results depending on where anycast sends each request. Labelling those clients as attackers hides the actual control failure.

Cookies complement the DNS transaction checks

DNS Cookies add evidence; they do not erase the matching rules for replies. RFC 5452 requires a resolver to match response and query addresses, destination port, Query ID, name, class and type before applying DNS trust rules. It also requires unpredictable source ports and Query IDs. These independent fields enlarge the space an off-path attacker must guess and reject a response that does not belong to the outstanding question.

The controls answer related but distinct questions. Query matching asks whether a response fits the transaction the resolver actually sent. A Client Cookie returned in a response weakly links that response to the server address the client targeted. A valid Server Cookie in a request gives the server evidence of a prior return path to the source context. None of them names a user, and none by itself supplies confidentiality.

RFC 6891 supplies the transport surface. EDNS is a hop-by-hop extension, and its OPT record carries control information for one question-and-answer sequence. The OPT record carries no DNS data and must not be cached, forwarded or stored in master files. The COOKIE option therefore belongs to transaction processing, not to a durable user directory.

The on-path boundary remains decisive. RFC 9018 states that an observer able to see plaintext DNS can capture a Server Cookie and abuse it during its valid lifetime. The server-side MAC prevents an off-path party without the secret from manufacturing arbitrary valid values. It does not encrypt the Cookie in transit or authenticate every actor able to observe and transmit on the path.

This is why a good control stack keeps the layers separate. DNS response matching, Cookie validation, transport choice, authenticated resolver access and application authorization may all contribute evidence. Their outputs should be correlated, not renamed as one universal “authentication” bit.

Build a receipt that preserves the boundary

For each Cookie decision, retain the server-visible source address, the client-visible address when available, a non-reversible reference to the Client Cookie, Server Cookie method and age, validation result, anycast validation set, retry sequence and TCP fallback outcome. Record secret-generation epochs and member rollout state separately so an operator can test infrastructure drift without exposing the secret itself.

If the service also authenticates an account or device, record that principal through its own method and timestamp. The join between identity and DNS transaction must be explicit: which authenticated session caused which resolver request, over what interval, and with what uncertainty when a shared resolver or NAT intervened. Absence of that join should remain absence, not be filled by a Cookie value.

The language in dashboards and alerts should match the evidence. “Valid return-path token” is accurate. “Previously reached this source context” can be accurate with the address and time attached. “Known customer”, “trusted device” and “authorised user” require facts the DNS Cookie does not contain.

Sources

  1. RFC 9018 — Interoperable Domain Name System (DNS) Server Cookies
  2. RFC 7873 — Domain Name System (DNS) Cookies
  3. RFC 5452 — Measures for Making DNS More Resilient against Forged Answers
  4. RFC 6891 — Extension Mechanisms for DNS (EDNS(0))