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.

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

When CloudFlare customers enable our DNS services for their domain, we allocate and provide them with nameservers. After the customer configures various records within their domain (e.g., A, AAAA, MX, CNAME, etc. records) on the CloudFlare system, customer’s then need to go back to their Domain Registrar and manually update their NS records so they match the NS information provided by CloudFlare. Once the NS records have been changed, CloudFlare becomes the authoritative DNS operator for that zone.

This manual process is outdated, and there is only one thing standing in the way of an automated process—the current domain industry registration model.

The domain registration system includes Registrants (Resellers and Registrars), Registries, and ICANN, and there are strict rules about how information flows through it:

Note: A full glossary of the terms used in this document is available from the ICANN website.

Notice that DNS Operators are not included in the ICANN diagram above. When this model was created, no one one thought that DNS service might be provided by someone other than Registrant and Registrar. Things have changed, but unfortunately, the system and its rules haven’t.

In nearly all cases, CloudFlare customers are using a Registrar where CloudFlare’s relationship with the customer is not explicitly expressed. The relationship can only be inferred by the NS records that point towards CloudFlare, or by the fact that nameserver addresses that are in CloudFlare address spaces. This omission of 3rd party DNS operators in the ICANN model causes operational difficulties.

Operational difficulties arise currently because the only way to find the Registrar of a domain name is to query for the “whois” information. Below is an selected output from a successful whois query:

Domain Name: CLOUDFLARE.COM ... Registrar WHOIS Server: whois.networksolutions.com Registrar URL: http://networksolutions.com ... Registrar: NETWORK SOLUTIONS, LLC. Registrar IANA ID: 2 ... Registrant Name: CloudFlare, Inc.

All domain updates (such as postal address or name server changes) go from the customer (or Registrant) to the Registrar before being sent to the Registry. As a DNS Operator, CloudFlare is separate from these R-named entities so we don’t show up in a whois query.

The difficulty is that whois information, which may contain postal addresses, telephone numbers, and/or email addresses, is designed for human consumption and human action. Because this information has historically been changed by people, there isn’t a protocol specified regarding how a DNS operator’s system can ask a registrar for changes in delegation information in an authenticated automated way.

In the current ICANN system there are roughly three classes of DNS operators. These classes are based on the ability of DNS operators to make changes in the delegating parent zone:

Registrars/Resellers—Have direct interface to the registry database, and can change information at will and instantly.

Registrant—Have a User Interface (usually web) to update information

Third Party DNS Operator—Need either the registrant to update information on its behalf, or have access to the registrants account with registrar (which is a bad security practice). In reality, DNS operators can only expect registrants to log into the account on two occasions: a. when service is moved to Operator, or b. when service is taken away from operator.

CloudFlare is advocating to gain the ability to update NS records for our customers and address records associated with them using automated channels. Our goal is to be able to add and remove nameservers from customer domains without the customer being involved.

Creating an automated process for updating NS (and DS) records would help solve the operational difficulties to providing DNS service, and would open up new possibilities for the Internet as a whole. If DNS operators had control of NS and DS records they could re-balance nameservers for stability, quickly change nameservers that go bad, and even better protect customers against DDoS attacks. Most people don’t know that when certain NS records come under heavy DDoS attack, all customers that share that nameserver might also experience a degradation in service. If those NS records could be changed quickly, we could lessen the impact on domains that are not being targeted.

Perhaps the most important reason for automating DNS operator’s access customer NS and DS records (Delegated Signer Record) is that this change would pave the way for DNSSEC implementation. DNSSEC requires maintaining DS records because they have to be inserted into the parent domain and potentially updated on a regular basis. If this record is not properly maintained, then DNSSEC validation fails, making the domain inaccessible. Presently, this is done through a web interface at the Registrar by the Registrant.

In theory, the Registrant could designate the DNS Operator as Technical Contact, but that doesn’t help unless the Technical Contact is given full access to the Registrant’s account since most Registrars don’t provide role-based access to accounts. In any case, asking our customers to update their delegation information in order to reflect the DNSSEC trust chain is problematic. One issue with this approach is that if CloudFlare were to ask hundreds of thousands of customers that own millions of domains to make manual updates to their records, there would be a huge chance of error. If records are updated incorrectly, it would not only cause frustration, it might cause the site to go down due to DNSSEC errors.

CloudFlare could try to minimize these errors by publishing CDS and or CDNSKEY records in each zone, that the registrar can pick up via DNS query and apply. But the long term solution is full automation with authorized updates to delegation information.

Some will say that the current system will work if the DNS operator is designated as Technical Contact (one of the roles defined in the ICANN model) but almost no Registrar offers a role based accounts for customers. All that does is to decrease the probability that phone call or email from Technical contact is dismissed as social engineering attack.

CloudFlare wants to team up with Registrars, Registries, and other DNS Operators to define and deploy more reliable methods for updating NS and DS records. We think this would be a big win for our customers, and, ultimately, for the internet as a whole. If you’re interested in participating in this process, you can sign up for this mailing list: dnssec-auto-ds@elists.isoc.org