Subject: [DNSOP] Automating Provision of DS Records

From: Olafur Gudmundsson <[email-masked]>
Date: Tue, 11 Nov 2014 18:29:13 -1000

Hi,
as I mentioned at the mike: 

For those at the IETF-91 I will be hosting a Beach Bof for people that are
interested in working on creating an automated solution to this problem in
as short time as possible.

Send me an email if you are interested
Time: 15:00 @ Thursday
Loaction: TBD

Olafur

Call to Action: Automating Provision of DS Records to DNS Parents

Background

The DNS ecosystem is complex and problematic. Because there are many
relationships between domains and their “DNS parent”, and these
relationships are often convoluted, updating information for the parent is
difficult. This blog post will explore this issue in an effort to highlight
the need for an automated mechanism to inject DNS delegation information
into Parent DNS.

To get an idea of the convoluted nature of the DNS ecosystem, it will be
helpful to start with an example: If we were to sign the domain “example.com
”, the parent of this domain is “com”. However, .com is what’s known as a
“shared registration delegating domain following the ICANN rules”. This
means that the holder or owner of “example.com”, known as Registrant,
purchased or leased the domain from a Registrar or a Reseller authorized to
market domain names in .com.

After the Registrant pays for the domain, the Registrar updates a common
database called a Registry. The Registry holds information about the
Registrant, Registrar, and DNS servers for the domain. This information is
kept in a database operated by the Registry Operator. Registry Operators
also operate (or contract out) the DNS servers that list the registered
domains.

In most cases, the Registrant has a single account with the Registrar for
all its domains. However, there are three “handles” listed in the account:
Registrant, Admin, and Tech. And there are different ways that DNS for the
domain is handled:

   -

   The DNS can be handled by the Registrant
   -

   The Registrar can operate DNS (This is common when the domain is
   registered and operations are then moved.)
   -

   The Registrant can outsource the operation to a company like CloudFlare

For the three different kinds of DNS operators listed above, the difficulty
of changing information in the parent differs greatly. For the Registrant,
the process is fairly simple: they will need to log into their account and
change the information manually. Registrars can simply inject changes via
the programmatic interface they use to update the Registry. In the case of
third party operator like CloudFlare, it becomes a bit more difficult.
Third party operators need the Registrant to either hand over access to the
Registration account, or ask Registrant to pass information on---both of
those options have many potential problems.

To make matters worse, in many cases the third party operator has no
information on who the entity acting as a registrar for the domain is, or
how to contact them. Even if the DNS operator knows about the registrar, it
may not have any authority to make changes.

CloudFlare currently operates between 1-2 Million DNS domains for its
customers as a third party DNS operator. These registrations are in over
400+ TLD’s, and in unknown number of sub-delegation domains like “se.com”.
In only a few cases do we have access to domain registration accounts
because we are treated as unknown entity by Registrars and Resellers. When
we want DNS information changed, we need the Registrant to relay that
information, and the only time an registrant is motivated to log into his
or her registration account on our behalf is when we become the DNS
operator, or when DNS operation is moved away from us.

Our Goal: An Automated Solution to Update DNS Leveraging DNSSEC.

We would like to create a system where CloudFlare, and any other third
party DNS operators, can update the delegation DNS information in the
parent domains in a 100% automated manner. In the current registrations
system, we can, in theory, find out who the Registrar is via a WHOIS
query.  But, in many cases, the WHOIS query fails, or the information from
that query is not relevant. It might only return the name of Registrar,
Address of registrar, phone number, or even just a email address.

We are looking for ways to discover the correct entity that needs to be
contacted to insert the change into parent zone, or find out that there is
no such capability. In order to make this happen wwe want to leverage
RFC7344 <https://tools.ietf.org/html/rfc7344> and DANE like
<http://tools.ietf.org/html/rfc6698>technologies to build a solution that
is easy to manage, easy to operate, and is secure.

Path forward: What are the Missing Pieces?

There are three different problems that need to be addressed:

   1.

   Protocols for expressing to “parent representative/agent” what needs to
   be changed for a specific domain
   2.

   Protocols for finding the “Parent agent” delegation automation server,
   i.e., to be able to send message via the protocol developed for a to the
   appropriate party.
   3.

   Creating trust in the information in the child zone thus it can be moved
   into the parent zone.

Problem a is a simple definition of what data is submitted as a request.
The server contacted might be right one or one that issues a referral to
another server. Problem b is by far the most difficult one due to the
complexities of relationships involved. There are a number of different
ways this can be done. Problem c has to large extent been solved for DNSSEC
signed zones by RFC7433 <https://tools.ietf.org/html/rfc7344>, but there is
a missing element: establishing initial trust. At the end of the day, the
DNS operator wants a simple answer an URL for parental server or statement
saying “Not available”.

Problems a and c are best addressed by technical proposals in industry
forums, but finding the registrar is a much harder problem unless we can
get all parties in the registration industry to cooperate.

Call to Action

CloudFlare is willing to take the lead on creating a proposed solution, and
demonstrating the solution. The solution will be public and any tools we
create as part of the demonstration will be made available as open source.
We are looking for few interested parties to team up with us and having a
demonstration ready in few months.