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

[Steve Crocker]

Having the old and new operators cross sign each other’s keys is, I
believe, the only foolproof way to get this done without losing validation.
  There are ways to minimize the damage, which you’ve obviously explored.

How much flexibility do you have in time and money?

Shumon Huque has been approaching this issue from a different perspective,
which is how to have multiple dns providers.  The idea is similar, but it
feels different to the providers because bringing the new one into
operation doesn’t immediately imply the first one will be shut down.

Another element to consider is how often changes are being made to the
zone.  It makes a difference if the zone is stable for a long time versus
changing frequently.

And to avoid the problem in the future, make sure the new operator will
cooperate if you want to add another operator down the line.

I have an interest in improving the mechanics and the rules so others won’t
have this problem.  When you have a moment, I’d like to discuss your help
in pushing on this.  Probably better off list.

Steve

On Mon, Mar 4, 2019 at 3:55 PM Anthony Eden <anthony.eden at dnsimple.com>
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>
> 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
>> 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
> _______________________________________________
> dns-operations mailing list
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20190304/f54f4dcb/attachment.html>