Re: [atlas] Probe operator notifications
Hi, On Thu, Dec 10, 2020 at 04:31:48PM -0500, Edward Lewis wrote: > I do get the ???your probe went off-line??? notices. I would like ???your > probe came back on-line??? notices as well. If we had those, I may have > noticed it stayed down after the last message I saw. Yes, please!! I have voiced the wish for "back on-line notice" like two years ago, and was told "it's complicated"... well... doesn't have to be millisecond- accurate, but if it saves me driving to a remote location, a few minutes delay are not that bad. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature
Re: [atlas] Probe operator notifications
I said it would be useful for probe up messages five years ago Col > On 10 Dec 2020, at 21:31, Edward Lewis wrote: > > (Seeing the thread about DNS intercepted probes reminded me to send this:) > > For 5 or so years running I have a probe operating in my garage (behind my > home’s NAT and using the ISP’s NXDOMAIN rewriting, non-DNSSEC handling > recursive server) a run-of-the-mill home cable set up. > > When I got my November report, it said I’d been down the last half of > November. That was news to me. I then down'd/up’d it and it reconnected and > seems to be on-line again. > > I do get the “your probe went off-line” notices. I would like “your probe > came back on-line” notices as well. If we had those, I may have noticed it > stayed down after the last message I saw. > > Ed > > >
[atlas] Probe operator notifications
(Seeing the thread about DNS intercepted probes reminded me to send this:) For 5 or so years running I have a probe operating in my garage (behind my home’s NAT and using the ISP’s NXDOMAIN rewriting, non-DNSSEC handling recursive server) a run-of-the-mill home cable set up. When I got my November report, it said I’d been down the last half of November. That was news to me. I then down'd/up’d it and it reconnected and seems to be on-line again. I do get the “your probe went off-line” notices. I would like “your probe came back on-line” notices as well. If we had those, I may have noticed it stayed down after the last message I saw. Ed
Re: [atlas] Probes suffering DNS interception?
On 10/12/2020 17:59, Massimo Candela wrote:
>
> On 10/12/2020 18:36, Stephane Bortzmeyer wrote:
>
>> I disagree. The point of RIPE Atlas probes is to test the Internet AS
>> IT IS, not as we would like it to be.
>
> +1
Fair enough - I was mostly asking if there was such a policy, rather
than necessarily proposing that this should be the policy.
> If you have a way to automatically discover such probes, it would be
> useful to release the code on the github atlas community contrib.
I don't have a fully automated way (yet), but I do have a list of
regexes that appear to match all known correct variants of the various
RSO's hostname.bind strings with no false positives being returned from
the currently active Atlas probes:
'a': /^(?:rootns-|nnn1-)([a-z]{3})\d$/,
'b': /^b\d-([a-z]{3})$/,
'c': /^([a-z]{3})\d[a-z]\.c\.root-servers\.org$/,
'd': /^([a-z]{4})\d\.droot\.maxgigapop\.net$/,
'e': /^(?:[a-z]\d+)\.([a-z]{3}[a-z]?)\.eroot$/,
'f': /^([a-z]{3})(?:\d[a-z]|\.cf)\.f\.root-servers\.org$/,
'g': /^groot-?-(.*?)-.*?(\.net)?$/,
'h': /^\d+\.([a-z]{3})\.h\.root-servers\.org$/,
'i': /^s\d\.([a-z]{3})$/,
'j': /^(?:rootns-(?:el)?|nnn1-)([a-z]{3})\d$/,
'k': /^.*?\.([a-z]{2}-[a-z]{3})\.k\.ripe\.net$/,
'l': /^[a-z]{2}\.([a-z]{2}-[a-z]{3})\.l\.root$/,
'm': /^m-([a-z]{3})(-[a-z]+)?-\d$/
Ray
Re: [atlas] Probes suffering DNS interception?
On 10/12/2020 18:36, Stephane Bortzmeyer wrote: I disagree. The point of RIPE Atlas probes is to test the Internet AS IT IS, not as we would like it to be. +1 If you have a way to automatically discover such probes, it would be useful to release the code on the github atlas community contrib. Ciao, Massimo
Re: [atlas] Probes suffering DNS interception?
On Thu, Dec 10, 2020 at 05:29:46PM +, Ray Bellis wrote a message of 20 lines which said: > Is there any RIPE policy about whether nodes that are subject to DNS > interception should be excluded from results (or maybe even dropped > altogether) ? I disagree. The point of RIPE Atlas probes is to test the Internet AS IT IS, not as we would like it to be. (Otherwise, I would drop the probes behind NAT…) > While these probes are perhaps still useful for ping and traceroute > tests, they are effectively useless for DNS related tests other than as > a proxy measure for how prevalent that practise actually is. Which is an important use. > If there was a heuristic that could be applied on the probe itself or > within the RIPE data collector that tagged the probe as having "bad DNS" > that would help a lot. Adding a tag is indeed a good idea, but not excluding or dropping these probes.
Re: [atlas] Probes suffering DNS interception?
> On Dec 10, 2020, at 12:29 PM, Ray Bellis wrote: > > Is there any RIPE policy about whether nodes that are subject to DNS > interception should be excluded from results (or maybe even dropped > altogether) ? > > While these probes are perhaps still useful for ping and traceroute > tests, they are effectively useless for DNS related tests other than as > a proxy measure for how prevalent that practise actually is. > > For the visualisation I've just been building based on the Root System's > "hostname.bind" data returned by Atlas it was pretty difficult to figure > out how to exclude those probes on the client side. > > If there was a heuristic that could be applied on the probe itself or > within the RIPE data collector that tagged the probe as having "bad DNS" > that would help a lot. I think this is valuable, you can get an idea of what part of the population is being tampered with either by bad NETGEAR devices or otherwise. It’s clear you need to design something to measure for this, but I don’t think they should be automatically excluded. There are providers that do strange things like TTL lengthening which are problematic, but you often can’t see these non-compliant resolvers without a much more in-depth investigation. (No, I’m not talking about serve-stale either, that I think is a fine behavior). - Jared
[atlas] Probes suffering DNS interception?
Is there any RIPE policy about whether nodes that are subject to DNS interception should be excluded from results (or maybe even dropped altogether) ? While these probes are perhaps still useful for ping and traceroute tests, they are effectively useless for DNS related tests other than as a proxy measure for how prevalent that practise actually is. For the visualisation I've just been building based on the Root System's "hostname.bind" data returned by Atlas it was pretty difficult to figure out how to exclude those probes on the client side. If there was a heuristic that could be applied on the probe itself or within the RIPE data collector that tagged the probe as having "bad DNS" that would help a lot. cheers, Ray Bellis Director of DNS Operations, ISC.
