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