[dns-operations] Switching DNSSEC uncooperative operator - help, please
James Stevens
james.stevens at jrcs.co.uk
Mon Mar 4 20:34:24 UTC 2019
I'm working with a large client who is currently trying to change their
DNSSEC signing operator. The client is *very* against going unsigned, if
it can be avoided.
Of course, option-1 would be to follow RFC-6781 - but looks like that's
not going to be possible :(
Currently neither operator appears to support adding each other's
DNSKEYs in the zone. I have tickets open with both, but I'm not holding
my breath.
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.
NS ttl is 3600, DNSKEY ttl is 7200 and parent is dot-COM, so DS ttl is 86400
Cloudflare switched to validating with the new keys pretty much
immediately, with very little outage.
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 orked fine on the new keys.
Google was odd - they switch randomly and gradually - 7 hours later some
of their servers still hadn't switched (i.e were giving answers
validated using the old keys) and they were often refreshing the TTL on
the old DNSKEYs - I can't see how that could be correct behavior after 7
hours?? 24 hrs later they had completely switched to the new keys.
If I can just get the old provider to carry the new DNSKEYs, it seems to
me this would alleviate most of the outage.
Failing that plan-b is to try and reduce the TTL on the NS & DNSKEY, to
minimize the outage.
Plan-Z is unsigned for 24 hrs :(
So questions
1) Am I right that Google is behaving oddly?
2) Anybody got any better ideas for switching while avoiding going
unsigned and avoiding outage ?
James
More information about the dns-operations
mailing list