The Server Cookie is effectively a Message Authentication Code (MAC). The Server Cookie, when it occurs in a COOKIE option in a request, is intended to weakly assure the server that the request came from a client that is both at the source IP address of the request and using the Client Cookie included in the option. This assurance is provided by the Server Cookie that the server (or any other server from the anycast set) sent to that client in an earlier response and that appears as the Server Cookie field in the weakly authenticated request (see Section 5.2
of RFC 7873
DNS Cookies do not provide protection against "on-path" adversaries (see Section 9
of RFC 7873
). An on-path observer that has seen a Server Cookie for a client can abuse that Server Cookie to spoof request for that client within the time span a Server Cookie is valid (see Section 4.3
The Server Cookie is calculated from the Client Cookie, a series of Sub-Fields specified below, the Client IP address, and a Server Secret that is known only to the server or only to the set of servers at the same anycast address.
For calculation of the Server Cookie, a pseudorandom function is RECOMMENDED
with the property that an attacker that does not know the Server Secret, cannot find (any information about) the Server Secret, and cannot create a Server Cookie for any combination of the Client Cookie, the series of Sub-Fields specified below, and the client IP address, for which it has not seen a Server Cookie before. Because DNS servers need to use the pseudorandom function in order to verify Server Cookies, it is RECOMMENDED
that it be efficient to calculate. The pseudorandom function described in [SipHash-2-4
] and introduced in Section 4.4
of this document fits these recommendations.
Changing the Server Secret regularly is RECOMMENDED
but, when a secure pseudorandom function is used, it need not be changed too frequently. Once a month, for example, would be adequate. See Section 5
on operator and implementation guidelines for updating a Server Secret.
The 128-bit Server Cookie consists of the following Sub-Fields: a 1-octet Version Sub-Field, a 3-octet Reserved Sub-Field, a 4-octet Timestamp Sub-Field, and an 8-octet Hash Sub-Field.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
| Version | Reserved |
| Timestamp |
| Hash |
The Version Sub-Field prescribes the structure and Hash calculation formula. This document defines Version 1 to be the structure and way to calculate the Hash Sub-Field as defined in this section.
The value of the Reserved Sub-Field is reserved for future versions of server-side cookie construction. On construction, it MUST
be set to zero octets. On Server Cookie verification, the server MUST NOT
enforce those fields to be zero, and the Hash should be computed with the received value as described in Section 4.4
The Timestamp value prevents Replay Attacks and MUST
be checked by the server to be within a defined period of time. The DNS server SHOULD
allow cookies within a 1-hour period in the past and a 5-minute period into the future to allow operation of low-volume clients and some limited time skew between the DNS servers in the anycast set.
The Timestamp value specifies a date and time in the form of a 32-bit unsigned
number of seconds elapsed since 1 January 1970 00:00:00 UTC, ignoring leap seconds, in network byte order. All comparisons involving these fields MUST
use "Serial number arithmetic", as defined in [RFC 1982
]. [RFC 1982
] specifies how the differences should be handled. This handles any relative time window less than 68 years, at any time in the future (2038, 2106, 2256, 22209, or later.)
The DNS server SHOULD
generate a new Server Cookie at least if the received Server Cookie from the client is more than half an hour old, but it MAY
generate a new cookie more often than that.
It's important that all the DNS servers use the same algorithm for computing the Server Cookie. This document defines the Version 1 of the server-side algorithm to be:
Hash = SipHash-2-4(
Client Cookie | Version | Reserved | Timestamp | Client-IP,
Server Secret )
where "|" indicates concatenation.
Notice that Client-IP is used for hash generation even though it is not included in the cookie value itself. Client-IP can be either 4 bytes for IPv4 or 16 bytes for IPv6. The length of all the concatenated elements (the input into [SipHash-2-4
be either precisely 20 bytes in case of an IPv4 Client-IP or precisely 32 bytes in case of an IPv6 Client-IP.
When a DNS server receives a Server Cookie version 1 for validation, the length of the received COOKIE option MUST
be precisely 24 bytes: 8 bytes for the Client Cookie plus 16 bytes for the Server Cookie. Verification of the length of the received COOKIE option is REQUIRED
to guarantee the length of the input into [SipHash-2-4
] to be precisely 20 bytes in the case of an IPv4 Client-IP and precisely 32 bytes in the case of an IPv6 Client-IP. This ensures that the input into [SipHash-2-4
] is an injective function of the elements making up the input, and thereby prevents data substitution attacks. More specifically, this prevents a 36-byte COOKIE option coming from an IPv4 Client-IP to be validated as if it were coming from an IPv6 Client-IP.
The Server Secret MUST
be configurable to make sure that servers in an anycast network return consistent results.