[dns-operations] Switching DNSSEC uncooperative operator - help, please

[Viktor Dukhovni]

> On Mar 4, 2019, at 3:34 PM, James Stevens <james.stevens at jrcs.co.uk> wrote:
> 
> What I tried (with a test zone) was to put both operator's DS keys in the parent, wait >24 hrs then switch all NS (parent & zone), all the time polling Google, Cloudflare and ISC's test bind & unbound to check for outage - using queries that would give NXDOMAIN answers, to avoid cached answers.

This has the effect of making both sets of KSKs valid, once the previous
DS RRs are sure to be gone from caches.

> NS ttl is 3600, DNSKEY ttl is 7200 and parent is dot-COM, so DS ttl is 86400

Until someone asks for the NS RRs explicitly, the NS records from the parent
tend to get cached and used, and NS records returned by .COM have a 2-day
TTL.

> ISC's servers both behaved the same - they kept validating on the old keys
> until the NS expired, then they gave SERVFAIL until the DNSKEY expired,
> then they switched and worked fine on the new keys.

When the cutover happens, various nameservers have cached copies of the
zone apex DNSKEY RRset from the previous servers, and these will be
typically be cached until expiration.  Since answers from the new nameservers
are not signed with those keys, failure is expected.

> If I can just get the old provider to carry the new DNSKEYs, it seems to
> me this would alleviate most of the outage.

It should be all, since you then pre-seed all caches with the upcoming keys
before directing queries to the new servers that have only those keys.

If I'm not missing some subtle scenario, whoever learns the new NS records
and subset of DNSKEYs, would presumably not later go back and query the
original servers.  (Rollback would of course be problematic)

> Failing that plan-b is to try and reduce the TTL on the NS & DNSKEY, to minimize the outage.

Yes, I'd drop the TTL to 300s for a few days, and do the cutover during
whatever time most resembles an acceptable maintenance window.

-- 
	Viktor.