You are here: Home > Publications > RIPE Labs > Stéphane Bortzmeyer > Creating RIPE Atlas One-off Measurements with Blaeu

Creating RIPE Atlas One-off Measurements with Blaeu

Stéphane Bortzmeyer — 16 Apr 2018
There are several ways to create RIPE Atlas measurements, thanks to its API. Here, we present Blaeu, a set of tools to create one-off measurements, mostly to debug temporary issues.

Introduction

You know that RIPE Atlas is a wonderful system to make network measurements.  These small Atlas probes are distributed in many places and you can ask them to perform measurements for you. You can ping your server from many points in the world, you can traceroute from Japan or from Mexico, you can check your DNS data in many places. There are a lot of measurements possible. For instance, periodic measurements are done by researchers who want to study the evolution of something, or by people who manage a service and want to see its quality over the time (this is the case with DNSmon). Here, we focus on a different use, case, one-off measurements to help debugging network problems.

There are many tools to start and analyze such measurements. You can do it from RIPE Atlas Web site, or use the excellent official command-line tool. There are also many tools made available by various users. I developed my own tool because there were fewer tools at this time and because I had specific uses in mind. It is named Blaeu (from a famous Dutch cartographer, who made a great Atlas) and is hosted at Framagit, a Gitlab instance managed by a non-profit organisation. (Blaeu derives from a set of tools that were already presented here.)

To give you an idea of its possibilities, here are some uses of Blaeu. First, testing connectivity of a machine (here, a machine which hosts .fr whois server):

% blaeu-reach 2001:67c:2218:1b::51:99
5 probes reported
Test #12131694 done at 2018-04-13T10:36:10Z
Tests: 15 successful tests (100.0 %), 0 errors (0.0 %), 0 timeouts (0.0 %), average RTT: 47 ms

Blaeu performs the measurement, analyzes the results and present an aggregated view in one command. Here, everything is fine (no error or timeout).

A more complicated one, showing several options (a specific number of probes, and a specific Autonomous System to select them from, we now test the Framagit server). Note that this time the results are not perfect:

% blaeu-reach --requested 10 --as 3215 2a01:4f8:200:1302::42
9 probes reported
Test #12131719 done at 2018-04-13T10:39:43Z
Tests: 26 successful tests (89.7 %), 0 errors (0.0 %), 3 timeouts (10.3 %), average RTT: 111 ms

Blaeu can do of course other measurements than the "ping" one. Here is a traceroute from Bolivia to the .cz registry Web site:

% blaeu-traceroute --format --requested 1 --country BO --protocol ICMP 2001:1488:0:3::2 
Measurement #12131894 Traceroute 2001:1488:0:3::2 from BO uses 1 probes
1 probes reported
Test #12131894 done at 2018-04-13T10:53:13Z
From: 2800:cd0:d00:3f00:1ad6:c7ff:fe2a:17fc 6568 Entel S.A. - EntelNet, BO
Source address: 2001:470:d9eb:d100:1ad6:c7ff:fe2a:17fc
Probe ID: 32092
1 2001:470:d9eb:d100::1 6939 HURRICANE - Hurricane Electric LLC, US [1.487, 0.487, 0.514]
2 2001:470:d9eb:d1ce::3:2 6939 HURRICANE - Hurricane Electric LLC, US [0.931, 0.879, 0.967]
3 ['*', '*', '*']
4 ['*', '*', '*']
5 2001:1498:1:ab1::2 12956 TELEFONICA Telefonica Wholesale Network, ES [12.323, 12.431, 12.514]
6 2001:1498:1:ab2::1 12956 TELEFONICA Telefonica Wholesale Network, ES [12.401, 11.663, 11.724]
7 2001:1498:1::100:228 12956 TELEFONICA Telefonica Wholesale Network, ES [116.692, 116.085, 117.422]
8 2001:1498:1::100:137 12956 TELEFONICA Telefonica Wholesale Network, ES [128.969, 116.434, 116.897]
9 2001:1498:1:360::2 12956 TELEFONICA Telefonica Wholesale Network, ES [127.062, 115.917, 217.719]
10 2001:470:0:35f::2 6939 HURRICANE - Hurricane Electric LLC, US [157.623, 194.227, 138.577]
11 2001:470:0:114::2 6939 HURRICANE - Hurricane Electric LLC, US [140.666, 190.323, 140.224]
12 2001:470:0:299::2 6939 HURRICANE - Hurricane Electric LLC, US [147.01, 146.756, 146.532]
13 2001:470:0:2cf::1 6939 HURRICANE - Hurricane Electric LLC, US [239.022, 211.793, 212.055]
14 2001:470:0:419::2 6939 HURRICANE - Hurricane Electric LLC, US [228.66, 227.581, 226.618]
15 2001:7f8:14::e:4 NA NA [232.491, 232.686, 233.203]
16 2001:1488:800::97 25192 CZNIC-AS, CZ [234.247, 233.743, 233.684]
17 2001:1488:0:3::2 25192 CZNIC-AS, CZ [237.58, 237.761, 237.677]

Installation

You're convinced? You want to use them? You need a RIPE-NCC account and RIPE Atlas credits. If you don't have the RIPE-NCC account, you can easily create it gratis and automatically. If you don't have RIPE Atlas credits (Atlas "money", each measurement will cost you some credits), there are several ways to get them:

  • Host a RIPE Atlas probe (which is always a good idea, specially if you're in a network with few probes at this time), you can apply,
  • Become a RIPE LIR (a member of the RIPE, they get credits),
  • Ask a friend (me, for instance: I have credits, just tell me the address associated with the RIPE-NCC account.

We assume a Unix machine here (Blaeu has not been tested on anything else). Once you have the RIPE-NCC account, create an API key and put it in a file named $HOME/.atlas/auth (and of course chmod go-rx this file, the key must be kept secret).

You can then install Blaeu. There are currently two ways, one where you install the dependencies before and one which is automatic (but may conflict with the way you manage packages on your machine). Let's start with the automatic one. Blaeu is written in Python and requires Python 3 minimum, as well as the pip3 tool (on Debian, it is in the python3-pip package). Then, just run:

% pip3 install blaeu
Collecting blaeu
Downloading blaeu-1.1.0.tar.gz
Collecting cymruwhois (from blaeu)
Downloading cymruwhois-1.6-py3-none-any.whl
...
Installing collected packages: cymruwhois, pycparser, cffi, six, idna, asn1crypto, cryptography, pyopenssl, blaeu
Successfully installed asn1crypto-0.24.0 blaeu-1.1.0 ...

Then, Blaeu should run:

% blaeu-reach --help
...

--verbose or -v : makes the program more talkative
--help or -h : this message
...

If you get command not found: blaeu-reach or something like that, and if you have never used the Python pip tool before, it probably means your PATH does not include the place where pip installs the programs. If you do not run pip as root, this place will typically be $HOME/.local/bin, which needs to be added to your PATH.

The other way to install Blaeu is to install the dependencies yourself, using the packaging system of your choosing. For instance, on Debian, the packages to install are python3-pip python3-openssl python3-cymruwhois Once installed, you can run a pip3 install --no-deps blaeu which will have only to install my program.

You can now run your first measurement:

% blaeu-reach 9.9.9.9 
5 probes reported
Test #12132153 done at 2018-04-13T11:29:08Z
Tests: 15 successful tests (100.0 %), 0 errors (0.0 %), 0 timeouts (0.0 %), average RTT: 42 ms

If there is a problem at the installation, if the command above does not work, write a comment here, or send me an email, or file an issue at Framagit. Just remember to be specific and to describe exactly what you did, the actual messages you got, and the output of blaeu-reach --version.

Usage

Now, let's see the details of the usage. Blaeu programs have generic options (the same for all programs) and specific options (specific to one program). We'll begin with the generic ones, using blaeu-reach, the program to test with ICMP echo packets (like ping does). Running blaeu-reach with the option --help allows to see all options.  First, the probe selection options. You can ask for a given number of probes (you get five by default) and you can select them based on:

  • the area (continent) or the country (useful for testing national censorship),
  • the Autonomous System (useful for testing problems specific to one operator),
  • the IP prefix (not so useful because you have to indicate a prefix which is in the global routing table),
  • a former measurement (which is very useful when you fixed a problem and want to run the exact same test),
  • a list of probes that you select yourself.

All Blaeu programs use long options (starting with two dashes such as --prefix) but have also short options (starting with one dash such as -f for the prefix). In this article, I'll use only the long options because they are self-documented. Let's see a first example where we test with fifty probes from America (area West). We will use the IP address of a RIPE Anchor, which are precisely here to be used as targets.

Ping

% blaeu-reach --requested 50 --area West 2001:67c:217c:4::2
50 probes reported
Test #12133103 done at 2018-04-13T12:39:41Z
Tests: 144 successful tests (96.0 %), 0 errors (0.0 %), 6 timeouts (4.0 %), average RTT: 124 ms

Note that we used an IP address as argument. Blaeu typically does not accept domain names because there can be several IP addresses for each name. Since Blaeu is a debugging tool, it tries to be precise, not user-friendly. You can always use the wonders of the Unix shell:

% blaeu-reach --requested 50 --area West $(dig +short +nodnssec AAAA fr-par-as20766.anchors.atlas.ripe.net) 
47 probes reported
Test #12133239 done at 2018-04-13T12:44:16Z
Tests: 139 successful tests (100.0 %), 0 errors (0.0 %), 0 timeouts (0.0 %), average RTT: 130 ms

An interesting feature of RIPE Atlas is the system of tags which are attached to the probes. Some tags are put automatically by Atlas, following active tests, and some are put by the user who installed and manages the probe. Blaeu use the system tags, the automatic tags to select only probes that are themselves working. For instance, if you run Blaeu with --verbose, you will see the JSON data sent to Atlas, including the tags:

% blaeu-reach --verbose $(dig +short +nodnssec AAAA se-sto-as8674.anchors.atlas.ripe.net) 
{'probes': [{'value': 'WW', 'tags': {'include': ['system-ipv6-works']}, 'type': 'area', 'requested': 5}], 'definitions': [{'description': 'Ping 2a01:3f0:0:60::5', 'packets': 3, 'af': 6, 'target': '2a01:3f0:0:60::5', 'size': 64, 'type': 'ping'}], 'is_oneoff': True}
Measurement #12133297 to 2a01:3f0:0:60::5 uses 5 probes
5 probes reported
Test #12133297 done at 2018-04-13T12:49:46Z
Tests: 15 successful tests (100.0 %), 0 errors (0.0 %), 0 timeouts (0.0 %), average RTT: 65 ms

We see here that Blaeu, detecting we wanted to test an IPv6 address, automatically added the system tag system-ipv6-works. But you can also request more tags. For instance, here, we want only probes connected through ADSL:

% blaeu-reach --verbose --include adsl $(dig +short +nodnssec AAAA se-sto-as8674.anchors.atlas.ripe.net) 
{'is_oneoff': True, 'probes': [{'tags': {'include': ['adsl', 'system-ipv6-works']}, 'value': 'WW', 'type': 'area', 'requested': 5}], 'definitions': [{'target': '2a01:3f0:0:60::5', 'type': 'ping', 'description': 'Ping 2a01:3f0:0:60::5', 'af': 6, 'packets': 3, 'size': 64}]}
Measurement #12133459 to 2a01:3f0:0:60::5 uses 5 probes
5 probes reported
Test #12133459 done at 2018-04-13T12:54:55Z
Tests: 15 successful tests (100.0 %), 0 errors (0.0 %), 0 timeouts (0.0 %), average RTT: 50 ms

Here, the tag adsl was added so all probes selected are connected to the Internet through ADSL. Do note that user tags are a form of "crowd-tagging" so are not always perfectly managed and maintained.

RIPE Atlas allows to select probes on the basis of a previous measurement. It is very useful if you made a test and want to retry it after changing things. Use the option --old_measurement for that:

% blaeu-reach --old_measurement 12133103 2001:67c:217c:4::2 
48 probes reported
Test #12156157 done at 2018-04-14T16:46:04Z
Tests: 141 successful tests (97.9 %), 0 errors (0.0 %), 3 timeouts (2.1 %), average RTT: 128 ms

Some generic options have a meaning only for some programs. This is the case of --size (it sets the size of the test packets) which is useful only for some of the Blaeu programs, including blaeu-reach:

% blaeu-reach --size 1400 $(dig +short +nodnssec AAAA se-sto-as8674.anchors.atlas.ripe.net) 
5 probes reported
Test #12134781 done at 2018-04-13T13:59:32Z
Tests: 15 successful tests (100.0 %), 0 errors (0.0 %), 0 timeouts (0.0 %), average RTT: 66 ms

Let's see now the specific options. One, --tests, specifies the number of tests (the number of ICMP echo packets sent):

% blaeu-reach --requested 10 --tests 1 1.1.1.1 
10 probes reported
Test #12134867 done at 2018-04-13T14:04:49Z
Tests: 10 successful tests (100.0 %), 0 errors (0.0 %), 0 timeouts (0.0 %), average RTT: 21 ms

The default value is three, which explains why, in the previous examples, blaeu-reach displayed more tests than the number of probes.

Another specific option, useful when there are more tests than probes, is to display results per probe and not per test, in order to see if the problem is because of packets dropped at random (buffers full, for instance) or if there is a general problem with some probes. Previously, we saw that measurement #12133103 had 4% of failures. Let's use the generic option --measurement-ID to redisplay its results (usage of Blaeu with the option requires no credits since we don't run a new measurement):

% blaeu-reach --measurement-ID 12133103 2001:67c:217c:4::2
Test #12133103 done at 2018-04-13T12:39:41Z
Tests: 144 successful tests (96.0 %), 0 errors (0.0 %), 6 timeouts (4.0 %), average RTT: 124 ms

Are the six timeouts distributed among all the Atlas probes? Let's try with --by_probe:

% blaeu-reach --measurement-ID 12133103 --by_probe 2001:67c:217c:4::2
Test #12133103 done at 2018-04-13T12:39:41Z
Tests: 48 successful probes (96.0 %), 2 failed (4.0 %), average RTT: 124 ms

No, the problem was not evenly distributed: two probes systematically fail. We can display their IDs:

% blaeu-reach --measurement-ID 12133103 --by_probe --displayprobes 2001:67c:217c:4::2 
Test #12133103 done at 2018-04-13T12:39:41Z
Tests: 48 successful probes (96.0 %), 2 failed (4.0 %), average RTT: 124 ms
[6264, 33230]

And now that we know that probes #6264 and #33230 cannot reach 2001:67c:217c:4::2 despite the fact they have the tag system-ipv6-works, we can investigate, contact their maintainers, etc. An obvious possible investigation is to use blaeau-traceroute, presented in the next section.

Traceroute

So, probe #6264 is not able to ping 2001:67c:217c:4::2? Let's traceroute from it to see what's going on:

% blaeu-traceroute --probes 6264 --format 2001:67c:217c:4::2 
Measurement #12155876 Traceroute 2001:67c:217c:4::2 uses 1 probes
1 probes reported
Test #12155876 done at 2018-04-14T16:09:14Z
From: 2606:2800:4020:c::a 15133 EDGECAST - MCI Communications Services, Inc. d/b/a Verizon Business, US
Source address: 2606:2800:4020:c::a
Probe ID: 6264
1 2606:2800:4020:c::1 15133 EDGECAST - MCI Communications Services, Inc. d/b/a Verizon Business, US [0.471, 0.336, 0.296]

 We did not went very far… This probe, although tagged as having working IPv6, cannot reach the outside world, at least for some IPv6 prefixes. This is sad, so let's test with a more beautiful traceroute:

% blaeu-traceroute --requested 1 --format 2001:4b98:dc0:41:216:3eff:fe27:3d3f
Measurement #12155929 Traceroute 2001:4b98:dc0:41:216:3eff:fe27:3d3f uses 1 probes
1 probes reported
Test #12155929 done at 2018-04-14T16:17:21Z
From: 2003:ed:2bef:bf01:c225:e9ff:fea8:48ea 3320 DTAG Internet service provider operations, DE
Source address: 2003:ed:2bef:bf01:c225:e9ff:fea8:48ea
Probe ID: 34547
1 2003:ed:2bef:bf01::1 3320 DTAG Internet service provider operations, DE [1.57, 0.685, 0.657]
2 2003:ed:2bbf:2fc7::1 3320 DTAG Internet service provider operations, DE [9.024, 8.757, 9.111]
3 2a02:e5c:8:4::2 NA NA [15.002, 14.945, 14.963]
4 2a02:e5c:8:4::1 NA NA [14.577, 14.576, 14.269]
5 2a02:e5c:0:c::1 NA NA [27.2, 27.295, 27.083]
6 ['*', '*', '*']
7 2001:4b98:dc2:1f::1:601 29169 GANDI-AS Domain name registrar - http://www.gandi.net, FR [23.848, 23.359, 23.387]
8 2001:4b98:dc2:1f::c502:2 29169 GANDI-AS Domain name registrar - http://www.gandi.net, FR [27.492, 24.741, 25.991]
9 2001:4b98:dc5::3 203476 GANDI-AS-2 Domain name registrar - http://www.gandi.net, FR [28.061, 27.772, 27.914]
10 ['*', '*', '*']
11 ['*', '*', '*']
12 ['*', '*', '*']
13 ['*', '*', '*']
14 ['*', '*', '*']
255 ['*', '*', '*']

This is better. We go through several Autonomous Systems (--format displays the AS number, here 3320 at the beginning, DTAG, then 29169, ndi). But there is still an issue at the end. Don't panic, Atlas traceroute can use several layer 4 protocols, by default it is UDP and the local firewall at the destination machine drops it. Let's use another one, with --protocol:

% blaeu-traceroute --requested 1 --format --protocol ICMP 2001:4b98:dc0:41:216:3eff:fe27:3d3f 
Measurement #12155946 Traceroute 2001:4b98:dc0:41:216:3eff:fe27:3d3f uses 1 probes
1 probes reported
Test #12155946 done at 2018-04-14T16:19:35Z
From: 2001:4dd0:40fa:1:a62b:b0ff:fef9:d602 8422 NETCOLOGNE, DE
Source address: 2001:4dd0:40fa:1:a62b:b0ff:fef9:d602
Probe ID: 29405
1 2001:4dd0:40fa:1:3a10:d5ff:fe1f:1737 8422 NETCOLOGNE, DE [1.251, 0.658, 0.609]
2 2001:4dd0:a2a:40::4acc 8422 NETCOLOGNE, DE [13.098, 12.68, 12.593]
3 2001:4dd0:a2b:80:dc40::a 8422 NETCOLOGNE, DE [11.787, 11.848, 11.876]
4 2001:4dd0:a2b:47:dc40::c 8422 NETCOLOGNE, DE [36.975, 11.6, 11.531]
5 2001:4dd0:a2b:11:dc41::b 8422 NETCOLOGNE, DE [13.54, 25.942, 11.786]
6 ['*', '*', '*']
7 2001:4b98:dc2:1f::1:601 29169 GANDI-AS Domain name registrar - http://www.gandi.net, FR [35.004, 34.475, 34.497]
8 2001:4b98:dc2:1f::c502:2 29169 GANDI-AS Domain name registrar - http://www.gandi.net, FR [35.377, 37.904, 37.858]
9 2001:4b98:dc5::3 203476 GANDI-AS-2 Domain name registrar - http://www.gandi.net, FR [35.877, 35.523, 34.456]
10 2001:4b98:dc0:41:216:3eff:fe27:3d3f 29169 GANDI-AS Domain name registrar - http://www.gandi.net, FR [34.911, 35.653, 34.436]

This time, we go to the final destination.

Being able to use another protocol is very useful when you are faced with strict firewalls, that drop UDP test packets or ICMP echo packets. This is the basic idea behind TCP ping: use TCP SYN packets as test packets. Let's see with a machine that seems unreachable (Atlas' Web site):

% blaeu-reach 193.0.6.158
5 probes reported
Test #12156012 done at 2018-04-14T16:28:41Z
No successful test

This is not a problem with the probes, it's simply that the destination drops our packets. Let's use TCP ping. We rely on the option --first_hop to set the TTL of the test packet large enough to reach the machine, and we set the size of the test packet to zero, because this is the size of the payload of a TCP SYN packet (if you don't use TCP Fast Open):

% blaeu-traceroute --protocol TCP --size=0 --port=443 --first_hop=64 --format 193.0.6.158 
Measurement #12156079 Traceroute 193.0.6.158 uses 5 probes
5 probes reported
Test #12156079 done at 2018-04-14T16:34:48Z
From: 82.226.100.240 12322 PROXAD, FR
Source address: 192.168.4.15
Probe ID: 17140
64 193.0.6.158 3333 RIPE-NCC-AS Reseaux IP Europeens Network Coordination Centre (RIPE NCC), NL [50.925, 50.491, 50.297]

From: 82.146.76.79 16185 RINGNETT-NORWAY RingNett AS Autonomous System, NO
Source address: 82.146.76.79
Probe ID: 27685
64 193.0.6.158 3333 RIPE-NCC-AS Reseaux IP Europeens Network Coordination Centre (RIPE NCC), NL [31.21, 31.346, 31.187]

From: 80.114.220.117 9143 ZIGGO Ziggo B.V., NL
Source address: 192.168.254.253
Probe ID: 31270
64 193.0.6.158 3333 RIPE-NCC-AS Reseaux IP Europeens Network Coordination Centre (RIPE NCC), NL [14.954, 16.237, 15.407]

From: 78.213.76.90 12322 PROXAD, FR
Source address: 192.168.1.15
Probe ID: 34571
64 193.0.6.158 3333 RIPE-NCC-AS Reseaux IP Europeens Network Coordination Centre (RIPE NCC), NL [70.329, 60.118, 53.655]

From: 37.201.225.223 6830 LGI-UPC formerly known as UPC Broadband Holding B.V., AT
Source address: 192.168.178.32
Probe ID: 34928
64 193.0.6.158 3333 RIPE-NCC-AS Reseaux IP Europeens Network Coordination Centre (RIPE NCC), NL [26.306, 38.502, 22.256]

And that's all! We have tested the connectivity of a HTTPS server despite the fact it refused ICMP and UDP. If the server had been down, or not responding on this port, we would have lines 64 ['*', '*', '*']

DNS

Some network guys may think that once ping and traceroute work, everything is fine. But no: every action on the Internet requires DNS answers. Being without DNS is like being without Internet. (If you think that you can visit any Web site by typing its IP address in the address bar of the browser, think twice.) Although being conceptually in the layer 7 of the OSI model, DNS is part of the infrastructure. It provides no value for the end-user but, without it, nothing will work. So, the network administrator must consider DNS as well.

RIPE Atlas probes can do DNS requests. Let's try:

% blaeu-resolve mamot.fr 
[2001:67c:288::14] : 5 occurrences
Test #12149872 done at 2018-04-14T07:55:43Z

Cool, it works, the five probes (the default value, you can use the generic option --requested if you want more) yield the same result. Note that it is not an error if they don't, it can be some sort of geo-targeting:

% blaeu-resolve gmail.com
[2a00:1450:400a:804::2005] : 1 occurrences
[2a00:1450:4006:802::2005] : 1 occurrences
[2a00:1450:400f:80a::2005] : 1 occurrences
[2a00:1450:4009:815::2005] : 1 occurrences
[2a00:1450:401b:804::2005] : 1 occurrences
Test #12155836 done at 2018-04-14T16:04:11Z

What if there is no data of the requested type?

% blaeu-resolve github.com
[] : 5 occurrences
Test #12155851 done at 2018-04-14T16:06:27Z

What? Github has no address? Yes, but you have to remember that Blaeu, by default, requests DNS records of type AAAA (IPv6 addresses) and Github still does not have IPv6 connectivity. Let's change the requested type:

% blaeu-resolve --type A github.com 
[192.30.253.112 192.30.253.113] : 5 occurrences
Test #12155870 done at 2018-04-14T16:08:47Z

--type is one of the many DNS specific options of Blaeu. Let's see a few others and remember you can always use --help to see them all. By default, we query the probe's default resolver(s). But you can indicate another name server, with --nameserver,  for instance here we test the anycasted name server d.nic.fr (something that the .fr registry often does, to assess the quality of the service it provides):

% blaeu-resolve --nameserver d.nic.fr --requested 10 --type SOA fr 
Nameserver d.nic.fr
[nsmaster.nic.fr. hostmaster.nic.fr. 2225046998 3600 1800 3600000 5400] : 9 occurrences
Test #12155933 done at 2018-04-14T16:17:48Z

Nine probes were able to get the SOA record from this server. (Ten were requested, but one did not reply in time.) Like many name servers, d.nic.fr is anycasted so the DNS answers were actually sent by different machines. Option --nsid lets us know which ones:

% blaeu-resolve --nameserver d.nic.fr --requested 10 --nsid --type SOA fr 
Nameserver d.nic.fr
[NSID: b'dns.ams.nic.fr' nsmaster.nic.fr. hostmaster.nic.fr. 2225046998 3600 1800 3600000 5400] : 1 occurrences
[NSID: b'dns.lon.nic.fr' nsmaster.nic.fr. hostmaster.nic.fr. 2225046998 3600 1800 3600000 5400] : 2 occurrences
[NSID: b'dns.ix1.nic.fr' nsmaster.nic.fr. hostmaster.nic.fr. 2225046998 3600 1800 3600000 5400] : 1 occurrences
[NSID: b'dns.fra.nic.fr' nsmaster.nic.fr. hostmaster.nic.fr. 2225046998 3600 1800 3600000 5400] : 2 occurrences
[NSID: b'dns.th2.nic.fr' nsmaster.nic.fr. hostmaster.nic.fr. 2225046998 3600 1800 3600000 5400] : 1 occurrences
[NSID: b'dns.lyn.nic.fr' nsmaster.nic.fr. hostmaster.nic.fr. 2225046998 3600 1800 3600000 5400] : 1 occurrences
[NSID: b'dns.bru.nic.fr' nsmaster.nic.fr. hostmaster.nic.fr. 2225046998 3600 1800 3600000 5400] : 2 occurrences
Test #12155944 done at 2018-04-14T16:19:21Z

We see seven different instances of this server (I let you guess the naming scheme). 

The --nameserver option is useful if you want to test the DNS service of a given server during a problem. Here, the network of a big registrar experienced trouble, as shown by the problem of the secondary name server they provide to customers:

% blaeu-resolve --requested 100 --nameserver 217.70.177.40 --type SOA franceix.net
Nameserver 217.70.177.40
[ns.franceix.net. noc.franceix.net. 2018040914 86400 3600 604800 10800] : 3 occurrences
[TIMEOUT] : 96 occurrences
Test #12159079 done at 2018-04-14T19:12:37Z

Only three probes among one hundred got an answer.

In theory, DNS should give you the same results from any place. One of the reasons that it is not true is national censorship. This is a case where RIPE Atlas probes are necessary, because they can see the DNS from many vantage points. Here is an use of option --country to select probes in a given country:

% blaeu-resolve --country FR --requested 20 --type A Libertyland.co 
[127.0.0.1] : 6 occurrences
[ERROR: SERVFAIL] : 1 occurrences
[104.27.186.25 104.27.187.25] : 12 occurrences
Test #12159110 done at 2018-04-14T19:17:25Z

This domain is censored in France for illegal sharing. We see that some RIPE Atlas probes get the correct answer(s), 104.27.186.25 104.27.187.25, but others get a fake 127.0.0.1. Speaking of censorship measurement, be careful if you request Atlas probes from some countries, you may endanger the Atlas host.

By default, RIPE Atlas probes use their local resolver. Sometimes, it validates with DNSSEC, somestimes not. Let's check with a deliberately broken domain:

% blaeu-resolve --requested 20  --type SOA servfail.nl 
Measurement #12156100 for servfail.nl/SOA uses 20 probes
[li1.forfun.net. hostmaster.forfun.net. 1508335121 86400 7200 2419200 60] : 9 occurrences
[ERROR: SERVFAIL] : 11 occurrences
Test #12156100 done at 2018-04-14T16:36:18Z

Approximately half of the probes used a validating resolver, thus getting SERVFAIL since the domain is really broken. If you don't want DNSSEC validation, use --checkingdisabled:

% blaeu-resolve --requested 20 --type SOA --checkingdisabled servfail.nl 
Measurement #12156083 for servfail.nl/SOA uses 18 probes
[li1.forfun.net. hostmaster.forfun.net. 1508335121 86400 7200 2419200 60] : 17 occurrences
Test #12156083 done at 2018-04-14T16:35:10Z

 And if we want to display the result of the DNSSEC validation? Use --displayvalidation:

% blaeu-resolve --requested 100 --country FR --displayvalidation dns.bortzmeyer.org
[2605:4500:2:245b::42] : 53 occurrences
[ (Authentic Data flag) 2605:4500:2:245b::42] : 47 occurrences
Test #12165554 done at 2018-04-15T09:44:47Z

We see that half of the probes use a validating resolver (it would be risky to deduce that half of the users in France use a validating resolver: RIPE Atlas probes are installed by volunteers, they probably live in "geekier" networks). Of course, if the domain is unsigned and therefore unsecured, we will not see "Authentic Data flag":

% blaeu-resolve --requested 100 --country FR --displayvalidation --type A www.societegenerale.com 
[192.230.83.215] : 2 occurrences
[192.230.80.215] : 28 occurrences
[185.11.125.215] : 63 occurrences
[192.230.66.215] : 1 occurrences
[149.126.74.215] : 3 occurrences
[149.126.72.215] : 3 occurrences
Test #12165581 done at 2018-04-15T09:48:42Z

One last DNS specific option: the EDNS size. Sometimes, the answer is too large to fit in the buffer used by default by the Atlas probe:

% blaeu-resolve --type DNSKEY icann.org 
[ (TRUNCATED May have to use --ednssize) 257 3 7 aweaaaxecky6a65zj+lopz61qmjhisft juw77gmhutrah2iz53i61ddnjh7h5lhu jgjvr7] : 1 occurrences
[ (TRUNCATED May have to use --ednssize) ] : 4 occurrences
Test #12165593 done at 2018-04-15T09:50:48Z

The answer is truncated (note that some resolvers still send part of the data). We have to retry with a larger buffer (and the same probes, the one of the previous measurement):

% blaeu-resolve --type DNSKEY --old_measurement 12165593 --ednssize 4096 icann.org 
[256 3 7 aweaabw1w8nwjzkbnewpgdtxlc4dxah2 u2wfknonnzuaicv22xkn7qm+ln6jj86t k4te+z 256 3 7 aweaacfymegbkc18dxkcuveq+ag2s9no tuscruqgwo4gx8fivpgzmdijpjklydri ghrcux 256 3 7 aweaaytu0l60epuymqfdmxhthxzgjhv/ k35fximalne39djkg6502wkvqe9vjwyk sqkvs/ 257 3 7 aweaaaxecky6a65zj+lopz61qmjhisft juw77gmhutrah2iz53i61ddnjh7h5lhu jgjvr7 257 3 7 aweaadkq+roffjvrgheuamc1vhi2hico xky9bgbcwzicdea90nynbt08cbem9is7 bd88kf] : 5 occurrences
Test #12165603 done at 2018-04-15T09:52:49Z

Certificates

RIPE Atlas probes can also fetch the PKIX (X.509) certificate from a TLS server (not only HTTPS, every TLS server). Note that the probes don't have a real complete TLS client, so don't expect other TLS-related information.

% blaeu-cert framapiaf.org 
5 probes reported
[FAILED TO GET A CERT: connect: timeout] : 1 occurrences
[<X509Name object '/CN=framapiaf.org'>] : 4 occurrences
Test #12156143 done at 2018-04-14T16:43:10Z

Too bad one probe got a problem but, otherwise, we retrieved the certificate and blaeu-cert, by default, displays the certificate holder ("subject", in PKIX parlance).  

You can display the issuer if you prefer (the Certificate Authority):

% blaeu-cert --issuer www.bortzmeyer.org
5 probes reported
[<X509Name object '/O=CAcert Inc./OU=http://www.CAcert.org/CN=CAcert Class 3 Root'>] : 5 occurrences
Test #12156165 done at 2018-04-14T16:46:55Z

blaeu-cert can also display the expiration time of the certificate. If the service is distributed on several machines, they may have different versions of the certificate and it is therefore useful to  have also a distributed monitoring, precisely what Atlas is made for. This is the case for Twitter:

% blaeu-cert --expiration -4 twitter.com 
5 probes reported
[b'20190408120000Z'] : 2 occurrences
[b'20190117120000Z'] : 3 occurrences
Test #12156229 done at 2018-04-14T16:52:20Z

Note the use of -4 because Twitter has no IPv6 address.

As I said, blaeu-cert is not only for HTTPS servers. Here, we ask the certificate for a DNS-over-TLS server:

% blaeu-cert  --port 853 1.1.1.1
Measurement #12159366 to 1.1.1.1 uses 5 probes
5 probes reported
[FAILED TO GET A CERT: connect: Connection refused] : 1 occurrences
[<X509Name object '/C=US/ST=California/L=San Francisco/O=Cloudflare, Inc./CN=*.cloudflare-dns.com'>] : 4 occurrences
Test #12159366 done at 2018-04-14T19:53:59Z

For the programmer

If you know programming in Python, you can also use the Blaeu package directly from your programs. An example is test-nat-tag.py, which selects probes based on the user tag nat and then checks that the source IP address is in RFC 1918.

 

3 Comments

Wouter says:
17 Apr, 2018 03:09 PM
Looks useful, thanks for sharing this!
Can you briefly comment on what features this tool offers that are not in the official command line client?
Stéphane Bortzmeyer says:
17 Apr, 2018 05:13 PM
I started its development long before the "official" CLI program existed. After that, it's a matter of choice.

Can you now display aggregated results with the "official" client? Last time I tried it, it was weak on that, displaying results probe per probe.
Stéphane Bortzmeyer says:
17 Apr, 2018 05:19 PM
The first package is for Gentoo :-) https://www.swordarmor.fr/e[…]-les-sondes-ripe-atlas.html
Add comment

You can add a comment by filling out the form below. Comments are moderated so they won't appear immediately. If you have a RIPE NCC Access account, we would like you to log in.