Following up on our previous article looking into the goals and infrastructure behind measurement.network, this time we're going over the services that were made available last year and the research done so far.
Our measurement.network has been around for a bit over a year, and as discussed in my last article, most of the work so far has focused on assembling and building base infrastructure.
That said though, last year we provisioned several open research services and actually ran a couple of measurements. In this article, I want to briefly go over the available services and take a look at the research done so far.
BTTF Whois
We are now hosting BTTF Whois. This is based on a publication looking into the impact of IP address churn (read: transfers) over time on the accuracy of whois (or rather announcement) information.
Basically, when looking at IP addresses in data sets seen some time ago, one wants to know who announced it back then, and not right now. Existing bulk whois services, like the one from Team Cymru, however, do not allow looking up that historic information, and only provide a 'right now' perspective.
BTTF Whois lets you add a date, and then returns information on who announced a prefix at a given date.
email-security-scans.org
Email might be the most complex protocol stack out there. This is mainly because it now pulls HTTP (via MTA-STS) and (naturally) DNS into the stack as well. The email-security-scans.org service is based on another earlier paper, and allows one to test how well sending is configured on one's mail server. While existing services like internet.nl's excellent mail test can check most receiving features, one needs to receive emails to test sending behaviour of a remote system.
email-security-scans.org checks a variety of (security) features, including SPF, DKIM, DMARC, and DNSSEC. Additionally, it also checks if a setup is fully IPv6 ready - i.e., if recursive and authoritative DNS work via IPv6, and if mail-servers can send emails via IPv6.
The results might surprise you, so give it a spin. ;-)
DNS measurements
Most measurements so far were DNS focused. The largest looked into DNS full tree exploration. For that, the project gathered 87 TB of DNS data covering 812M domains with over 85B queries over 40 days.
Now, what is full-tree resolution? For DNS, it usually suffices that you can resolve a name somehow. When the resolver is dual-stack though, that can hide errors, for example if a crucial server on-path is only reachable via IPv4. Similarly, only looking at the working paths may hide misconfigurations in other parts of the possible resolution tree, which might come back to bite you later on.
Below, you can see the DNS tree for querying A example.com, including all zones (round) and NSs (square) that may be involved in a resolution. Only five queries are strictly necessary (the black boxes further below). It assumes that glue for resolving example.com can be trusted. The corresponding zones and authoritative servers in the full graph are highlighted in red.
Exploring the full tree can reveal interesting information on inconsistencies, IPv6 resolvability, and resilience. Furthermore, the dataset is a good collection of 'what is out there' for OSS developers to build test-cases and identify so far unknown corner-cases.
The results of this paper are currently in the final stages of getting published (open access). Similarly, we are currently compressing the dataset to make it publicly available. Links will be added to this article as soon as the data is online.
Beyond this, we are now hosting measurements into the use of CDS/CDNSKEY records for automatic DNSSEC updates between parent and child. We also supported a master thesis of a student from Japan who needed authoritative zones for a set of measurements run via RIPE Atlas, investigating IPv6 resolvability of zones from clients.
DNS services
In addition to hosting DNS related measurements, measurement.network also runs a DNS self-test. Via the web, one can test the IPv6 resolvability (and check for possible improvements, though it's a bit strict at the moment...) of zones.
There also is a public resolver on v6only-resolver.measurement.network, which can be queried via IPv4 and IPv6, but only performs IPv6 DNS resolution. For properly configured zones, this is just a normal resolver:
% dig +short @9.9.9.9 ripe.net
193.0.11.51
% dig +short @v6only-resolver.measurement.network ripe.net
193.0.11.51
Zones that are not IPv6 ready, though, cannot be resolved:
% dig +short @9.9.9.9 tudelft.nl
130.161.128.82
% dig +short @v6only-resolver.measurement.network tudelt.nl
%
Dark Nets
The last notable thing currently going on is a study on Internet background noise. For this purpose, measurement.network announces a temporary IPv4 assignment the student received from the RIPE NCC.
In addition, measurement.network provides multiple /36 as 'dark nets', i.e. networks with no services, where all incoming traffic is captured. The most interesting aspect in terms of running this from measurement.network is the ability to provide multiple test cases. While one of the prefixes is currently announced explicitly, another is only visible via the covering prefix. This allows the researcher to investigate whether the announcement state of a prefix influences the background noise it receives.
Conclusion
In summary, things are happening! Although artefact evaluation took away a lot of time that did not go into opening up the submission system, there are nevertheless a number of experiments and measurements have already been run. So far, these have mostly been for 'in house' work, to make sure that the platform can actually handle measurements. But we shall continue to push on - there always is tomorrow.
If you have a measurement to run that does not fit any other platform, or for which your affiliation cannot provide the right resources, please reach out to contact@measurement.network
Comments 0