UDP lets a sender place a source address in a datagram without a transport handshake that proves the sender can receive traffic at that address. DNS inherits that property when it runs over UDP. An off-path attacker can therefore send a query with a forged source address and try to make a DNS server direct its response toward another host.

DNS Cookies add a lightweight challenge-and-return mechanism inside EDNS. RFC 7873 defines the COOKIE option, while RFC 9018 tightens Server Cookie construction for interoperable deployments. The mechanism does not turn UDP into an authenticated transport. It gives DNS clients and servers additional evidence about whether a peer has participated in an earlier exchange at the relevant network address.

Two cookies serve different directions

A DNS COOKIE option can carry a Client Cookie alone or a Client Cookie followed by a Server Cookie.

The Client Cookie is generated by the client. RFC 7873 recommends deriving it with a pseudorandom function over the client IP address, server IP address, and a client secret. A client sends it with requests and checks that a response returns the expected value. This adds a transaction check beyond fields such as the DNS message ID.

The Server Cookie is generated by the server. Its construction binds server-only secret material to the request context, including the client address and Client Cookie. A client that receives it can cache it and include it in later requests to that server.

The resulting exchange is conceptually:

client -> server: Client Cookie
server -> client: Client Cookie + Server Cookie
client -> server: Client Cookie + Server Cookie

A valid Server Cookie tells the server that the requester possesses a value previously returned to the source-address context represented by that cookie. This is useful precisely because a blind source-address spoofer normally cannot receive the server’s reply at the forged address.

The server does not need a session table containing every issued cookie. RFC 9018 specifies a Server Cookie format whose authentication field is computed from a Server Secret, Client Cookie, client IP address, and cookie subfields.

That design lets the server recompute the expected authentication value when a later request arrives. Secret rotation can invalidate old values according to the server’s acceptance policy without creating a persistent session for each DNS client.

This stateless property matters for authoritative servers and other high-volume DNS infrastructure. The anti-spoofing signal does not require the server to allocate durable client state merely because an unsolicited UDP query arrived.

Invalid or absent cookies do not become universal rejection rules

DNS Cookies are designed for incremental deployment. A request without a COOKIE option cannot simply be assumed malicious because clients and intermediaries may not use the extension.

RFC 7873 therefore gives servers policy choices when a request carries only a Client Cookie. A server can discard it, return BADCOOKIE, or process it normally, subject to local policy such as rate limiting. If it responds, it supplies a Server Cookie so the client can move into the state where subsequent requests carry a value the server can validate.

An invalid Server Cookie is also treated as if the request did not contain a usable Server Cookie. It can result from spoofing, but it can also follow address changes, secret rotation, or inconsistent configuration across an anycast set.

Operational policy has to preserve that distinction. A failed cookie check is a signal for defensive handling, not proof of hostile intent.

DNS services commonly announce one address from multiple servers. A client may receive a Server Cookie from one node and send its next request to another node behind the same anycast address.

RFC 9018 addresses this by defining an interoperable Server Cookie construction. Servers participating in the same anycast service need compatible secret and algorithm handling if they are expected to validate cookies issued by their peers.

Poor coordination can surface as repeated BADCOOKIE responses even when the client is behaving correctly. Cookie validation therefore becomes part of the service’s shared operational state, alongside the routing behavior that can move successive packets between nodes.

NAT changes the identity available to the server

Many clients can appear behind one public IP address. Binding a Server Cookie only to that public address would allow one host behind the NAT to obtain a value usable for other hosts sharing the address.

The Client Cookie supplies additional separation. RFC 7873 includes it as an input to Server Cookie generation, so clients sharing one translated address can still present distinct cookie contexts.

This does not create a stable real-world identity for the client. It narrows the server’s check to the network address and Client Cookie context used to create the value.

The mechanism has explicit security limits

DNS Cookies provide limited protection against off-path attacks. They do not protect against an on-path adversary that can observe a valid Server Cookie and reuse it while it remains acceptable. They also do not replace DNSSEC: a cookie does not provide origin authentication or integrity for DNS record data in the way DNSSEC signatures do.

Rate limiting and other abuse controls remain relevant, especially for traffic that lacks a valid Server Cookie. The extension contributes a return-path signal that a server can use when deciding how much UDP response service to provide.

That narrow scope is its strength. DNS Cookies add a cheap, mostly stateless check to a protocol that often operates without a handshake, while leaving cryptographic data authenticity, transport confidentiality, and broader denial-of-service controls to mechanisms designed for those jobs.

Cybersecurity DNS DNS Cookies UDP Network Security