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

_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Reply via email to