[Freeipa-devel] DNSSEC: upgrade path to Vault

[Petr Spacek]

On 11.3.2014 21:19, Martin Kosek wrote:
> On 03/11/2014 07:40 PM, Simo Sorce wrote:
>> On Tue, 2014-03-11 at 11:33 +0100, Petr Spacek wrote:
>>> Yesterday we have agreed that DNSSEC support is not going to depend on Vault
> ...
>>> - walk through cn=masters,cn=ipa,cn=etc,dc=ipa,dc=example and check if there
>>> are any other replicas with DNSSECKeyImporterv1 service:
>>> a) No such replica exists -> delete old-fashioned keys from LDAP.
>>
>> I say we do this step unconditionally if we move to the vault, all other
>> DNS server have functional keys for a while anyway (should always have
>> at least 1 month autonomy), and we clearly state people must upgrade the
>> infrastructure in a week not in months. So we should never need to keep
>> old keys.
>>
>>> b) Another replica with DNSSECKeyImporterv1 service exists:
>>> - *Temporarily* run DNSSECKeyImporterv2 which will do one-way key conversion
>>> from Vault to LDAP.
>>
>> We do not need this, you must update all replicas to a vesion that knows
>> what to do and then they'll find the new keys where they are.
>>
>>> - DNSSECKeyImporterv2 can check e.g. daily if all DNSSECKeyImporterv1
>>> instances were deleted or not. Then it can delete old-fashioned keys from LDAP
>>> and also stop itself when all old replicas were deleted (and compatibility
>>> mode is not needed anymore).
>>
>> We also avoid this.
>> The *only* thing we really need to do IMO is that if a DNS server finds
>> out it's key for a zone are expired then it shuts down itself and makes
>> itself unavailable so clients will start falling over to another DNS
>> server and the admin will have to troubleshoot and resolve out why the
>> keys were not accessible. If the reason is that they forgot to update a
>> replica then they should just proceed and update and the DNS server will
>> restart after that (we may want to make sure we have a way to pull the
>> latest key at upgrade or we have chick egg issue where replica update
>> fails because DNS does not start).
>>
>>> This approach removes time constraints from upgrade procedure and prevents DNS
>>> servers from failing when update is delayed etc. As a result, admin can
>>> upgrade replica-by-replica at will.
>>
>> I want time constraints and I want DNS server to fail fast.
>> constraints are in the order of 1 month though, not a few days.
>> I think 1 month is sufficient.
>
> Do we need to do this unconditionally for whole DNS service? Let's say admin
> has 2 zones, my-dnssec-testing-zone.test and my-production-zone.test and keys
> for my-dnssec-testing-zone.test expire. Is this a reason to shut down the
> whole DNS service? I do not think so.
>
> Could we return with NotAuth or ServFail instead? Would DNS client failover
> for other DNS server for that broken zone?

SERVFAIL encourages client to fail over. It could be tricky from 
implementation point of view but I will try it.

-- 
Petr^2 Spacek