DNS cache snooping is a technique to find out what requests have been done to a caching DNS server by using the Time To Live (TTL) values in its answers. If you run a caching DNS server that is visible to the internet, with cache snooping, anyone can find out (to some extent) what domain names have been requested to the server, and when. For example, this can be used to track what websites have been visited.

The technique of DNS cache snooping is a pretty direct consequence of how the Domain Name System handles TTL values. Thus, it has been known to implementors, and some system administrators, for some time. Dan Bernstein’s Djbdns has had protection for this kind of attack for some time1); it was explicitly mentioned in this mailing list post from 2002. Back in 2003, I discovered this method myself, and subsequently wrote a tool to exploit it (see my 2004 weblog post). In 2004, Luis Grangeia was the first one who officially coined the term DNS cache snooping in his excellent research paper about the topic.

Grangeia’s research paper provides five interesting scenario’s of how DNS cache snooping could be used. I’m just going to quite from my original weblog post, which describes how it works in general, here.

To find out how this works, let’s talk about DNS a little. DNS is the telephone directory of the internet: it converts domain names such as www.google.com and home.wanadoo.nl (if http://blah/foo/bar is an URL, blah is the domain name) to server IP numbers such as . This is done by a program on a server run by your ISP, a DNS server. This so-called caching DNS server, in turn, gets its data from the DNS servers run by the people maintaining the domain names, e.g. the people running www.google.com run their own DNS servers. This is called authoritative DNS.

Now, to save resources, if the caching DNS server gets asked the same question more than once, it will just save the first answer rather than asking the authoritative DNS servers every time. This is what’s called caching. To know how long a caching DNS server may keep the data, the authoritative DNS server passes on a so-called TTL (Time To Live) to specify the expiration time of the data.

Now here’s the thing: when you ask a question to a caching DNS server, you will get its own TTL value, which is the original TTL value minus the time the caching DNS server has kept the data. If you compare this to the original TTL value from the authoritative DNS server, you find out the time when the caching server asked the authoritative one, due to a client query. It may have had the same query again later on, but you know that the domain has been visited at least then. One precaution is neccesary though: we need to ask the caching server not to bother doing any lookups for our own query: we don’t want our inquieries influencing themselves.

Now, that’s exactly what the dnstimeago tool I wrote does. Let’s look at some output:

[ examples]$
$ ./dnstimeago @10.0.0.2 -a 127.0.0.1 www.mokkels.com
-> www.mokkels.com.
Server 10.0.0.2#53                    said: domain not in cache
$ ./dnstimeago @10.0.0.2 -a 127.0.0.1 www.thehun.com
-> www.thehun.com.
Server 10.0.0.2#53                    answered: ttl=23h57m39
Server 62.250.2.2#53                  answered: ttl=1d
The domain www.thehun.com. was probably visited less than 2m21 ago.
$ ./dnstimeago @10.0.0.2 -a 127.0.0.1 www.sex.com
-> www.sex.com.
Server 10.0.0.2#53                    answered: ttl=1h31m29
Server #53             answered: ttl=2d
The domain www.sex.com. was probably visited less than 1d22h28m31 ago.
$ ./dnstimeago @10.0.0.2 -a 127.0.0.1 posadis.org
-> posadis.org.
Server 10.0.0.2#53                    answered: ttl=2h56m48
Server 5#53               answered: ttl=1d
The domain posadis.org. was probably visited less than 21h3m12 ago.

In this set up, 10.0.0.2 was the DNS server I wanted to check (my local net DNS server which forwards queries to the Wanadoo DNS servers, so the values are of the Wanadoo servers). More on the -a 127.0.0.1 later.

Whereas it seems www.mokkels.com has not been visited recently (one would want to find out the TTL value for www.mokkels.com to find out for at least how long, but my tool doesn’t do that), but www.thehun.com, pointing to The Hun’s Yellow Pages, has been visited pretty recently. posadis.org has been visited yesterday too, but that was probably just me :)

The weblog post has download links.

Now something about the -a 127.0.0.1 option I used in my examples. You can try without it first, but in some cases you’ll find it causes such messages as:

$ ./dnstimeago @10.0.0.2 posadis.org
-> posadis.org.
Server 10.0.0.2#53                    answered: ttl=2h24m24
*** query failed: No NS list in answer!

This is because the problem depends on the server being helpful in providing a pointer to the authoritative DNS servers. When I wrote the tool a year ago this was no problem, but nowadays the DNS servers of both my providers don’t do this anymore. The solution is to find a DNS server which does give this information. You can do this by running your own local DNS server (using Posadis, obviously :), and specifying the alternate DNS server with the -a option of dnstimeago.

Of course, the case of the ISP DNS server is not an extremely interesting one, though it is in itself a funny thing to poke around with. More interesting applications would be to check the DNS server of a local network, where you can actually get an idea who was visiting the web pages…

There are several ways to defend oneself against cache snooping.

The simplest method is not to allow queries from internet hosts. This can be achieved in Posadis with the listen configuration setting in the posadisrc.

If that’s not an option, specific work needs to be done by the DNS server to prevent this kind of attack. Grangeia suggest several methods to do this. One way, known to be implemented by djbdns, is to always return zero TTLs on answers. Still, the time it takes for a query to be done (if other servers need to be consulted, a query will take longer) provides some kind of indication of whether the domain name was already in cache, and for this method to work, a DNS server should not answer queries without the RD bit set at all. Another disadvantage is that a DNS server providing this defense can not be used by another forwarding DNS server.

• DNS Cache Snooping by Luis Grangeia is an excellent, in-depth research paper on this topic.
• Tracking surfing habits with DNS for fun and profit by Meilof Veeningen, quoted above, provides an overview of the technique, and presents the dnstimeago tool, which can be used to snoop data from DNS caches
• Snooping the DNS cache for fun and profit by Nicolas Bareil provides a similar tool called snoopdns to snoop a DNS cache.