[dns-operations] Outdated RIPE NCC Trust Anchors in Fedora Linux Repositories

[Mark Andrews]

In message <65432E0B-B0D0-45C3-BB15-B4FC2357CA60 at nzrs.net.nz>, Jay Daley writes
:
> 
> On 8/02/2010, at 4:31 AM, Shane Kerr wrote:
> 
> > ...
> > =
> 
> > I am wondering if we can also take something here to the reoccurring
> > debate about the utility of regular KSK rollovers.
> > =
> 
> > In that debate, one argument is that since there is no cryptological
> > motivation for a KSK rollover, that these should be done only when the
> > KSK is possibly compromised. The other argument is that we need to do
> > regular rollovers so that when an emergency rollover is necessary it
> > will work.
> > =
> 
> > This strikes me as indicating that even with regular rollovers, things
> > will still break. Which kind of supports the idea of rolling over only
> > in emergency, doesn't it? At least in that case you *might* never have
> > to go through the pain of making some domains go dark for some users....
> 
> I have a lot of sympathy for this view but I still have some questions unre=
> solved:
> 
> 1.  Is this pain if it happens, actually necessary to ensure that people le=
> arn to do things properly?
> 
> 2.  Can a regular KSK rollover be scheduled to minimise the impact of the p=
> ain (in my TLD is certainly can because most of our registrants are in the =
> same time zone) and would learning the lessons that way reduce the pain if =
> any emergency KSK rollover were needed, which presumably could not be sched=
> uled so?
> 
> 3.  Do we need to apply "Rumsfield's Razor" (tm) to this problem - "There a=
> re known unknowns. That is to say, there are things that we now know we don=
> =92t know. But there are also unknown unknowns. These are things we do not =
> know we don=92t know." - and so be rolling KSKs in case they have been comp=
> romised but we just don't know about it?
> 
> any views?
> 
> Jay

As long as your parent is signed and you don't publish trust anchors
outside of the DNS you are fine to roll keys.  If you get it wrong
the pain will be short lived once you correct the stuff up.  DS,
DLV and DNSKEY records all have TTL's on them so they will flush
from the system without reconfiguration of validators being required.

For zones that need to have trust anchors configured there is RFC5011
but RFC 5011 support is still being rolled out.  I don't know whether
this will be enough or not.  It should have helped with the RIPE
NCC trust anchors as the new keys were published early enough for
a RFC 5011 client to follow.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org