DNS TTLs and their anonymity implications.

Nick Mathewson nickm at freehaven.net
Mon Jun 5 03:15:13 UTC 2006

So, as of, we're sending back meaningful TTL values for DNS
results for the first time.  There are some subtle issues, so I'll
braindump to the list in hopes that somebody can come up with a better

Here's a *bad* solution:  the exit server, when asked to resolve an
address for a user, remembers the TTL.  If asked again later, it
returns the original TTL, minus the amount of time that has passed.

Here's why that solution is bad: At noon, Alice asks for
mildly-embarassing.com; the exit node resolves it, and learns that the
TTL is one hour.  The exit node tells Alice the answer and "one hour"
for the TTL.  At 12:21:25, Bob asks for mildly-embarassing.com; the
exit node finds the answer in its cache, and sees that it has 39
minutes and 35 seconds left to live.  The exit node tells Bob the
answer and "39 minutes, 35 seconds" for the TTL.  From this, Bob can
deduce that somebody asked for m-e.com at noon sharp.  If Bob is
watching Alice, this may be enough to compromise her.

So here's what we're doing instead: Exit nodes tell users the exact
TTL they received, even if time has passed, but never cache a DNS
result for longer than MIN(TTL, 30 minutes).  This means that an
attacker can't infer the exact time when a result was requested.
This also means that users sometimes receive a stale entry.

Is this dumb?  Is there something *better* we should be doing instead?
(No need to tell us about equally dumb things we could be doing; we
know about several of those.)

Nick Mathewson
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 654 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20060604/dc3346c4/attachment.pgp>

More information about the tor-dev mailing list