NIS2 Inconsistency – a DNS Supply Chain Perspective Thumbnail
‹ Back
Internet Way of Networking 17 December 2021

NIS2 Inconsistency – a DNS Supply Chain Perspective

Olaf Kolkman
By Olaf KolkmanPrincipal - Internet Technology, Policy, and Advocacy

The European Union’s Network and Information Security directive (NIS2) is missing an opportunity to foster accountability across the entire DNS supply chain. Instead of focusing on the outcome for the consumer, NIS2 is trying to regulate specific points in the network.

Future regulations in the EU or elsewhere can do better.

Let me step back and explain about the DNS supply chain.

How do we get to the right address on the Internet?

When you enter a text like “internetsociety.org” on your device, it uses a recursive name server to query the Domain Name System (DNS) – a global distributed hierarchical database which translates that text into an address or another resource. This act of translation allows your device to reach the destination you are interested in. Without using the service provided by a recursive name server, you would not have a useful Internet experience.

Whenever you connect to the Internet, your network operator – your mobile operator, home Internet Service Provider, or your enterprise network operator – automatically supplies you with the address on which your device can find the that recursive name server.

Recursive name servers were traditionally operated by your Internet Service Provider (ISP) or enterprise network operator.  But during the last decade these services have increasingly been outsourced to recursive name server operators like Google, Cloudflare, or QUAD9.

The reasons for doing so are primarily driven by the need to reduce continuity risk. The capital expenses of running your own recursive name server can be negligible as recursive name servers typically use open-source free products that run on commodity, or off-the-shelf hardware.

Likewise, operational expenses are typically modest and on par with standard system administration duties. Until… something goes wrong.  If your recursive name server is down, your network is down. Having a technical expert who can solve this problem quickly become expensive given the need for the individual to be available 24/7.

Outsourcing, for this reason, is attractive as a simpler and cheaper option. A specialized operator will now deliver the service, often even at no monetary cost. Makes sense, but what about security?

What are the security risks with outsourcing recursive name servers?

Let us look at NIS2, a recent regulatory proposal from the EU, that seeks to impose security requirements on the operators of essential and important entities. As I wrote about previously, NIS2 has a specific vision for where in the digital ecosystem cybersecurity measures should be taken. The Directive’s text states:

the cybersecurity risk management measures should consist of appropriate and proportionate technical and organisational measures to manage the risks posed to the security of network and information systems which the relevant entities use in the provision of their services”
( Art 12a of 12019/2/21 Rev2 d.d. 25 October 2021, not publicly available).

I sympathize with that vision and agree that such measures should take into account all the dependencies, including the network and information systems, that entities rely on – what we call a supply chain. At the same time, I believe that entities should be responsible for managing cybersecurity risk within their own supply chains and practice due diligence when they consider outsourcing the inputs that go into their final services. In essence, my view is that it is not necessary to regulate all points along a supply chain as long as the final entities are expected to take responsibility for their decisions. 

NIS2 does not take this approach and instead views operators of recursive name servers as independent entities, imposing direct requirements on them. By regulating at all points up and down the supply chain, NIS2 treats recursive resolvers as services that are directly used by consumers and enterprises, which is not the case.

The dependencies in entity supply chains are not always apparent. The outsourcing of recursive name servers by network providers has blurred the chain of dependency over time as these outsourcing arrangements are typically made without service-level agreements (SLAs) or contracts.

Entities that do outsource to recursive name servers are best positioned to understand where dependencies exist. By exclusively regulating final entities rather than all levels of the supply chain, NIS2 could nudge entities to thoroughly analyze the risks in their supply chains themselves.

With this approach, entities that fail to conduct a sufficient risk analysis would face the corresponding penalties. In the long term this would foster a culture of greater transparency and accountability among essential and important entities, contributing greatly to increased cybersecurity health.

The DNS environment is constantly evolving. For example, a few new protocols such as DNS over Hypertext Transfer Protocol Secure (DoH) are now being used to provide security and privacy features.

Regulation that pinpoints final entities rather than the full supply chain would be adaptive to such new initiatives, as entities would be responsible for managing risk in their own supply chains.

In an enterprise environment, the enterprise’s security policies should guide risk analysis. In a home network, browser vendors or other applications would be responsible for any decisions to hard-configure a DNS provider or consider a scenario where a user might override the standard settings of an ISP. In fact, there is a whole Internet Engineering Task Force (IETF) working group dedicated to creating the technical mechanisms to make sure the appropriate recursive nameserver can be found and configured.

By treating recursive nameservers as independent actors, NIS2 incentivizes recursive nameservers to be ignored in the analysis of supply chain dependencies. This is bound to have perverse effects and misses an opportunity to foster of accountability among important and essential entities.

In designing this sort of regulation, it is wise to identify the actual service that is being delivered and put the responsibility for security there. In the ideal world, I would like to see NIS2 fixed. But given that NIS2 is in the final stages of negotiation, it would be wise that governing authorities in other parts of the world take note so that they don’t make the same mistakes as the EU. 


Image credit: “Drapeau de l’Union Européenne” by CampusFrance, licensed under CC0 1.0

‹ Back

Disclaimer: Viewpoints expressed in this post are those of the author and may or may not reflect official Internet Society positions.

Related articles

Internet Way of Networking 18 May 2022

Protecting the Internet As We Know It – Three Things You Can Do Today To Stop the Splinternet

Learn how to protect what the Internet needs to exist and thrive—then do something today.

Internet Way of Networking 14 April 2022

US, EU, and G7 Commitment Will Slow the Splinternet, But More Work Needed

The Internet Society welcomes the US, EU, and G7 commitment to exempt telecommunications services that support Internet access and...

Internet Way of Networking 23 March 2022

What Is the Splinternet? And Why You Should Be Paying Attention

The “Splinternet” is the idea that the open, globally connected Internet we all use splinters into a collection of...

Join the conversation with Internet Society members around the world