Right now, the European Union is developing their second Network and Information Security directive (NIS2) and I am concerned about the language used to describe the domain name system (DNS) – and the negative effects the legislation will have on the security and resiliency of the DNS.
At the current time, there are three different drafts of the NIS2 in circulation. The European Parliament just approved a draft that will then be compared against the drafts produced by the European Council (member states of the European Union) and the European Commission (EU executive branch in Brussels) to be negotiated until the parties agree on a single text.
We have written about the NIS2 earlier. Now I would like to zoom into the European Council’s draft and a specific aspect of the DNS, indicating how far technical reality drifts from regulatory intent.
The intent of NIS2 is to make sure that the infrastructure on which Europe relies for its economic activity is secure and trustworthy. That is a laudable goal. In fact, the Internet Society believes any Internet infrastructure on which people have to rely on for their social and economic activity should be secure and trustworthy, no matter where they live.
In order to attain this security goal NIS2 wants to regulate the domain name system (DNS). Recital 15 of the European Council’s version the draft NIS2 now reads:
“Therefore, this Directive should apply to all providers of DNS services along the DNS provisioning and resolution chain that are of importance for the internal market, the entities providing domain name registration services, the including operators of root name servers with a significant footprint in the EU, top-level-domain (TLD) name registries servers, the entities providing domain name registration services,operators of authoritative name servers for domain names and operators of recursive resolvers”
(This is from Document 12019/2/21 Rev2 d.d. 25 October 2021, not publicly available, whereby the strikethroughs and the bold font indicate recent changes in the draft text.)
The annex of the Council’s version now reads “DNS service providers, including operators of root name servers with a significant footprint in the EU (more than 10 sites in the EU).”
If we look at this language through the lens of the pillars of security to the DNS server infrastructure, the Council language does not add any security or trustworthiness.. Below we first look at Integrity and Authenticity and then at Availability[1].
Integrity and Authenticity
When it comes to security and trustworthiness, we must first consider the matter of integrity of the information that is being provided by the DNS. Is the information about a domain that the user receives from a DNS resolver the correct and accurate information that the domain operator entered into DNS? The integrity is guaranteed by the DNS Security Extensions (DNSSEC). With DNSSEC, the information provided has been cryptographically signed by the publisher of the Information. No matter how that information is received, the users can cryptographically verify that the answers are exactly the same as published by the domain owner. It does not matter where the name server is located, or even how secure it is – the information is signed and can therefore not be modified – therefore we have integrity. Because of the cryptographic properties of the signatures, we know which entity published particular DNS information – therefore we also have authenticity.
Regardless of the size of the “footprint”, having more or fewer name servers does not impact the authenticity and integrity of the DNS information. Having DNSSEC does. And fortunately the state of DNSSEC deployment at the national level in the EU is quite advanced (see here our deployment maps).
With regards to integrity and authenticity of the DNS, the NIS2 provisions about name servers are not going to make any difference whatsoever. They may impact the provisioning of the DNS information itself (through regristrars and registries) but not how that information is made available on the Internet.
Availability
With authenticity and integrity not being impacted with the name server provisions of NIS2, surely NIS2 will at least improve availability, and thereby trustworthiness and security, right?
To understand this, let’s look at availability from the perspective from the user. When the user enters a domain name into a web browser, for instance, that domain name is sent to a local DNS recursive resolver to look up an IP address. The recursive resolver then queries authoritative name servers, such as the root servers, to get an answer on behalf of the user.
In this process, the recursive resolver will build an internal list of all the IP addresses of authoritative name servers on which information about a certain domain name is available.
The recursive resolver will then randomly pick one of the authoritative name server IP addresses to query for an answer. It doesn’t matter to the recursive resolver where that authoritative server is located. At least one popular implementation of recursive resolvers doesn’t care on which continent or economic region the IP is located, it will pick randomly from around the globe[2].
(As an aside, the reason it does that is to prevent the so-called Kaminsky attack to which the DNS is vulnerable in absence of DNSSEC, see https://www.nlnetlabs.nl/documentation/unbound/patch-announce102/ and https://www.nlnetlabs.nl/documentation/unbound/info-timeout/).
To improve resilience, availability and performance of the DNS system a technique called “anycast” has been widely used by the DNS service operators. The idea is that exact copies of a DNS server, including its IP address, are deployed in many places in the network infrastructure. Those servers are called “instances” (not sites, as in the Annex) and if there are multiple instances in the Internet each will attract the traffic that is close to it in terms of network topology. They are traffic magnets.
Creating more instances of a name server buys you two things. First, if the random selection happens to choose the name server IP having an instance close in the network topology will get you a quicker answer. Second, an instance will attract all local traffic. So if the IP of a name server is under a high volume denial-of service (DOS) attack, these will attract local attack traffic, allowing network operators to better identify and respond to the attackers. More instances means more capacity to deal with DOS attacks, which in turns means that there will be less debilitating results. And the more instances the fewer EU citizens are impacted during high volume DOS attacks.
Hence the more instances of name servers on the network, the more secure it will be. Ideally, for the root you would want to have all operators deploy multiple name server instances on European soil. That way you can be sure that the random algorithm will always promptly respond. You simply get more resilience and better performance.
But will NIS2 incentivize the creation of more name servers? In particular root servers?
I don’t think it will. In fact, it may cause name server operators to consider reducing the amount of name servers to less than 10 in order to fall out of the scope of the regulation. Therefore, as is the directive incentivizes reduction of resiliency and availability.
Accountability
More generally, looking at the last sentence of Recital 15.
“the entities providing domain name registration services, operators of authoritative name servers for domain names and operators of recursive resolvers.“
Operators of recursive resolvers are part of the supply chain of enterprises and Internet Service Providers (ISPs) that choose to use them.Similarly, the authoritative name servers are part of a supply chain for which ultimately the domain holder bears responsibility. The entity that makes its services available through, for example an EU domain, would guarantee the availability of their service through service level agreements on the supply chain. Ultimately those who make a service available that relies on a domain name are accountable for the availability of that service. That accountability trickles down through contracts and in that way creates a security culture. Accountability is guaranteed bottom up, instead of top down.
If the European Council and the European Commission want to prevent risks from a top-down approach to regulation of the DNS that could seriously fragment the Internet and reduce security online, it should take a cue from the European Parliament’s version of the NIS2 text, which has excluded root name servers from the scope. In fact, it should take that a step further and exclude the root server system as a whole, both because of the technical arguments above but also because it is already governed through best practices in an open multi stakeholder process.
[1] Pillars of security are Confidentially, Integrity, Authenticity, and Availability. We do not discuss confidentiality, as while that is important component of making the DNS more secure and trustworthy, it does not play a role in the draft text.
[2] I am describing the behavior of the Unbound recursive nameserver, one that I helped design. That server treats all servers that are within 400ms roundtrip time away – anywhere on the globe – as similar.