Folks, I've started a new mailing list for discussion of how to facilitate both DS updates and cross-signing of zones when there are multiple DNS providers. My tastes run toward "push/registrar" solutions for DS updates, but it's certainly possible to use pull instead of push and registry instead of registrar. RFC 8078 is a pull/registry solution. I believe some ccTLDs are using it, but I have not seen any traction within the gTLD community.
I'm hoping one or more concrete proposals emerge from the interactions on this list. If they do, they will be submitted through the usual channels for adoption. (Some aspects will likely be appropriate for the IETF; others for ICANN or other bodies.) This activity is therefore a design team. The new mailing list is [email protected] Comments are welcome, as is membership on the list. Thanks, Steve ---------- Forwarded message --------- From: Steve Crocker <[email protected]> Date: Sun, Jan 19, 2020 at 12:16 PM Subject: Adding DNS providers to the registration To: DNSSEC Provisioning <[email protected]> I hereby propose that RDDS be extended to include the DNS provider(s). I believe that making DNS providers visible in the registration will make it easier to automate both the upward movement of DS records to the registry and coordination of cross-signing when there are multiple DNS providers. DNS service is generally provided in one of three ways: - By the registrar. This is probably the most common in terms of number of registrations, but not as common for larger registrants. - By the registrant as part of its internal operation. - By 3rd party DNS providers, e.g. Cloudflare, Dyn, et al. Some registrants, particularly large registrants, will use multiple DNS providers, so my proposal permits naming more than one DNS provider. The intended functionality is for DNS providers to be able to push new DS records upward whenever they roll the keys. Accordingly, I'm expecting that in addition to simply adding the name of the DNS provider to the registration, the registrar will also have an access path for the DNS provider to send it new DS records. This leads to some design questions: 1. How should DNS providers be designated? The designation should be easy for the registrant to specify and not easily confused. 2. The designation should serve as authorization for the DNS provider(s) to act on behalf of the registrant. 3. In addition to updating the DS records, it seems sensible to have the DNS provider specify the NS records as well. What about glue records? 4. Would DNS providers need to be qualified before being allowed to be included in the registration? My quick thought is no because there are no barriers today in setting the NS records. 5. Do we need a common naming scheme for DNS providers. Perhaps something like _dns-provider.<domain name> would do the job. It also seems to me that whenever a DNS provider is added to or removed from a registration, both it and any other DNS providers receive notification. This should trigger the appropriate coordination. To take the easiest case, here's a sequence for the registration with a single 3rd party DNS provider. 1. Registrant registers the domain name with the registrar. 2. Registrant contracts with the DNS provider for DNS service and populates the child zone. 3. Registrant tells adds the name of the DNS provider to the registration. 4. Registrar's process sends a notice to the DNS provider that it has been named as a DNS provider for the registrant's domain. 5. DNS provider tells the registrar the list of nameservers, the DS record and any other details that may be needed. Comments? Suggestions? Problems? Thanks, Steve
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
