January 2023 - DNS | Cybersecurity

DNS Cookies: The Transaction Mechanism to Protect the Namespace

Although they are not the cure for all name server problems, DNS cookies offer an extra layer of protection and are particularly effective against off-path attacks. Simone Catania, InterNetX, looks at how DNS cookies can make DNS transactions more secure.

DNS Cookies: The Transaction Mechanism to Protect the Namespace-web

© Rutmer Visser| istockphoto.com

When the Domain Name System (DNS) was designed in the early 1980s, the Internet was only an academic project within a restricted pool of trusted users. Its rapid and exponential expansion over the past decades has made the Internet a global public utility network, subject to increasing abuse by malicious actors. Developing security mechanisms has become vital to the sustainable growth of the network of networks. Over the years, as the number of cyber attacks increased and new flaws in the DNS were found, the Internet community has developed new standardized security mechanisms: from best practices to minimize information exposure to protocols like DNSSEC, and encryption solutions to offer enhanced data and transaction security.

Included in the line of defense are DNS cookies, which can provide a certain degree of protection to DNS clients and servers, mostly against off-path attacks. No configuration is necessary and there is only one essential requirement: both parties in the transaction have to support DNS cookies. Learn about DNS cookies and how they offer special protection.

The DNS is a vulnerable system

The DNS has seen many updates since its conceptualization by Paul Mockapetris in 1983 and its standardization by the IETF in 1986. Although the DNS design is far from being 100 percent safe, there are several security protocols in place to enhance DNS data and transactions. 2008 marked a turning point with the discovery by Daniel Kaminsky of a fundamental flaw that allowed DNS cache poisoning on most name servers. Working with major companies, computer scientists have been working to solve the issues, developing a patch to make the exploitation of the vulnerability more complex. However, the problem has still not been fully resolved.

Available DNS security mechanisms

With the last paper published in 2005, DNSSEC is probably the main security extension. This protocol helps authenticate the data origin and provides authenticated denial of existence. This protocol is the best solution to prevent the manipulation or poisoning of responses to DNS requests, thereby protecting it against data and cache poisoning.

Nonetheless, the cryptographic computational load it requires can worsen some denial-of-service attacks and the increased size of the DNS response packets. TSIG (RFC2845) and SIG(0) (RFC 2931) aim to protect transaction security. The first one uses keyed hash authentication codes, while the latter uses public-key authentication to digitally sign DNS requests and transactions/responses. Another aspect to consider is that DNS uses the User Datagram Protocol (UDP) as the primary transport protocol. UDP does not offer an identity check and cannot provide any protection against spoofing attacks. Several measures reduce the cache poisoning rates between DNS clients and resolvers, such as source port randomization and 0x20 encoding, DNS-over-TCP, DNS-over-TLS (DoT) and DNS-over-HTTPS (DoH). To secure communication between a resolver and an authoritative server, DNSCurve uses elliptic curve cryptography. TLS/SSL and HTTPS encrypt the communication between client and server but only after the domain name resolution. They do not offer any protection in the DNS transmission to resolve the domain name.

These DNS protection mechanisms often operate on several levels for the most common DNS attack methods, offering specific protection to a single element or passage of communication. However, none of them provide the protection provided by DNS cookies. This makes them a unique mechanism able to operate on their own and for their specific purposes.

What are DNS cookies?

Now that we understand that DNS is not a secure system and that the current security systems do not offer complete protection, we can look at DNS cookies and learn how they operate.

So what is a DNS cookie? It is a lightweight DNS transaction security mechanism specified as an OPT record (RFC 6891) in DNS requests and responses. An OPT does not carry any DNS data since it only contains information about the question-and-answer sequence of a specific transaction. Their standardization paper RFC 7873 of May 2016 states they are 64-bit pseudorandom values and, since they operate an OPT RR option, they require the specification Extension Mechanisms for DNS (EDNS). DNS cookies are compatible with other DNS transaction security mechanisms and work with NAT and NAT-PT.

With regard to their lifetime, this may vary. Some DNS cookies last only a couple of minutes, while others live for days or weeks. At the same time, some DNS cookies might not change, even when the users connect to a VPN. It all depends on the DNS configurations.

What does a DNS cookie do for cybersecurity?

Let's be clear: DNS cookies are not the panacea to all problems but they do close a gap. They can provide an additional security layer to authenticate DNS requests and responses and thus play an essential role in enhancing the security threshold of the DNS. They are particularly successful at mitigating off-path attacks.

Client cookie vs. server cookie

When talking about DNS cookies, we need to clearly distinguish them based on who creates the cookie and consequently the client or server. On this basis, we can divide DNS cookies into two main categories:

  • Client cookies: made up of the client IP address, the server IP address, and a secret of at least 64 bits known to the client only.
  • Server cookies: consisting of the client IP address, at least a 64-bit secret changed periodically and the client cookie.

Note that the client and the server cookies are private to both parties. The idea is that they are only required to recognize their own DNS cookie for more security.

DNS cookies differ from regular cookies

Cookies have been used in HTTP connections for decades to store stateful information. Despite the similar name, DNS cookies are not related to browser cookies and require no JavaScript. This also means that clearing your browser's cookies and cache does not affect DNS cookies. While browser cookies can be "read" across different browsers and websites and divided into first-party and third-party cookies, this does not apply to DNS cookies. DNS cookies can also be read outside the web environment, e.g., to track conversion out of the website, such as in a mobile app.

What does a DNS cookie do and why use it?

The DNS generates a high number of UDP transactions and hackers often target them since they can be easily spoofed. This is where DNS cookies come into play. They ensure that the querier and server, the parties involved in DNS information exchange, know they are communicating with the right and valid partner.

The DNS cookie helps the client verify that the server includes the client-provided cookie in DNS transactions. This procedure ensures that no off-path attacker has spoofed requests and responses. Without DNS cookies, the client and server need to somehow ensure that they are talking to the right end of the connection and not with a malicious actor.

Deploying them is very easy. They do not need any configuration and are also low-cost and lightweight. Having DNS cookies in the communication does not hold any particular disadvantages but decreases the general vulnerability to specific threats. There is only one crucial aspect to consider: DNS cookies must be supported by both the querier and server. If implemented by only one side, they are ignored!

This is how DNS cookies are transmitted

DNS cookies follow a precise procedure within DNS communication. We will summarize this process in three steps.

1) The querier sends a query (OPT with a client cookie) to the server. The querier checks its cache and if it doesn't find any cookie for that particular server, it generates a new client cookie. The input contains the IP address, the server IP, and the secret self-generated by the client.

2) The server cannot do anything with the client cookie itself or get any security. So, it generates its server cookie for that specific client. Based on the pseudorandom function, the server will use the client IP, its random secret, and the client cookie as input. The server responds "normally," but it sends back the client and the server cookie on the OPT RR-Record section in the Extended DNS (EDNS) option. A safe query response contains an OPT with a client and server (DNS) cookie.

3) Now, the query goes back to the querier. It checks whether the received client cookie is valid. If it is not, the response does not come from the server it wanted to communicate with, so the querier can discard the response. In this case, a potential off-path attack has been prevented. Even if the attacker fakes the source IP of the server, the bogus response can be determined thanks to the client cookie.

What threats can DNS cookies protect against?

DNS cookies are particularly efficient against off-path attacks, which open off-path to intercept the DNS transaction and inject malicious content. The attacker is thus able to "read" the private transaction and edit the message before passing it to the intended recipient.

These are the three groups of attacks DNS cookies can protect from.

1. Denial-of-service (DoS) attacks on DNS servers

In the framework of a denial-of-service attack, DNS cookies can protect the server against forged requests and before any recursive queries or public key cryptographic operations.

Although DNS cookies do not provide direct protection against on-path attacks, which use correct source addresses that saturate a server with DNS requests, knowing the source IP addresses helps counteract such attacks, e.g. by contacting the attack origin networks and stopping them.

2. DNS amplification attacks

Forging DNS requests with a different source IP address will redirect the traffic and interfere with the service. Furthermore, the responses can be made longer to amplify the attack. In this case, DNS cookies can help limit the amplification of the attack.

3. DNS cache poisoning and answer forgery attacks

DNS cookies can reject forged replies when sending forged responses to a resolver. This prevents all those attacks that poison the name server's cache.

The DNS cookies adoption remains low

Since 2016, the deployment of DNS cookies has spread and many open-source DNS software vendors now support them. But an academic study published in 2021 aimed at analyzing DNS cookie use found that 30 percent of servers fully support cookies. Still, only 10 percent of recursive clients send cookies. This research indicates a relatively low level of adoption and minimal enforcement of DNS cookies today. Their relatively minimal impact is therefore attributed to the low adoption rate.

DNS cookies require more deployment

Although DNS cookies represent a weak authentication form for DNS requests and responses, they provide an additional layer of protection that, combined with other DNS security protocols such as DNSSEC, TSIG, and SIG(0), can significantly reduce cyber attacks on the global Internet.

To achieve a higher level of security, greater adoption and strategies for enforcement are required. The Internet community should look at enforcement strategies among clients and servers and encourage using cookies. Due to the diversified Internet ecosystem, universal adoption is extremely unlikely, but greater adoption in itself would result in more beneficial results for DNS and domains protection.


Simone Catania currently serves InterNetX as Global Content and Communications Manager. He is responsible for the content across InterNetX's blog and other channels and helps users understand the underpinning mechanisms behind the Internet. Simone is an ICANN fellow and member of EURALO and UASG.

Please note: The opinions expressed in Industry Insights published by dotmagazine are the author’s or interview partner’s own and do not necessarily reflect the view of the publisher, eco – Association of the Internet Industry.