[atlas] Probes suffering DNS interception?

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