Re: [atlas] [Request] System tags for DNS resolution

On Thu, Nov 12, 2015 at 10:41:03AM +0100, Chris Amin wrote a message of 75 lines which said: > > For instance, probes 16659, 17072, 17620, 17854 use a resolver > > which yields a REFUSED for any request and probe 19948, 20065 one > > with systematic SERVFAIL. ... > The above

Re: [atlas] [Request] System tags for DNS resolution

> On 11 Nov 2015, at 17:36, Stephane Bortzmeyer wrote: > > [Is there a better way to record enhancement requests for Atlas? Atlas > has no public issue tracker, if I'm correct?] > > It would be cool to have system (automatic) tags for DNS resolution > because some probes are

Re: [atlas] [Request] System tags for DNS resolution

Hi Stephane, On 11/11/2015 17:36, Stephane Bortzmeyer wrote: > [Is there a better way to record enhancement requests for Atlas? Atlas > has no public issue tracker, if I'm correct?] You can also send requests to at...@ripe.net, where they will be automatically added to our issue queue. There's

Re: [atlas] [Request] System tags for DNS resolution

Hi Stephane, all, On 11-nov.-15 17:36, Stephane Bortzmeyer wrote: [Is there a better way to record enhancement requests for Atlas? Atlas has no public issue tracker, if I'm correct?] You are correct, to some extent -- there is a manual processing involved in the middle ;-) It's good that

[atlas] edst 193.0.0.228 in traceroute results

Hello, In https://atlas.ripe.net/measurements/2928258, I did a UDP traceroute. "edst":"193.0.0.228" from first hop and second hop somehow showed up in the results after the last hop that responded to traceroute, which should have been a reply to buil-in measurement to tt01.ripe.net. And under

[atlas] Architecture and firmware version filter in probe selection

It would be nice to be able to set architecture and firmware version criteria when selecting probes, making the results more consistent and avoid unnecessary measurements in certain cases. Yang