O BIND 9.16 introduziu um novo dnssec-policy
recurso como um recurso de assinatura e gerenciamento de chaves DNSSEC mais automatizado sobre a auto-dnssec maintain
funcionalidade estabelecida há muito tempo.
A documentação não parece cobrir a migração do antigo para o novo, mas a página wiki relacionada parece indicar que as chaves já existentes seriam selecionadas pelo dnssec-policy
.
Dito isso, configurar uma nova zona com dnssec-policy
é bastante simples, mas migrar uma zona existente de auto-dnssec maintain
para dnssec-policy
não parece funcionar como se poderia esperar.
O que eu esperava era que uma política compatível com as chaves existentes continuasse usando essas chaves.
O que parece acontecer é que todas as chaves existentes são imediatamente excluídas da zona porque "expiraram" e são substituídas por novas chaves, mesmo que a nova política exija um conjunto compatível de chaves (mesmo algoritmo e tamanho) e as chaves existentes tenham sem propriedades de fim de vida definidas (somente Created
, Publish
e Activate
tempos nos arquivos .key).
A política que usei ao testar se parece com isso (nomeada para refletir o que é o que durante o teste):
dnssec-policy alg13-ksk-unlimited-zsk-60day {
keys {
ksk key-directory lifetime unlimited algorithm ECDSAP256SHA256;
zsk key-directory lifetime P60D algorithm ECDSAP256SHA256;
};
};
Esta é a saída do log quando a configuração mudou de auto-dnssec maintain;
para dnssec-policy alg13-ksk-unlimited-zsk-60day;
:
zone zone.example/IN (signed): reconfiguring zone keys
keymgr: DNSKEY zone.example/ECDSAP256SHA256/49004 (KSK) created for policy alg13-ksk-unlimited-zsk-60day
keymgr: DNSKEY zone.example/ECDSAP256SHA256/54646 (ZSK) created for policy alg13-ksk-unlimited-zsk-60day
Removing expired key 20481/ECDSAP256SHA256 from DNSKEY RRset.
DNSKEY zone.example/ECDSAP256SHA256/20481 (ZSK) is now deleted
Removing expired key 12506/ECDSAP256SHA256 from DNSKEY RRset.
DNSKEY zone.example/ECDSAP256SHA256/12506 (KSK) is now deleted
Fetching zone.example/ECDSAP256SHA256/49004 (KSK) from key repository.
DNSKEY zone.example/ECDSAP256SHA256/49004 (KSK) is now published
DNSKEY zone.example/ECDSAP256SHA256/49004 (KSK) is now active
Fetching zone.example/ECDSAP256SHA256/54646 (ZSK) from key repository.
DNSKEY zone.example/ECDSAP256SHA256/54646 (ZSK) is now published
DNSKEY zone.example/ECDSAP256SHA256/54646 (ZSK) is now active
zone zone.example/IN (signed): next key event: 22-Mar-2020 15:08:19.805
Como pode ser visto, as chaves existentes foram imediatamente excluídas (nem mesmo seguindo o procedimento normal de rollover!) e substituídas por novas chaves do mesmo tipo.
Considerando que apenas substituir instantaneamente as chaves em vez de seguir o procedimento de rollover pretendido quebra tudo, é evidente que simplesmente mudar a configuração para dnssec-policy
não é possível.
Observando os arquivos de chave, noto que um .state
arquivo adicional é adicionado lado a lado com as chaves antigas e novas.
Não sei se este arquivo é um requisito para o bom dnssec-policy
funcionamento de alguma forma? Ter esses arquivos criados antecipadamente de alguma forma evitaria esse comportamento?
A questão central é: existe uma maneira de migrar para o uso dnssec-policy
de maneira não disruptiva? Se sim, como?
O comportamento descrito na pergunta foi um bug, que deve ser resolvido a partir do BIND versão 9.16.2.
Das Notas de Versão do BIND 9.16.2 :