[allenz]

That is surprisingly high. Presumably the queries weren't actually made years ago. There are many possible explanations: incorrect DNS clients, incorrect system clocks, automated scripts scraping into a DNS database, misconfigured embedded/IoT devices, etc.

[jacobush]

But if they timestamped the labels?

[kqr]

It's unclear what clock the labels were timestamped based on. Their article sort of indicates that it was the user clock, but I'd assume someone like APNIC would be smarter than that.

However, they did investigate further and as far as I can tell, the main reason for these insane numbers is the one second TTL they put on the records in the experiment. Some caches intent on efficiency will apparently keep re-quering for the record every second to have a fresh record to serve to their users.

So, basically, what they discovered was that

1. some queries are performed repeatedly without user involvement, which is hardly surprising; and

2. if ant-size your TTL, you can induce the amount of re-queries to increase compared to regular queries.

This is relatively obvious once you see the explanation, but I guess their point is that until you do see the explanation, the behaviour can appear extremely non-obvious and hard to predict.

(They also mention some hosts that seem to have as their sole purpose to perform queries for records someone has already accessed (i.e. the originators of requests are never behind these hosts). While that would generate a high number of zombies, I don't see how that – on its own – would lead to queries that happen months after the original event.)

[ggm]

its an NTP synced clock on our head servers. the DNS label is a wildcard cert backed 1x1 pixel so the name is of the form

XXX-TIME-IN-SECONDS-SINCE-1970-uNiquehash-experiment.dom.ain

We do get local clock feedback, but its not what we use to assign the time to an experiment

we're dumb: we're not that dumb.