On Sat, 8 Mar 2014, Mark Andrews wrote:
Our audience should be the CPE developer with the one "turn on DNSSEC" button which generates the keys, signs the zone, pushes keys upstream at the right time. It has a username/password field for zones where it is not automatically installing KEY records as part of the automatic delegation process.
Buy router. Configure DNS. CPE uploads DS record. I forget my password, factory default the firmware, configure DNS, attempt to upload a new DS record. Either: a) authentication fails and my domain remains broken b) it works, meaning any CPE compromise will lead to massive DNSSEC circumvention. Neither are desirable, and why people wanted the update systems to be bootstrapped externally and did not want to allow the update mechanism to change the security status of zones.
The second audience is the DNSSEC Key management tool developer which has a policy file which says "roll the key for this zone monthly/yearly" and just ensures it happens.
This works with any of the proposals, once you boostrap via EPP. I don't know many people who want to bypass the bootstrap.
nsupdate is how one does it today because the other bits of software that will use the method have not yet been written because we (the IETF) haven't provided them with a full standardised solution which works everywhere.
I think we have. But registrars don't provide a unified method for updating that information to _their_ customers. They could easilly setup their own EPP channel to talk to their registrants and avoid using custom website GUIs. Some, like gkg.net, provide nice and simple JSON API's, but the location and format is not standarised (but could easilly be if registrars want that). ICANN did well in enforcing the location for registrant facing services like WHOIS for the new GTLDs. Perhaps it can extend this for other registrant-facing services like DS update. Using EPP here would make a lot of sense.
nsupdate is the proof of concept tool. It is the fill the gap tool until the others are written. It is the fix it tool.
nsupdate can never fix the bootstrap. The initial authorization that allows signed zone content to be trusted by the registrar to make domain registry modifications but involve a human.
However in all cases we have RRR and non-RRR managed zone and the tools need to work with all of them.
The initial bootstrap problem is the same for RRR and non-RRR, unless parent and child are under teh same administratiev control, in which case it should already be handled. (A previous DNS signer product I worked on fully automated rollovers if parent and child were managed by it)
We also have nameservers that are being renumbered that need to push new glue records for themselves to the parent zones. This will happen with both signed and unsigned zones and their is no "scraping" solution that works for this senario.
You still need an authorization step there for the RRR case. I believe, and I think the WG concensus was the same, that the best way for that authorization step was to use out of band EPP using the KSK. In other words, once you get the KSK at the registrar, you can use signed records within your zone for signaling without requiring another set of credentials. nsupdate requires a new set of credentials, as well as a new API as to where to send the nsupdate to, possibly with new firewall holes. It requires dynamic zones or custom software pretending to run dynamic zones to take the update. The domain owner would need to keep another secret on their "live nsupdate machine" apart from the private KSK key. Using zone data for signaling also works for the non-RRR use cases. These were all reasons for the WG to agree on signed zone content as an authorization method for parent updates. Paul _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
