Maybe someone would like to see the article.
Sony.
Sony has a rootkit.
The rootkit phones home.
Phoning home requires a DNS query.
DNS queries are cached.
Caches are externally testable (great paper, Luis!), provided you have a list of all the name servers out there.
It just so happens I have such a list, from the audits I've been running from http://deluvian.doxpara.com .
So what did I find?
Much, much more than I expected.
It now appears that at least 568,200 nameservers have witnessed DNS queries related to the rootkit. How many hosts does this correspond to? Only Sony (and First4Internet) knows...unsurprisingly, they are not particularly communicative. But at that scale, it doesn't take much to make this a multi-million host, worm-scale Incident. The process of discovering this has led to some significant advances in the art of cache snooping. Here are some of the factors I've dealt with:
Just because you *request* the disabling of recursion, doesn't mean it'll actually happen. A full 353,200 name servers had to be excluded from the final tally because not only would recursive queries emit from them whether or not they were desired, but they'd also notify their neighbors of the results.
Low TTL names exist, and are rather difficult to catch by cache snooping (they expire before you can find proof of life). However, they may be hosted by names that last much longer -- updates.xcp-aurora.com has a lifespan of an hour, but xcp-aurora.com's NS link to resolver1.first4internet.co.uk will last 150,000 seconds.
Some hosts lie -- captive portals, I'm looking at you. Simply filtering TTL's that are divisible by 100 has a way of eliminating most of them; after that, you're left with surprisingly few NS's that lie about IP
Some hosts lie -- captive portals, I'm looking at you. Simply filtering TTL's that are divisible by 100 has a way of eliminating most of them; after that, you're left with surprisingly few NS's that lie about IP