[ksk-rollover] Suggested update to the key ceremonies.

Mark Elkins mje at posix.co.za
Thu Feb 15 08:32:08 UTC 2018


I'd agree with you on this.

I run a small ISP and have been offering DNSSEC to clients for a few
years now. Most of my own domains are signed (very few customer
domains). I store DNS records in a Database and at time of writing have
339 DNSKEY records. None of the Key-ID's are duplicates. For some
domains (e.g. Reverse DNS that is signed), duplicate Key ID's could lead
to human error as (certainly at AfriNIC) DS Records need to be managed 
via cut'n'paste into a web form. Old records also need removing. Having
duplicate Key ID's could lead to confusion.

I also find the Key ID a useful "handle" for debugging.

I have some code that when any DNSKEY is generated (KSK/ZSK) - that
checks that the Key ID is unique on my system - otherwise go create a
new one (very old code). Unfortunately, I don't generate stats on this -
or know whether its ever been used. I will one day have to modify this
behaviour as more domains are signed - probably just unique to the
domain in question.

i.e. I at least look for duplicate Key ID's in order to reduce potential
fragility to my own systems.


On 14/02/2018 22:40, Warren Kumari wrote:
> Apologies if this isn't the right place to propose this - the
> ksk-ceremony list didn't feel right...
>
> I think that it would be a useful addition to the script to ensure
> that, when a new KSK is generated, it does not have the same Key ID as
> any previous KSKs. It is *does* have the same Key ID, it should be
> discarded and a new one generated.
>
> Rational: If we end up with multiple keys with the same Key ID it
> becomes very tricky to run things like RFC8145, KSK Sentinel, etc.
> Also, when doing troubleshooting / diagnostics, the key ID is an easy
> thing to use to differentiate keys.
>
> This has long been source of low level concern for me, and I've been
> assured that if there were collisions during the ceremony, the right
> thing would likely happen -- but I think that this is worth explicitly
> noting what happens.
>
> I *did* look at the scripts, and didn't see a note on this; 'pologies
> if it is already covered and I missed it.
>
> W

-- 
Mark James ELKINS  -  Posix Systems - (South) Africa
mje at posix.co.za       Tel: +27.128070590  Cell: +27.826010496
For fast, reliable, low cost Internet in ZA: https://ftth.posix.co.za



More information about the ksk-rollover mailing list