[Opendnssec-develop] Zone moving between operators

[Rick van Rein]

Hello,

> I just want to make sure that the consequences of using a single key for multiple zones are understood, and that this behavior is not the "default" or "promoted".

Yep, it's more like the el cheapo, low-end profile of using DNSSEC
I suppose.  Still, I'd much rather get a lot of low-budget, few-domain
users online with DNSSEC than to outlaw them by way of design choices
in OpenDNSSEC and similar tools.  Or to make them abandon DNSSEC if the
first tool they look at (say, OpenDNSSEC) tells them off for wanting to
use a simple RSA stick.  ("I'm willing to invest as much as EUR 50 into
something I won't see the immediate benefits of, and still it's not
enough -- what a lousy technology" kind of reasoning.)

> I agree with Roy that we can not force a policy on the use of keys, but we can have an SLA on the registry system.
> The part I'm concerned about most is not the emergency key rollovers, but the regular key rollovers.

Ah!  Same argument -- given a suitable EPP it would be possible to update
them all in one (possibly massive) UPDATE statement.

> A dns-operator that has 100.000+ zones signed with a single key will have an operational issue when doing a rollover.

...and that's all their own fault...

> A wild guess from me is that the complete process of propagating a key change to the parent will take about 0,1 seconds per delegation.

So, the total delay would be under 3 hours... which is still quite acceptable!
Normal DNSSEC procedures would assume it could take more time.  Sounds like
you could tell people how much zones under a single key would work *in
practice*, which is probably the best way to convince people that they're
better off not to take the "el cheapo" shortcut through a USB RSA key if
they mean serious business.  That's ideal: You want people to feel your
pain/gain so they will automatically make the choices you would like them
to make.

> We cannot justify queuing other regular requests for such a long time, even more because it exceeds the time we generate new zonefiles.

Yes, you would want to allow for other changes at the same time, but the
DNSSEC policies would allow a week or so for such changes... or to be more
accurate, a parent is assumed to be taking some time, perhaps up to a week
or so, but at least at their (preferrably well-defined) discretion.

> I like Jelte's idea of defining some BCP for this, but that remains only a recommendation.

I like it too.  Even if it's just an advice formally, it will give registries
something to point at while saying "if you think you can get away with having
many [bm]illions of domains under the same key, you should not be surprised
if it takes more than mere seconds to propagate the update".

It is important (and thank you for leading the discussion on it) to make any
such issues as clear as possible, so people rolling out DNSSEC will make the
choices that are optimal for the system as a whole.  A BCP is a great way of
writing down any advice on such choices.

> My real question is if we need to safeguard such recommendation in the design of OPENDNSSEC, or that we leave it completely to the user without warnings, at the risk the user blaims the software not working properly.

The approach I would follow is to setup defaults that are safe (such as having
a different key for each domain signed) and allow for enough breadth of choice
to enable the domain admin to mindfully make choices that would not be
advisable in general.  You do not want to make choices "for safety sake" that
block functionality that may in some cases be useful.  That would land in the
same category as "every user should be able to live with 640 k RAM" (*)


Best,
 -Rick

(*) I still happen to think this is quite a lot, but that's only because I
    also do embedded coding ;-)