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.
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
