5 ms·

That is surprisingly high. Presumably the queries weren't actually made years ago. There are many possible explanations: incorrect DNS clients, incorrect system

by allenz 8y ago

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 8y ago
But if they timestamped the labels?
- kqr 8y ago
  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 8y ago
    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.

by allenz 8y ago

jacobush 8y ago

But if they timestamped the labels?

kqr 8y ago
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 8y ago
  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.