DNS cookies on servers in anycast clusters or behind load balancers

DNS cookies - what are they?

From RFC 7873:

DNS Cookies are a lightweight DNS transaction security mechanism that
provides limited protection to DNS servers and clients against a
variety of increasingly common denial-of-service and amplification/
forgery or cache poisoning attacks by off-path attackers.

They are a small amount of extra information carried in both query and response messages that help to ensure that two servers (or a client and a server) are the same two endpoints every time.

In BIND 9.11 and newer, DNS cookies are enabled automatically. This means that BIND will respond with a server cookie when queried by a client (which might be another DNS server or just a resolver stub) that supports this option. Similarly (when querying other servers) BIND, as a resolver, will offer a DNS cookie unless it has been configured not to do so, either globally or per server.

For more information about DNS cookies, please see:

• DNS cookies in BIND 9, an ISC knowledgebase article.
• RFC 7873, the RFC in which they are defined.
• RFC 9018, an RFC giving further detail.

Potential Interoperability Problems

Most of the time, clients and servers that support DNS cookies will happily interoperate with clients and servers that do not, and no special configuration options should be necessary. However, there is one specific scenario where DNS server operators may need to pay attention and possibly make configuration changes.

This scenario is the anycast or load-balanced cluster: specifically, one in which many servers are provisioned behind a single IP address. A client may query several different servers at different times, but they are presented to the client as a single server instance.

In that case, a client that supports DNS cookies may find that the cached server cookies appear to change arbitrarily, or that sometimes a server supports DNS cookies and other times does not.

Operating a Homogeneous Anycast or Load-balanced Cluster

If all of your DNS servers are running a version of BIND that supports DNS cookies, then it is possible to generate your own cookie secret that they all share - this will ensure that they all respond identically.

The default cookie algorithm is “siphash24.” Support for the cookie algorithm "AES" has been depreciated since BIND 9.18.21 and removed from BIND 9.18.20 and later. Both algorithms use a 128-bit secret.

One way to generate the secret is to make use of the system's source of randomness - typically /dev/random, but some operating environments might need /dev/urandom or /dev/prandom instead.

The following command (as an example) will generate 128 bits that can be used as a cookie-secret with "siphash24":

$ dd if=/dev/random bs=16 count=1 | od -x
1+0 records in
1+0 records out
16 bytes transferred in 0.000029 secs (550073 bytes/sec)
0000000	8217	891b	cbbc	a1b7	9030	69d2	0d20	c4c2
0000020

The generated bits can then be used in "named.conf" like this:

cookie-secret "8217891bcbbca1b7903069d20d20c4c2";

The advantage of generating cookie-secret locally is that you might, for ease of system administration, want to script a process for updating it periodically.

Another method for generating a secret string would be to use a publicly available source of randomness, such as random.org.

For information on siphash24 and AES, please see: https://www.random.org/cgi-bin/randbyte?nbytes=16&format=h

Operating a Heterogeneous Anycast or Load-balanced Cluster

If you run a mixture of DNS servers you may not be able to configure them to handle DNS cookies identically. Typically you might do this to introduce security by diversity, by deploying DNS services from several different software providers.

Unless it is causing operational problems you should be able to ignore the issue. Clients are supposed to handle multiple BADCOOKIE responses and switch to TCP: both named and dig will do this.

RFC 7873 says:

If the extended RCODE in the reply is BADCOOKIE and the Client Cookie in the reply matches what was sent, it means that the server was unwilling to process the request because it did not have the correct Server Cookie in it. The client SHOULD retry the request using the new Server Cookie from the response. Repeated BADCOOKIE responses to requests that use the Server Cookie provided in the previous response may be an indication that either the shared secrets or the method for generating secrets in an anycast cluster of servers is inconsistent. If the reply to a retried request with a fresh Server Cookie is BADCOOKIE, the client SHOULD retry using TCP as the transport, since the server will likely process the request normally based on the security provided by TCP (see Section 5.2.3).
Nevertheless some operators may wish to disable DNS Cookies on their BIND servers.

In all recent versions of BIND there is an option to disable server cookies:

answer-cookie no ;

How can I tell if I have a problem with DNS cookies on my anycast or load-balanced clustered servers?

As alluded to above, any problems encountered are likely to appear to be an intermittent issue when responding to clients. What happens is that clients that support DNS cookies have learned the server cookie of the first (or most recent) server in the cluster they communicated with. They then send that cookie again to the server cluster, which possibly directs the query to a different server in the set, resulting in it responding with BADCOOKIE (RCODE 23).

Since cookies are an extension to the DNS protocol, they are carried in the OPT pseudo section of DNS messages. This means that, in order to support cookies at all a server must first support EDNS.

There are a few ways to test whether servers support EDNS, which are discussed in this article.