Introducing DNS Resolver, 1.1.1.1 (not a joke)

Cloudflare’s mission is to help build a better Internet and today we are releasing our DNS resolver, 1.1.1.1 - a recursive DNS service. With this offering, we’re fixing the foundation of the Internet by building a faster, more secure and privacy-centric public DNS resolver. The DNS resolver, 1.1.1.1, is available publicly for everyone to use - it is the first consumer-focused service Cloudflare has ever released.

We’re using the following IPv4 addresses for our resolver: 1.1.1.1 and 1.0.0.1. Easy to remember. These addresses have been provided to Cloudflare by APNIC for both joint research and this service. You can read more about their work via the APNIC blog.

DNS resolver, 1.1.1.1, is served by Cloudflare’s Global Anycast Network.

Background: A quick refresher on the role of the resolver in DNS

Our friends at DNSimple have made this amazing DNS Tutorial for anyone to fill in their gaps on how DNS works. They explain all about resolvers, root name servers, and much more in a very informative way.

When resolving a domain name, a query travels from your end system (i.e. a web browser) to Continue reading

It’s Hard To Change The Keys To The Internet And It Involves Destroying HSM’s

Photo by Niko Soikkeli / Unsplash

The root of the DNS tree has been using DNSSEC to protect the zone content since 2010. DNSSEC is simply a mechanism to provide cryptographic signatures alongside DNS records that can be validated, i.e. prove the answer is correct and has not been tampered with. To learn more about why DNSSEC is important, you can read our earlier blog post.

Today, the root zone is signed with a 2048 bit RSA “Trust Anchor” key. This key is used to sign further keys and is used to establish the Chain of trust that exists in the public DNS at the moment.

With access to this root Trust Anchor, it would be possible to re-sign the DNS tree and tamper with the content of DNS records on any domain, implementing a man-in-the-middle DNS attack… without causing recursors and resolvers to consider the data invalid.

As explained in this blog the key is very well protected with eye scanners and fingerprint readers and fire-breathing dragons patrolling the gate (okay, maybe not dragons). Operationally though, the root zone uses two different keys, the mentioned Trust Anchor key (that is called the Key Signing Key or KSK for Continue reading

What happened next: the deprecation of ANY

Almost a year ago, we announced that we were going to stop answering DNS ANY queries. We were prompted by a number of factors:

1. The lack of legitimate ANY use.

2. The abundance of malicious ANY use.

3. The constant use of ANY queries in large DNS amplification DDoS attacks.

Additionally, we were about to launch Universal DNSSEC, and we could foresee the high cost of assembling ANY answers and providing DNSSEC-on-the-fly for those answers, especially when most of the time, those ANY answers were for malicious, illegitimate, clients.

Although we usually make a tremendous effort to maintain backwards compatibility across Internet protocols (recently, for example, continuing to support SHA-1-based SSL certificates), it was clear to us that the DNS ANY query was something that was better removed from the Internet than maintained for general use.

Our proposal at the time was to return an ERROR code to the querier telling them that ANY was not supported, and this sparked a robust discussion in the DNS protocol community. In this blog post, we’ll cover what has happened and what our final plan is.

Just before we published our blog a popular software started using ANY queries, to get all address Continue reading

Updating the DNS Registration Model to Keep Pace with Today’s Internet.

CloudFlare is, arguably, the largest third-party DNS Authoritative operator in the world. We manage well over 1 million domains and have registrations in almost every TLD open for registrations. Our role as a DNS operator is to maintain customer information and publish their records in the global DNS.

In this blog, we’ll introduce a significant problem that DNS operators like CloudFlare face when trying to provide the best possible experience to our customers. If you are a CloudFlare customer, you’ll remember during the sign up process you were asked to login to your registrar account in order to change your nameservers (NS). The absence of an automated process for changing NS records not only makes our signup process one step longer than we’d like, it also prevents CloudFlare, and other 3rd party DNS operators, from doing a slew of other things that would benefit customers and the Internet as a whole.

Note: In this blog we’ll use the term DNS Operator mainly in the context of operators that provide Authoritative DNS service. This is sometimes called Managed DNS service.

Manual Updates

For those who are not yet CloudFlare customers, let’s run through the sign up process:

When CloudFlare customers enable Continue reading

DNSSEC Done Right

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 Continue reading