DNS Cookie Demonstration

Identify Related Network Flows

DNS cookies use DNS caches as a side-channel to identify related network flows.

This is the javascript-free implementation. Click here for the javascript version.

Your DNS Cookie ID: DNS Cookie ID

Where can they be used?

They work with nearly any network application - web browsers, email clients, mobile applications, etc. No Javascript is required. As they do not depend on features provided by the browser, clearing a browser's cookies and cache has no effect.

How can they be used?

As with traditional HTTP cookies, DNS cookies can be used to track users on the web. They have no concept of "first party" or "third party" and can be read across different websites or from a different browser. They can also be used outside the web environment, for instance to track a web conversion which occurs after reading an email but not clicking on a link, or to track a sign-up in a mobile application after viewing a website. They also have application in DDoS mitigation - especially on IPv6 networks.

How uniquely do they identify a user?

It depends. A DNS server which uses the edns-client-subnet DNS extension can help ensure public recursive DNS servers cookie users more uniquely. Users sharing a local DNS cache (such as a home router or corporate firewall) will tend to receive the same DNS cookie.

How long can a DNS cookie last?

It depends on the DNS implementation. The size of the DNS clients's cache and the degree to which it respects the TTL will determine how long a DNS cookie lasts. Some configurations will provide a maximum lifetime of minutes, while others will allow a DNS cookie to persist for days or even weeks. Depending on how a system is configured, a DNS cookie may not change when a user's IP address changes, such as when they connect to a VPN.

How are they implemented?

A custom DNS server responds to requests with an IP chosen randomly from a pool of IP addresses. The IP address used by the client to connect to a particular DNS label is observed. With 2 IP addresses available in the pool, a 32-bit identifier requires 32 correlated connections. With 256 IP addresses, a 32-bit identifier requires only 4 correlated connections. Connections can be correlated using application layer strategies (e.g. a random number used in multiple HTTP requests), or using techniques such as TCP fingerprints. Using IPv6, it's easy to obtain a /64 of IP space - a 64-bit identifier requires observing only a single network connection.

How could this idea be extended?

More advanced implementations may:

  • Use DNS records with a variety of TTLs.
  • Use heuristics to select the DNS labels used to identify network flows.
  • Use timing information to identify cache hits and separate users in the same IPv4 /24.
  • Use APIs which provide direct access to DNS, rather than imputing the contents of the DNS cache.
  • Give special consideration to browser behaviours like DNS pinning and prefetching.
  • Not strictly randomize DNS responses - use heuristics to choose the ID assigned to a client.
  • Add a cryptographic signature to the cookie.
  • Use the caches of other middleboxes, such as transparent HTTP proxies.

In this demonstration, DNS cookies are not logged.