[dns-operations] Switching DNSSEC uncooperative operator - help, please
james.stevens at jrcs.co.uk
Mon Mar 4 21:47:58 UTC 2019
That's very interesting - I never thought the algorithm would make any
difference. There is no mention of it in RFC-6871/4.3.5
Currently they are different - this was also a motivation for switching
- old=SHA-1 , new=ECDSA256
I might be able to get the providers to sync algorythms.
On 04/03/2019 20:48, Anthony Eden wrote:
> Is the algorithm remaining the same between the two providers?
> If so then having both provider's DS records and changing the delegation
> should work, but you probably want to leave the old DS record present
> longer before removing it. We are leaving old DS records a minimum of 48
> hours (for example, when removing DNSSEC, and longer when we rotate
> keys, but that's more to give customers more time to add the DS where
> automation isn't possible).
> If the algorithms are different... well, then you're stuck so far as I
> can tell - both providers need to use the same algorithm.
> Anthony Eden
> On Mon, Mar 4, 2019 at 3:38 PM James Stevens <james.stevens at jrcs.co.uk
> <mailto:james.stevens at jrcs.co.uk>> wrote:
> 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
> 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 ?
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> <mailto:dns-operations at lists.dns-oarc.net>
> dns-operations mailing list
> Twitter: @dnsimple
More information about the dns-operations