The challenge of DNSSEC in multi-cloud environments

DNS Security Extensions (DNSSEC) prevent DNS spoofing attacks by providing origin authentication and integrity of DNS data using digital signatures.

With DNSSEC enabled, DNS responses from authoritative servers are accompanied by cryptographic signatures. The recursive resolver then checks these signatures and rejects the response if it detects that it has been tampered with.

DNSSEC was created as a security add-on long after the DNS protocol was in general use. It was designed to support the most common use case of the time: zones that are maintained by one party and served by others. This is achieved by taking the DNS data for an authority in the form of a zone file, digitally signing all records in advance, and then distributing the new zone file with all signatures included.

Internet DNS infrastructure is still supported today by pre-signed DNS zones. Yet increasingly, this method is a limiting factor for today’s complex enterprise networks.

Organizations relying on CDNs and multi-cloud environments usually want the best experience for their visitors and users. DNS helps achieve that goal by tailoring DNS responses for specific DNS queries and directing each client to the best-performing data center.

DNS response tailoring is specific to individual DNS providers and is usually not directly translatable between vendors. Such configurations cannot be supported by pre-signing DNS zones and require some form of online signing of DNS responses as they are generated by the authoritative DNS server.

Supporting DNSSEC in such cases is less straightforward. In the tradeoff between using multiple DNS providers, effective DNS traffic management, and adopting DNSSEC, network admins usually opt for more functionality to support business needs.

The result is that DNSSEC becomes a “nice to have” instead of what it should be: a necessity.

How Multi-Signer DNSSEC works

NS1 believes that nobody should have to compromise when it comes to security or DNS functionality. To this end, we started conversations with multiple DNS vendors and our customers about a way to configure DNSSEC so it could support authoritative answers from multiple DNS vendors. The result of this work is RFC 8901 (Multi-Signer DNSSEC Models) which I co-authored.

The DNSSEC trust model

To set the stage for Multi-Signer DNSSEC, let’s take a step back and talk about how DNSSEC authenticates queries.

DNSSEC adds a few new record types into the DNS protocol:

• RRSIG records hold the actual signatures,

• DNSKEY records store public key data to validate the signatures, and

• DS records indicate which DNSSEC keys are used for child zones.

The DNS resolution process is iterative. The resolver starts by figuring out which server is responsible for a given domain name by asking DNS root servers that are well known. The root servers usually respond with delegations to top-level domain servers, which return another delegation. Eventually, the resolver finds the right DNS zone and server, which can give authoritative answers.

At each step of the resolution process, the DNSSEC validating resolver checks the authenticity and integrity of each answer. It takes the response, which is accompanied by the signature in the RRSIG record, fetches the DNSKEY record, and verifies the signature.

How can the DNSKEY be trusted? The resolver has a pre-configured trust anchor, which is a list of DNSSEC keys trusted for the root zone. As the resolver follows individual delegations, it also receives DS records which indicate which DNSKEY records are valid for the child zone. The DS records are signed by the parent zone. As a result, the resolver establishes trust by following the DS and DNSKEY records all the way from the trust anchor to the final DNS zone.

DNSSEC validation never happens through a single response. There are at least three separate DNS responses that are required to complete the chain of trust:

• the DNS response accompanied by a signature (RRSIG) that needs to be validated,

• the DNSKEY response with the public keys for the zone, and

• the response from the parent zone with the DS record indicating which DNSKEY records can be trusted.

All these pieces of information need to fit together for DNSSEC validation to work.

The multi-signer solution

Here’s the good news: Multi-Signer DNSSEC doesn't require any changes to the DNS protocol. It’s simply a matter of configuring DNSKEY records appropriately.

Each DNS provider uses a different set of signing keys. We also know that the resolver fetches the DNSKEY separately from the actual record to validate. If the resolver gets a record from the first provider and DNSKEY from a different provider, the record needs to successfully validate against the second provider’s DNSKEY.

All that needs to be done to make a multi-signer work is to set up the DNSKEY records of each provider to contain public keys used by the other providers. The desired outcome is an identical set of DNSKEY records which is served by all providers and includes all public keys that are used.

Here’s a visual representation of how the delegation and DNSKEY records are configured in a multi-signer scenario.

Implementing Multi-Signer DNSSEC

NS1 is excited to be one of the first DNS providers to support multi-signer DNSSEC. We’ve successfully deployed multi-signer DNSSEC with open-source BIND and Knot DNS, and now we’re working with design partners across the industry to make multi-signer DNSSEC accessible and easy to configure through simple API calls.

We believe that multi-signer DNSSEC will finally allow our customers to have it both ways, unlocking the power of multi-cloud DNS without sacrificing vendor-specific features.

In our next blog, we’ll dive deeper into how NS1 has implemented multi-signer DNSSEC configurations in our platform. As a preview, check out our help center article on managing DNSSEC keys with the NS1 API.