DNSSEC is increasingly adopted by organizations to protect DNS data and prevent DNS attacks like DNS spoofing and DNS cache poisoning. At the same time, more DNS deployments are using proprietary DNS features like geo-routing or load balancing, which require special configuration to support using DNSSEC.

When these requirements intersect with multiple DNS providers, the system breaks down. DNSSEC cannot currently work with two or more providers if those providers offer proprietary DNS features. In this article, we’ll explain why this happens and present an innovative technical solution that was recently adopted in an RFC draft and is under evaluation by the DNS operations working group in the IETF. We will show how NS1 implements this solution and describe another way that organizations can achieve DNS redundancy with DNSSEC.

The Problem of Multi-Signer DNSSEC

DNSSEC is a set of extensions that improve the original DNS protocol to make it more secure. Its main objective is to allow DNS clients to verify that they are receiving correct DNS information and not fake information injected by attackers.

DNSSEC defines new types of DNS records, which hold cryptographic signatures of DNS data and share a public key that allows verification of the data. The signatures are a proof that the data has not been tampered with and are authentic because the private key that was used to create the signatures is held only by the DNS zone owner.

The problem begins when organizations have three requirements, all of which are quite common in modern DNS deployments:

1. DNSSEC – they want to secure DNS communication using the DNSSEC protocol.
2. Multi provider – they want to run DNS with more than one provider at the same time. This is commonly used to setup redundant DNS, ensuring services remain available even if one DNS provider fails.
3. Advanced and Proprietary DNS features – most DNS providers today offer capabilities that go beyond the standard DNS protocol in order to route traffic based on rules or conditions such as resource availability or geo-routing that can route users, via DNS, to a server near them, or Global Server Load Balancing to route users between several servers. See for example NS1’s DNS traffic steering capabilities. Since these capabilities extend standard DNS, many of these advanced features are implemented in proprietary ways.

Using current DNS infrastructure, if you meet requirements #2 and #3, DNSSEC will simply not work. Let’s understand why.

In traditional DNS, all records are static. The zone file is signed with DNSSEC and distributed to DNS providers (in case you use more than one). All providers serve the records from the same file. Every client who sends a query for a record gets the same answer, regardless of which DNS provider that client is communicating with.

However, when we introduce requirement #3, proprietary DNS features, DNS records are no longer static. The DNS answer might change for a specific query. For example, you might want to provide a different DNS response depending on the geographical location of the user, the server you want to route the user to, performance considerations, etc.

Each DNS provider that has proprietary DNS features has an internal method for making DNSSEC work with their traffic management features. For example, NS1 signs each individual response on-the-fly when generating the response (this is called DNSSEC online signing).

Those proprietary DNSSEC implementations are quite different between providers. It is no longer possible to provide one zone file, sign it one time and distribute it between providers. Each provider generates tailored DNS responses which cannot be easily pre-signed with a single DNSSEC key.

A Strategy for Solving the Multi-Signer DNSSEC Problem

A solution to this problem has been proposed in a recent IETF draft, co-authored by NS1’s Jan V?elák. The solution is straightforward but requires some background to understand, let’s go through it step by step.

A Bit of Background: KSK and ZSK

Let’s start by defining two important concepts:

• The Key Signing Key (KSK) is the key used to sign and therefore authenticate other DNSSEC keys to sign the zone content. The private part of the key is kept by the zone owner and the public part of the key is published in the DNS. The key is also referred to from a parent zone which establishes a secure delegation between the parent and the zone.
• The Zone Signing Key (ZSK) is the key used to sign all records in the zone, except for the DNSKEY record which is signed by KSK.

Sharing the ZSK Between Providers

The proposed strategy for multi-signer DNS is that each DNS provider should use a separate zone signing key for the records they serve, but all providers have to agree on the total set of DNSSEC keys being used, which includes all of the KSK and ZSK. Therefore each provider has to import the public keys of every other provider.

Why would one DNS provider need the public keys of the other providers?

Take a domain, example.com, with two DNS providers A and B and with each provider using a separate KSK and ZSK. There is a secure delegation from the parent zone (”.com”), which contains signed DS records pointing to both providers’ KSK.

Now the DNS resolver has to fetch the DNSKEY record for the zone which contains the DNSSEC keys to be used for validation. If it chooses to talk to provider A, the resolver obtains the DNSKEY, validates the response, and then caches it. This is illustrated below.

At a later point in time, the resolver might query another record in that zone, but now it talks to provider B’s name servers. It gets a response, but that response is signed by B’s ZSK which is not present in the cached DNSKEY record received from A. This is illustrated by provider B returning an answer signed by the orange and purple keys.

That’s why provider A’s DNS response needs to include the ZSK for provider B, and vice versa. Every provider has to import public keys of every other provider. This is the basis for the multi-signer DNSSEC solution.

Two Models for Making Multi-Signer DNSSEC Work

We’ve presented the basic principle that makes multi-signer DNSSEC work—that each provider needs to import and provide to its users the ZSKs of all the other providers. This ensures that the next time a user makes a query, they can still validate their DNSSEC data even if they reach another provider. There are two models for making this happen.

Model 1: One Zone Owner and One KSK

Who is it for?

Model 1 uses a single KSK managed by one of the providers or the zone owner. This model is suitable for organizations that require a better control of the KSK and want to manage all signing keys for the zone themselves.

How it works

Each of the providers, A and B, has its own set of zone signing keys (ZSK). The zone owner retrieves the public keys from the providers, builds the DNSKEY record set which contains the public KSK and public ZSKs of the providers, signs it using the private KSK, and provides the resulting DNSKEY record set along with the signature to the two DNS providers.

Source: DNS OARC Presentation

The above diagram illustrates that the DNS record set is always served with the same signature, generated in advance by the zone owner. But any other content in the zone is signed by the ZSKs held by the different providers.

Because each DNS provider has the same DNSKEY record set, even if the resolver caches a response from one provider, they have all public keys needed to validate responses sent by the other provider.

Model 2: Shared Trust, Two KSKs Distributed to Two DNS Providers

Who is it for?

Under model 2, each provider uses independent KSK and ZSK. This model is suitable for organizations that do not require tight control of the KSK and instead require a solution with full redundancy.

How it works

Each provider has their own ZSK and KSK. They independently reach out to the other provider, get the public keys that provider is using, and add their own public keys. As a result, they all end up with the same DNSKEY record set which is signed by their own KSK. The DNSKEY record and the signatures are then added into the zone.

In this setup, the parent zone contains DS record referring to KSK of each provider. No matter what provider the DNS resolver selects to get any zone record, it will always be able to validate their authenticity because both KSKs are trusted and the DNSKEY record set is the same at both providers.

Multi-Signer DNSSEC Status at NS1

At this stage, NS1 has working prototype implementation of the interface required to support Model 1: Our REST API enables to retrieve public keys we use for signing and also allows publishing the final DNSKEY record set and its signatures. At the same time, we are building an open-source component that allows you to run NS1 and any common open-source DNS server (for example BIND) in the multi-signer DNSSEC configuration.

NS1 is currently working with other DNS providers to implement the same interface, which will also eventually enable running the Model 2, which has the benefit of full DNS provider redundancy.

While we are talking to different providers to enable Model 2, you can achieve the same results solely leveraging the NS1 Domain Security Suite.

Domain Security Suite

NS1 Domain Security Suite Includes:

• A fully managed, single tenant, globally anycasted DNS network dedicated to your zones
• A second, redundant DNS network hosted with a third party vendor on hardware, IPs, and ASNs that are physically and logically separate from the NS1 Managed DNS network
• Support for full traffic management and DNSSEC on both networks
• Full use of NS1’s suite of advanced traffic steering capabilities on both DNSSEC-protected DNS networks
• Single pane of glass management