[Webinar] Using RUM to Fight Latency and Supercharge Performance - Register Now!

NS1 Announces DNSSEC

This week NS1 announced that we now support DNSSEC. DNSSEC has been around for a long time and many managed DNS providers already support it. Is NS1 joining the DNSSEC party a big deal? To answer that question let’s consider how widely deployed DNSSEC is and the underlying reasons why.

The history of DNSSEC goes back to 1990s when the first RFCs were authored. It was recognized at the time that the DNS protocol did not include adequate mechanisms for resolvers to authenticate the validity of the information they receive in response to their queries. Hackers could feed resolvers false data regarding website addresses, email servers and even nameservers themselves.  

However, the task of using DNSSEC was a “heavy lift” to say the least. Aside from DNSSEC needing to be implemented on DNS server software, there was the chicken and egg problem of the entire DNS infrastructure needing to be “DNSSEC ready” before domain owners could benefit from it. There was also an issue of complexity. DNSSEC was hard to set up and DNS administrators could easily make a mistake that would result in their domain disappearing from the internet. Given these barriers and the apparent low incidence of the kinds of cache poisoning attacks DNSSEC would prevent, DNSSEC remained an interesting side show.

Fast forward to 2008 and the famous Dan Kaminsky revelations of how vulnerable the DNS system really was to DNS cache poisoning, and the move to implement DNSSEC began in earnest. Over the subsequent several years many of the barriers to using DNSSEC were addressed – the root zones and most TLDs were signed. Tools became available to make it much easier and less prone to error for DNS administrations to protect their zones with DNSSEC.

Now that the DNSSEC scaffolding is in place what is the state of deployment across the major domains? In short, low. As the graphs below show, although the major TLDs are signed, relatively few subdomains are also signed. For example, at last count fewer than 1% of the .com subdomains were signed. While the numbers have been going up, the rate of increase is very gradual.

Figure 1: Top Level Domains (TLDs) are almost all signed (source: State of DNS Deployment 2016, Internet Society)

Figure 2: Percentage of second level domains signed in .net and .com signed (source: State of DNS Deployment 2016, Internet Society)

What accounts for this? The potential impact of a successful cache poisoning attack is very severe. Furthermore, not only is DNSSEC readily available, it’s also free to use. It would seem that taking this basic step to protect one’s online presence and customers should be a no brainer for most businesses and yet the numbers show this not to be the case.

There may be both an awareness issue coupled with the fact that there have been few visible and publicized cache poisoning events in the news. That might explain why this important security mechanism is sitting on the sidelines for most businesses. As we often see in matters of IT security, businesses tend to be reactive. For example, we saw heightened interest in redundant DNS architectures only after highly visible DDoS attacks exposed the need for redundancy. Awareness and urgency may be lacking.

We think though that there is another important factor in play. When we looked at how most other DNS providers had implemented DNSSEC on their platforms, it was obvious as to why the uptake by enterprises would be so low. What we see is the major DNS providers (with a couple of exceptions) use offline signing for DNSSEC. This means that the dynamic traffic management features of DNS become inoperable if the zone is signed. You lose the ability to do geo-routing, real time site or server monitoring, global load balancing and many other techniques that improve application performance and availability. Having dual DNS providers is also affected by many DNSSEC implementations. The ability to deploy DNS in primary – secondary mode is either difficult or flat out unsupported. Given the significant trade-offs and sacrifices that are the price of using DNSSEC, it is no surprise that most businesses are opting out.

Our objective from the start was to offer DNSSEC without these trade-offs. Here is what we did:

  • We use online signing. NS1 has the most comprehensive and advanced set of DNS traffic management features in the industry so there was no way we were going ask customers to give that up in exchange for using DNSSEC. All of NS1 filter chains work with DNSSEC.
  • Fast response. Online signing means we sign every query response. This is computationally expensive so we took major steps to make sure the extra load on our servers would have no impact in DNS response time. We redesigned our DNS server software for efficiencies across the board and our engineering team delivered stellar results. We actually get faster responses with signed responses on the new platform than we were getting with unsigned responses on the previous platform.
  • No compromises DNS redundancy. Our solution for redundant DNS (Turnkey Dedicated DNS) has been very well received by customers because no other approach delivers both advanced traffic management and single pane of glass management simplicity. We clearly were not going to ask customers to give that up in exchange for using DNSSEC. Our Turnkey redundant DNS solution is fully supported with DNSSEC.
  • Support for dual provider primary – secondary DNS configurations. We recognize that many customers want to keep two DNS providers. Our engineers are working hard on that too. We have verified DNSSEC support with NS1 as primary to Dyn and over the coming weeks we will be adding more verified dual provider set-ups.
  • Future ready. Aside from the fundamental issue and impact of online vs offline signing, there are other implementation details of DNSSEC that are (or should be) important to customers. One is choice of signing and hashing algorithm. We use algorithm 13 (ECDSAP256SHA256). This has the benefit of being computationally efficient, reduces the size of DNS responses and is cryptographically strong so key rollover events are less frequent. We also implemented NSEC “black lies” to protect the privacy of record names within a zone.

Our overarching design goal was to deliver DNSSEC without the compromises and we do think this is a big deal. It is a truism in the IT industry that security that is too hard to use is usually ignored. We don’t want to see that with DNSSEC, because the security it provides is important. We hope that our efforts along with the efforts of other providers as they refine their support for DNSSEC will move us to a more secure internet.