NLnet Labs participates in various research projects which revolve around core Internet infrastructure. Here you can find an overview of the current projects we are participating in.

Route Origin Validation measurements

Description

The Resource Public Key Infrastructure (RPKI) aims to secure Internet routing. Route Origin Authorizations (ROAs) provide attestable statements regarding which prefix is authorized to be originated from which Autonomous System Number (ASN) in the Border Gateway Protocol (BGP). Route Origin Validation (ROV) is the process of using the data from the ROAs in the RPKI to determine whether a route announced in the BGP is valid, invalid, or unknown.

NLnet Labs has been measuring the uptake of protection by ROV of DNS resolvers since January 2020, starting with a research project executed by Marius Bouwer and Erik Dekker (see the report). Up to date results of the Route Origin Validation of DNS resolvers measurements can also be found on the DNSThought website (here for IPv4 and here). These measurements were performed with the help of a RPKI beacon kindly provided by Job Snijders until September 2021. Results of this research has been presented at DNS-OARC 32b (video), ICANN69 (video) and Internetdagarna 2020.

With the help of temporary resources provided by the RIPE NCC we have managed to create our own RPKI Beacon (currently using our own permanent resources) to continue measuring the uptake of protection by ROV of DNS resolvers. This effort has been presented at the IEPG at the IETF113 (video), the CENTR Tech46 meeting and at the NLUUG vj 2022. We facilitate community RPKI measurement initiatives by providing a RIPE Atlas probe using the RPKI Invalid resources, and by making the invalid resources available through our NLNOG RING node nlnetlabs01.ring.nlnog.net. The beacon also provides the means to determine the ROV status of end-user’s with an RPKI webtest <https://rpkitest.nlnetlabs.net/> and of end-user’s resolvers in `DNS-OARC's Check My DNS service.

With the continuing measurements tracking the state of RPKI protection of DNS resources in the long term in place, we are now deepening our research on the state of ROV in collaboration with students from the University of Twenty, the University of Amsterdam and the Domain Name System Operations Analysis and Research Center:

  1. Measuring Route Origin Validation of authoritative name servers

    This research is in collaboration with Sander Post and Brice Habets from the University of Amsterdam and aims to measure the state of ROV at authoritative name servers. A short project description can be found under project #90 on the SNE Masters Research Projects page.

  2. Comparing Route Origin Validation of the different Trust Anchor Locators

    With this effort we will try to see if and what is the difference in the status of ROV with resources anchored at the Trust Anchor Locators (TALs) of the different Regional Internet Registries (RIRs). We are especially interested in resources anchored in the ARIN TAL to measure the effect of the requirement to agree with ARIN’s Relying Party Agreement (RPA) before usage. This research is in collaboration with Jerry Lundström of the  Domain Name System Operations Analysis and Research Center (DNS-OARC).

    For this research we will need additional resources from the different RIRs, especially from ARIN.

  3. Where does the ROV on the path happen? Who is to blame?

    Unlike (previous) other RPKI beacons, our beacon not only announces an RPKI invalid prefix, but also a valid less specific prefix overlapping with the invalid prefix from another location. This facilitates more rapid results collection; The same address can be serviced from both locations and the location where a packet arrived reveals whether it was subject to ROV.

    But this setup also induces some specific ROV dynamics; Even if your network does ROV you may end up at the invalid announcement, because any hop on the path may direct it there. Furthermore, recent experiments seem to indicate that the further the two locations (serving the invalid and the less specific valid prefix) are apart, the more likely it is that ROV will fail for paths towards the valid prefix.

    We would like to differentiate on how ROV (or lack thereof) occurs on the path. How does ROV at the beginning of a path (as measured by conventional RPKI beacons) compare to the lack of validation anywhere on the path (as measured by our specific RPKI beacon). We also think we can pinpoint which hop at the end of a path does not perform ROV, by performing traceroutes from the valid announcement and monitoring at which location the ICMP “Time to live exceeded” messages arrive. By doing the traceroutes from different locations worldwide, we should be able to gain insight in why and to what extent the physical distance of a routing hijack impacts the success of the hijack.

    These additional methods above would provide more detailed feedback on where ROV fails with our online RPKI webtest and the resolvers in DNS-OARC's Check My DNS service. We also need additional IPv4 resources to realize them for IPv4 too.

NGI0 PET - DNSSEC Key Signing Suite

Description
The DNSSEC protocol brings trust to the Domain Name System by guaranteeing the authenticity and integrity of data stored in the DNS. DNSSEC is increasingly used as a root of trust for Internet protocols. For example, leveraging the DNS-based Authentication of Named Entitities (DANE) protocol, servers used for the handling of e-mail can now securely communicate which public keys are trusted when establishing a TLS connection with these servers. This makes it of paramount importance that key material used for DNSSEC is well protected, especially higher up in the DNS hierarchy at top-level domains. Ideally, in such environments, it is desirable to store sensitive key material (such as the so-called Key Signing Key) offline, and to only use it when required. While some TLD operators already follow this practice, it is far from common, due to a lack of standardised tools and procedures. In this NGI0 PET project, funded by the European Commission, NLnet Labs will develop such standardised tools and procedures in collaboration with stakeholders in the industry.
More
Learn more about NGI0 PET on the NLnet Foundation website.

Root Canary

Description

The Root Canary project is a joint project of seven partners: SURFnet, the University of Twente, Northeastern University, NLnet Labs, SIDN Labs, the RIPE NCC and ICANN. The goal of this project is to monitor and measure the rollover of the DNSSEC root Key Signing Key (KSK), that is due to take place in 2018-2019.

This project has two main goals:

  1. Serve as a virtual canary in the coalmine, that signals problems DNSSEC-validating DNS resolvers may have during the Root KSK rollover process.
  2. Perform comprehensive measurements of the global DNS resolver population during the entire Root KSK rollover process, from the introduction of the new key until the removal of the old key. The results of these measurements can then be analysed after the process completes to draw lessons for future Root KSK rollover events.

While the actual project itself has now ended, the measurements that were part of the project have become part of NLnet Labs' DNSthough platform.

More
This project is maintained on rootcanary.org.

LIGHTest

Description

The aim of the LIGHTest research project has been to create a global cross-domain trust infrastructure that renders it transparent and easy for verifiers to evaluate electronic transactions. By querying different trust authorities world-wide and combining trust aspects related to identity, business, reputation etc. it will become possible to conduct domain-specific trust decisions.

Funded under the EU’s Horizon 2020 programme, the project had fourteen partners from nine countries with a diverse background. NLnet Labs contributed its knowledge and experience of the DNS to the project.

More
You can find more information on the LIGHTest Community Site.

OpenINTEL

Description

The goal of the OpenINTEL project is to build reliable long-term datasets of the Domain Name System (DNS). Currently, OpenINTEL sends daily queries for a fixed set of common DNS record types for around 65% of the global namespace. Started in 2015 as a collaboration between SURFnet, SIDN and the University of Twente, OpenINTEL has already collected closed to 3 trillion DNS records that can be used to study the constantly evolving Internet.

OpenINTEL uses tools developed by NLnet Labs to power its measurement infrastructure, with LDNS serving as the Swiss army knife to send the billions of DNS queries and parse the result, and Unbound to perform the important task of resolving these queries. NLnet Labs also contributes DNS expertise and custom development for the measurement code of OpenINTEL.

More
You can find more information on OpenINTEL on the project webpage openintel.nl.

SAND

Description

The Self-Managing Anycast Networks for DNS (SAND) project is a collaboration between the University of Twente, SIDN and NLnet Labs. The goal of this project is to create resilient anycast DNS networks that can withstand global outages and large-scale DDoS attacks.

NLnet Labs contributes to SAND with its in-depth knowledge of BGP routing and DNS. In addition to this, NLnet Labs strives to adopt the open source tools developed as part of the SAND project.

More
You can find more information on the SAND project webpage at sand-project.nl.

MASCOT

Description

Outsourcing to the cloud is mainstream business practice. Oft-quoted security benefits of the cloud are availability of skilled staff, bandwidth and compute power to head off attacks. Yet recent outages call these benefits into question. MASCOT will rigorously study cloud resilience and use the outcome to support security-conscious cloud strategies.

The project consortium is led by the University of Twente, and includes SURF, Logius, KPN and NLnet Labs as partners. The project will run for four years from 2020 - 2023.

More
The MASCOT project does not have its own webpage yet.

Connectbyname

Description
The connectbyname library provides an application with a high-level function to obtain a TLS connections to a service identified by a DNS name and a port.
More
You can find more information on the project webpage.