Re: [DNSOP] pushing updates to the parent

[Paul Wouters <[e-mail]>]

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