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.
On Dec 10, 2020, at 12:29 PM, Ray Bellis <ray@isc.org> 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
On Thu, Dec 10, 2020 at 05:29:46PM +0000, Ray Bellis <ray@isc.org> 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.
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
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
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
Fair enough - I was mostly asking if there was such a policy, rather than necessarily proposing that this should be the policy. 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
(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
I said it would be useful for probe up messages five years ago Col
On 10 Dec 2020, at 21:31, Edward Lewis <edlewisjr@cox.net> 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
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 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
+1 for 'your probe came back on-line' Regards, Grzegorz From: Edward Lewis <edlewisjr@cox.net> Date: Thursday 2020-12-10 at 22:32 To: "ripe-atlas@ripe.net" <ripe-atlas@ripe.net> Cc: Ed Lewis <edlewisjr@cox.net> Subject: [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
On 2020-12-10 22: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
Hi, (Not replying to individual messages, but to the thread in general) Thank you all for the trigger, we re-vived this issue and will come up with a reasonable solution "soon" - hopefully measured in weeks, not years :-) In many cases the trigger "your probe is down" itself resulted host action, tough I do appreciate that an automated "it's fine now" can also help. Regards, Robert
I "tamper" with my DNS to remove the massive amount of tracking and ad-serving domains that are so prevalent nowadays, but I do run my probe on a separate "untrusted" VLAN that allows direct dns requests out to the internet.
Hello, A couple of reflections from me: On 2020-12-10 18:29, 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) ?
I agree with others who said we shouldn't *exclude* these. However, given a workable definition, we can tag these probes which is likely to be helpful to everyone who are looking for an easy way to filter. As always, the devil is in the details: if we tag probes "now" that does not mean their behaviour was the same "yesterday". So one would need to align the probe tag times with result times, which complicates things.
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.
The difficulty is the same (or worse, see below) even if we do this on the server side :-) So while I don't think shifting the solution around makes things easier, as noted above it can be done "once" instead of by every client.
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.
Indeed, we (on the infrastructure side) can help here.
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$/, ...
(*) The *real* difficulty here is that these rules change over time, and the decoder needs to follow these changes (if it know about them...) This fact also makes the server side tagging susceptible to erroneous tagging. BTW this very rule set exists in our visualisations already (powering maps like https://atlas.ripe.net/results/maps/root-instances/). In reality it's 26 entries, not 13, in order to cover historical naming schemes. Unfortunately so far root server operators haven't converged on a single scheme, and even if they did, the historical queries would not be simplified. Cheers, Robert
participants (10)
-
Colin Johnston -
Edward Lewis -
Gert Doering -
Jared Mauch -
Massimo Candela -
Ponikierski, Grzegorz -
Rafael Possamai -
Ray Bellis -
Robert Kisteleki -
Stephane Bortzmeyer