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

[James Stevens]

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.



James


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.
> 
> Sincerely,
> 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
>     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
> 
> 
> 
> 
> 
>     _______________________________________________
>     dns-operations mailing list
>     dns-operations at lists.dns-oarc.net
>     <mailto:dns-operations at lists.dns-oarc.net>
>     https://lists.dns-oarc.net/mailman/listinfo/dns-operations
>     dns-operations mailing list
>     https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> 
> 
> 
> -- 
> DNSimple.com
> http://dnsimple.com/
> Twitter: @dnsimple