[nsd-users] DNSSEC and registrar rollover

[Michael A. Peters]

A bit off topic, I don't know the right place to share this concern. I'm 
guessing there's an IETF list?

I found http://dnssec.ietf.org/ but no mention of list.

https://datatracker.ietf.org/list/wg/ does not have a DNSSEC list listed.

Going through the process of rolling over the key signing keys for many 
of the domains I administer. I only rollover KSK about every 18 to 24 
months, not often.

The proper way is to have registry add new DS record, sign zsk with 
both, when properly propagated through caching resolvers, safe to stop 
signing with old ksk and remove old DS records.

That's easy when there's an interface that lets me do it without support 
staff involved.

Issue is that not all top level domains have API set up to do that 
through my registry (namecheap) - .email for example does not, I have to 
contact support staff.

Unfortunately, and I do not know if it is registry incompetence or TLD 
incompetence, they sometimes don't just add the new DS and then wait for 
another support request to remove the old DS once the rollover has aged 
- even though that is what I ask for.

Sometimes they add the new DS and immediately remove the old, resulting 
in DNSSEC failure until things propagate.

This has to be addressed, TLD registrars need to have mechanism in place 
to allow DNS administrators to add DS records and remove records w/o 
needing to go through technical support that seem to sometimes not 
understand why it is important to NOT remove the old DS records until 
specifically requested to do so.

Websites going offline and e-mail delivery being delayed because of 
improper KSK rollover by support staff will both discourage rotation of 
KSK and discourage use of DNSSEC.

Just like certificate authorities are now expected to provide CT and 
OSCP, registries should be expected to provide a standard API for DS 
records so that registrars can provide the necessary tool to allow 
addition and deletion of DS records w/o human error of support staff 
that rarely deal with DNSSEC and do not understand the process.