This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/ripe-atlas@ripe.net/
[atlas] What is the meaning of 127.0.0.1 as probe resolver?
- Previous message (by thread): [atlas] What is the meaning of 127.0.0.1 as probe resolver?
- Next message (by thread): [atlas] Problem in status checks?
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Baptiste Jonglez
baptiste.jonglez at imag.fr
Mon Oct 16 10:48:02 CEST 2017
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 -------------- next part -------------- A non-text attachment was scrubbed... Name: atlas-delay-classification-30002.png Type: image/png Size: 298860 bytes Desc: not available URL: </ripe/mail/archives/ripe-atlas/attachments/20171016/0c65d7ed/attachment.png> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: </ripe/mail/archives/ripe-atlas/attachments/20171016/0c65d7ed/attachment.sig>
- Previous message (by thread): [atlas] What is the meaning of 127.0.0.1 as probe resolver?
- Next message (by thread): [atlas] Problem in status checks?
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]