On Fri, Oct 13, 2017 at 08:21:38PM +0200, Anand Buddhdev wrote:

On 13/10/2017 19:19, Baptiste Jonglez wrote:

Hi Baptiste,

...

While looking at the result of built-in DNS measurements that use the probe resolvers, I noticed that a significant fraction of probes have "127.0.0.1" as a resolver. And the results are strange: performance is really bad, for instance measurement 30002 gives a median resolution time of 300 ms for these probes!

What could be the meaning of this? It almost looks like a recursive resolver with no cache at all is running on the probes themselves.

I was looking at this measurement: https://atlas.ripe.net/measurements/30002/

And here are some example probes that exhibit this "127.0.0.1" symptom: 6001, 6087, 6162, 6235, 6308.

All these probes are actually RIPE Atlas anchors. They all run a caching recursive resolver, which can, and often is, used to perform DNS lookups for measurements running on these anchors.

Indeed, this is quite obvious now that you point it out. In the dataset I am using (measurement 30002), there are 287 "probes" using 127.0.0.1 as resolver, which roughly matches the current number of anchors (290).

The high latency in resolution could be for any number of reasons, so I can't immediately it.

In case you are interested, I have attached a plot of query latency over one week of DNS measurements, showing the behaviour across the different address types of the resolvers (global, RFC1918, RFC6598 shared addresses, and loopback). As you can see, the loopback resolver used by Atlas anchors has an incredibly bad latency! Baptiste