DNS Cookies in BIND 9.10 and 9.11


DNS COOKIE is an Extended DNS (EDNS) option which, when both the client and server support it, allows the client to detect and ignore off-path spoofed responses, and the server to determine that a client's address is not spoofed. It is supported as an experimental compile-time option in BIND 9.10.3 and higher, under the name Server Identity Tokens (SIT), but it enabled by default in BIND 9.11.0.

  • To use it in the BIND 9.10 branch, build BIND with "configure --enable-sit". 
  • It is enabled by default for Windows builds from BIND 9.10.3 and higher
  • It is enabled in all builds from BIND 9.11.0 forward.
The COOKIE option is defined in RFC7873,"Domain Name System (DNS) Cookies".
Why would I want to use DNS Cookies?

Using cookies allows the client to do less work when sending queries, such as having to manage multiple sockets to get source port randomization, to prevent spoofed responses being received. DNS Cookie also allows a server to pick out legitimate repeat clients from a sea of spoofed-source queries, so long as the client supports the DNS Cookie option.  Some of these features that can make use of DNS Cookies are still under development.  They are also dependent on both client and server supporting the feature, however, support for DNS Cookies will increase along with the benefits available to those deploying them.  COOKIE, like all EDNS options, is theoretically incrementally and independently deployable, so as to encourage early adoption.

How does BIND use DNS Cookies?

In BIND 9.11.0, we use DNS Cookies to white-list known clients for Response Rate Limiting (RRL).  Client queries associated with valid Cookies will not be rate-limited. This makes rate limiting more effective in mitigating abusive traffic, because rate limiting is able to focus on only those client queries not associated with Cookies.

For DNS Cookies to be effective, both server and client need to support them

From BIND 9.11.0 DNS Cookie functionality is enabled by default and will be used by servers that deploy Response Rate Limiting.  Administrators that upgrade their Authoritative servers to BIND 9.11.0 will have this feature automatically enabled and used with their RRL configuration.  Administrators of Recursive servers that resolve queries on behalf of end user clients, when they upgrade to BIND 9.11.0, will be able to take advantage of DNS Cookies when communicating with Authoritative servers that also support their use.

What configuration options exist for DNS Cookies?

Please see the Administrator Reference Manuals (BIND 9.11.0 and newer) for more detail, but in summary:

  • send-cookie yes_or_no;
    (Default yes).  This is an option that is set globally or per-server and controls whether or not named will add a DNS COOKIE when sending queries to that server.  It also controls the expectations of the behavior of a remote server that has responded previously with support for DNS Cookies.  (In BIND 9.10 this was request-sit yes_or_no)
  • require-server-cookie yes_or_no;
    (Default no).  This controls how a server will respond to a COOKIE-aware client.
  • nocookie-udp-size number;
    Use this option if you need to change the default maximum UDP response size when responding to queries from clients that don't use DNS COOKIE (noting that max-udp-size may further limit the response size too)
  • cookie-secret secret-string;
    If you're running an anycast cluster, you can use this option to pre-set the server cookie string (instead of having it automatically generated at start-up)
  • cookie-algorithm algorithm-id;
    In the event that you want to change the way the default server COOKIE is generated at server start-up, this option changes the algorithm that is used.

What if my server supports DNS Cookies but other servers don't?
DNS servers that are properly compliant with regards to EDNS options (RFC6891), even if they don't support DNS Cookies, should simply ignore it.  The use of DNS Cookies is established by negotiation between the client and the server; if the negotiation does not take place then DNS Cookies will not be used and DNS queries and query responses will be sent and received as they would be before DNS Cookies were available.

If I want enable DNS Cookies on my server, is there anything else I need to do in my network infrastructure?

If you are running servers that are using load-balancing, proxying, firewalling or other similar solutions between your clients and your servers, then you need to confirm that those other devices will handle properly the EDNS COOKIE option and subsequent Cookie negotiation.   Use of Cookies is between two endpoints; this will very influence the design of your DNS deployment if you wish to take advantage of DNS Cookie.

I don't want to enable DNS Cookies on my servers; do I need to do anything?

We strongly advise anyone running Authoritative DNS services to check that they are providing RFC-compliant services.

You can test whether your servers fully support EDNS via: https://ednscomp.isc.org/

Because EDNS Cookie is being deployed by many DNS server and client code providers, your servers will increasingly be encountering this EDNS option in received queries.  You should ensure that your servers and any load-balancing, proxying and firewalling devices that you operate are fully compliant with (RFC6891).

Failure to support RFC6891 will cause DNS resolution failures and delays

This warning is primarily aimed at those running Authoritative DNS services.  Failure to respond appropriately to queries that contain EDNS options, whether or not they are options that your servers support, may mean that your customers are unable to reach your servers as a result of DNS resolution failures and delays.

COOKIE, like all EDNS options, is theoretically incrementally and independently deployable. Servers that don't know about an EDNS option are supposed to ignore it (RFC6891). In practice, this is not always the case; about 10% of servers (as of June 2016) mishandle queries with unknown EDNS options in various ways. This is not normally fatal for DNS COOKIE; it just results in slightly slower lookups from these servers.

Nevertheless, mishandling of the COOKIE option has been known to cause errors that are fatal to name resolution when the resolver is validating responses coming from a signed zone, and the authoritative server returns either FORMERR or BADVERS, or fails to respond to the query. named treats these answers as if the server does not support EDNS (which it doesn't) so it stops sending any EDNS queries at all, which makes it impossible to get a DNSSEC response back.  When testing against servers for the Alexa Top 1 Million names only a handful of servers behaved in this manner with signed zones, and the owners of these servers have been notified of the issue.

Mishandling of the COOKIE option can also trigger incorrect responses (such as NXDOMAIN or no NOERROR/NODATA, when there should have been a positive answer). This is usually caused by a misconfigured load-balancer.

I've enabled DNS Cookies on my Recursive Server and now I'm experiencing problems with some domains - what can I do?

Unfortunately, not all DNS server implementations are correct (this is not limited to support for EDNS - there are many circumstances in which Authoritative Servers respond improperly).

  • Use the server clause in named.conf to disable sending the DNS COOKIE option to servers that fail completely
  • In BIND 9.10.x the option to do this is "request-sit no;"
  • From BIND 9.11.0 onwards, it is "send-cookie no;"
How do I disable DNS Cookies on my server entirely?

We don't recommend doing this, except in extremis.  Most of the time, if you are running your servers correctly and professionally, the cause of your problems will lie elsewhere and should be addressed by other server administrators.  However, it is possible to disable the use of DNS COOKIE on your server entirely if you really need too (we hope that this is a temporary measure only):

  • You can globally disable sending the DNS COOKIE option within the Options statement in named.conf
  • In BIND 9.10.x the option to do this is "request-sit no;"
  • From BIND 9.11.0 onwards, it is "send-cookie no;"
What tools are available for testing for and confirming DNS Cookies support?

You can test whether your servers fully support EDNS via: https://ednscomp.isc.org/

By default, (new) dig will send requests with a DNS COOKIE option present. You can disable this with dig +nocookie.  

On receiving a BADCOOKIE response, dig will automatically retry with the correct cookie. You can disable this with with dig +nobadcookie.

You can see the DNS COOKIE values being used by named to talk to servers in the named_dump.db file in the "Address database dump" sections.