DNSSEC Done Right (original) (raw)
2015-01-29
4 min read
This blog post is probably more personal than the usual posts here. It’s about why I joined CloudFlare.
I’ve been working on DNSSEC evolution for a long time as implementor, IETF working group chair, protocol experimenter, DNS operator, consultant, and evangelist. These different perspectives allow me to look at the protocol in a holistic way.
First and foremost, it’s important to realize the exact role of DNSSEC. DNSSEC is actually a misnomer: it’s from an era when the understanding of different security technologies, and what role each plays, was not as good as today. Today, this protocol would be called DNSAUTH. This is because all it does is to provide integrity protection to the answers from authoritative servers.
Over the years, the design of DNSSEC has changed. A number of people working on early versions of DNSSEC (myself included) didn’t know DNS all that well. Similarly, many DNS people at the time didn’t understand security, and in particular, cryptography all that well. To make things even more complex, general understanding of the DNS protocol was lacking in certain areas and needed to be clarified in order to do DNSSEC properly. This has led to three major versions of the protocol. The first two were not deployable for various reasons. Some of the decisions made, in hindsight, were sub-optimal. They were artifacts of constraints placed on the design by the DNS protocol itself, understanding of DNS, and various operational realities. DNSSECv3 [RFC403x], however, is deployable.
Today, we have wide spread deployment of the crucial building blocks for DNSSEC:
- Root and TLDs: over 2/3’rds of the TLDs are signed
- Most DNS software is DNSSEC enabled
- Many registrars offer their customers DNSSEC support either by signing the customers zones or by adding DS records into the parent zones.
What’s missing is having Enterprise zones signed, and turning on validation in resolvers and clients. It’s estimated that over 10% of all user DNS answers today are validated, but how much is validated in data centers is unknown.
DNSSEC deployment has been what I call a game of “excuse elimination”. First it was “com will never be signed”, then “the root will never be signed”, then “the answers will be too big”, and so on. Right now, the main excuse is, “this important domain is not signed”. Getting CDNs to sign is a great step towards getting the important domains signed. This is because CDNs frequently act as DNS operators for such domains.
So what does all of this have to do with me joining CloudFlare? Well, when a friend mentioned to me that CloudFlare was looking for a DNS person I checked them out. CloudFlare impressed me by wanting to do things correctly right from the beginning, and people here are not afraid to do things differently if it’s better. CloudFlare had been thinking about doing DNSSEC, and wanted me to help them implement and deploy it. This is turning out to be a fun project not just because of the scale, but also because of the ability to take a fresh perspective and questioning all prior assumptions.
CloudFlare’s DNS servers provide answers from over 30 anycasted data centers all over the world. We operate lots of DNS servers—authoritative for millions of zones. Not all the servers return the same answers to all clients because of policies and locations. Furthermore, much of the DNS data we serve has geographical bias. Thus, some data centers never see a query for that data. In this environment the only realistic way to answer the question is to generate the signatures at the edge on demand. This is a radical departure from most DNSSEC implementations, but there are few implementations like PowerDNS that have this capability. What online signing does is significantly reduce the volume of data that has to be transferred to the edge. We’ve designed our systems to only transfer signed DNSKEY (and CDS) records to the edges, while everything else is signed there. This requires transferring the zone signing keys to the edge.
CloudFlare is a frequent target of DNS attacks, both against our customers and as an reflector/amplifier. For that reason, we are fanatical about keeping DNS answers as small as possible to minimize the damage our systems can do to others when used as a reflector. This has directed us in a number of choices on how we do DNSSEC.
First, we use the Elliptic Curve algorithm ECDSA P-256. A ECDSA key is stronger than most RSA keys used today and the signatures are much smaller. Also, it takes fewer CPU cycles to generate the signatures than with RSA making this is a double win for us. When we started on the project, we found only one Validating Resolver implementation that did not support ECDSA. We reached out to them and now Google Public DNS correctly validates ECDSA!
Second, we do negative answers in a special way. Negative answers in DNSSEC can get large. For zones signed with NSEC, it’s not uncommon to have SOA + RRSIG(SOA) + 2 NSEC records + 2 RRSIG(NSEC) records in the negative answers. Even for the weakest RSA keys allowed, this results in an answer that is at least 635 bytes. NSEC3 signed answers require, in most cases, 3 NSEC3 and 3 RRSIG (NSEC3) records to deny the existence of the item asked for—that’s at least 1000 bytes. So we selected NSEC as our negative answer and use ECC keys. But the biggest saving comes from not having to prove that the covering wildcard exists at all, which is the role of the second NSEC record. We return an answer that says, “sure, the name exists, but the type you asked for does not”. This allows us to return only one NSEC record in negative answers!
In the past, NSEC records have been criticized for leaking information about the zone contents. Our implementation of negative answers allows us to provide negative answer with no value for a zone walker. Thus, our customers will gain the best possible defense against zone walking.The net result of our careful engineering of DNS answers is that we are able to keep most of our signed answers under 512 bytes. There are, however, exceptions, like when customers have large answers or long names but that is unavoidable.
Today's announcement regarding CloudFlare's alpha DNSSEC support is the first step towards providing a comprehensive DNSSEC offerings to our customers. We plan on offering DNSSEC to all our customers soon.
Cloudflare's connectivity cloud protects entire corporate networks, helps customers build Internet-scale applications efficiently, accelerates any website or Internet application, wards off DDoS attacks, keeps hackers at bay, and can help you on your journey to Zero Trust.
Visit 1.1.1.1 from any device to get started with our free app that makes your Internet faster and safer.
To learn more about our mission to help build a better Internet, start here. If you're looking for a new career direction, check out our open positions.