Summary

  • DNS Cookies are lightweight transaction state designed to make several off-path amplification, forgery and cache-poisoning attacks harder.
  • A valid Server Cookie weakly assures a server that a request came from the observed source address while carrying a Client Cookie seen in an earlier exchange.
  • The mechanism does not resist an on-path observer and does not name a user, subscriber, device owner or application principal behind a resolver or NAT.
  • Operations therefore need a DNS request-assurance receipt that keeps cookie validation, network observation, resolver identity and authorization as separate claims.

Consider a hypothetical abuse-control system. A household, office or carrier network sends DNS traffic through a shared recursive resolver. The resolver reaches an anycast service, receives a Server Cookie and later presents a valid one from the same public address. A downstream control system records the cookie as proof that the same customer made both requests. The protocol has established something narrower: the second request carries state that the server can validate against the Client Cookie, the observed source address, its secret and a time window.

RFC 7873 defines DNS Cookies as a lightweight DNS transaction-security mechanism. Their purpose is limited protection against denial-of-service amplification, answer forgery and cache poisoning by an attacker who cannot observe the exchange. That off-path condition is not a footnote. It is the boundary of the assurance.

A first request contains an eight-byte Client Cookie. Once the server replies, later requests can include both the Client Cookie and the Server Cookie. This lets the server reject or constrain traffic that cannot reproduce the state it issued. The mechanism can be incrementally deployed, works with NAT and can be used by anycast services without requiring every Internet client to possess a pre-arranged credential.

Those advantages explain why the RFC calls the mechanism a weak form of authentication rather than a client-identity system. An on-path router, bridge, shared-link participant or other observer that can see plaintext DNS traffic can also see the cookie. During the cookie's usable lifetime, that observer may replay what it has learned. The cookie therefore raises the cost for an off-path forger; it does not turn an observable bearer value into proof of a human or organisation.

RFC 9018 makes the Server Cookie construction interoperable. Version 1 combines the Client Cookie, version and reserved fields, a timestamp and the client's source IP address under a Server Secret. The client IP is an input to the calculation even though it is not carried inside the cookie value. A server verifies the result with the same secret.

This construction answers a precise server-side question: is the request consistent with a cookie previously produced for this Client Cookie and this observed address under a valid secret and time window? It does not answer who is using the address. Several users may share one recursive resolver. Several devices may appear behind one NAT address. A resolver process may restart, rotate its Client Cookie or move between addresses. Conversely, one public address can remain stable while the people and permissions behind it change.

Time is part of the evidence. RFC 9018 says the timestamp must be checked within a defined period and recommends accepting a window roughly one hour into the past and five minutes into the future. A server should renew a cookie once the received value is more than half an hour old. A valid timestamp limits replay; it is not a current authorization epoch for a subscriber account.

Anycast creates another distinction. Members of an anycast set need compatible Server Cookie construction and access to the secrets required to verify each other's output. RFC 9018 describes a three-stage rollover: distribute the new secret while continuing to generate with the old one; begin generating with the new secret while validating both; then retire the old secret after clients have had time to renew. A cookie accepted by a different member shows that the fleet shares a compatible validation state. It does not prove that the same physical server, resolver instance or end user returned.

Privacy rules reinforce the point. A client must create a new Client Cookie when its source address changes, and the specification warns that a client behind NAT may not know that its public address changed. Cookie continuity is therefore deliberately bounded by network context and implementation state. Treating it as a durable customer identifier would work against the privacy and mobility assumptions of the mechanism.

The stronger comparator is RFC 8945, which defines TSIG. TSIG authenticates a DNS transaction with a message authentication code between entities that already share a configured secret. It can establish that a dynamic update or response came from an approved party holding that key. This requires key distribution, key protection and a named trust relationship that DNS Cookies intentionally avoid.

Even TSIG has a defined boundary: it authenticates transmission between parties sharing a secret, not the truth or original provenance of every DNS record. DNS Cookies cannot inherit TSIG's stronger party authentication merely because both mechanisms use keyed calculations. One is lightweight anti-forgery state for broad deployment; the other is transaction authentication inside a pre-established trust relationship.

The operational error is to compress four observations into one identity flag. The Server Cookie may be valid. The source address may match the calculation. The request may still have traversed an observable path. The resolver may represent many users whose application permissions differ. A rate limiter can use the cookie as one anti-abuse signal without declaring that it has authenticated a customer.

A useful DNS request-assurance receipt would retain the layers. It would record the Client Cookie and Server Cookie version, timestamp and validation result; the source address observed by the server; the responding anycast member; the active Server Secret epoch; the transport and whether an on-path observer could see the exchange; the resolver instance when known; any separately authenticated principal; the authorization policy; and the action time. It would never store the secret itself.

This approach preserves the mechanism's value. Valid cookies can support rate limiting, reduce reflection opportunities and screen obviously forged requests before more expensive controls run. They can also expose secret-rollover or anycast-consistency failures. The gain comes from making the evidence legible, not from promoting it beyond its threat model.

Sources

RFC 7873 — Domain Name System (DNS) Cookies; RFC 9018 — Interoperable DNS Server Cookies; RFC 8945 — Secret Key Transaction Authentication for DNS.