logoCert_sugestao2.png

Métodos de troca de chaves no DNSSEC

Introdução

A troca de chaves planejada vai depender da política de chaves DNSSEC da instituição. No caso do POP-BA, a ZSK é trocada a cada três meses e a KSK tem validade de 2 anos (veja mais detalhes). Existem dois métodos utilizados na troca de chaves: pre-publish e double-signing. Esse documento descreve de forma geral esses métodos e explica em que situações cada um deles deve ser utilizado.

Método pre-publish

No método pre-publish a ideia é adicionar uma ou mais novas chaves na zona antes mesmo delas serem de fato utilizadas para assinar registros. O objetivo dessa adição antecipada da chave é torná-la disponível no cache de servidores recursivos habilitados com DNSSEC antes da chave ser substituída. Além disso, após a assinatura da zona com a nova chave, a chave antiga é mantida na zona (mesmo que aparentemente não esteja sendo útil). Dessa forma garante-se a disponibilidade de ambas as chaves no cache do servidores recursivos, que devem utilizar todas as chaves disponíveis na validação de um registro, e evita-se falhas pela utilização incorreta da chave na validação.

Para ilustrar o funcionamento desse método, vamos acompanhar os passos de substituição de uma chave em uma zona fictícia. Para tal, assumimos que o TTL de qualquer registro na zona assinada é 24h (86400 segundos).
  1. No mínimo dois dias antes da expiração das assinaturas da zona (poderia ser qualquer momento antes), a nova chave (seja KSK ou ZSK) deve ser adicionada ao registro DNSKEY da zona. A zona é então re-assinada usando a chave atual, não a nova. A nova chave apenas estará presente à zona, porém ainda não será usada em nenhuma assinatura.
  2. Passado-se as 24h (tempo definido do TTL ou TTL máximo da zona), garantimos que o cache dos servidores recursivos contém o registro DNSKEY contendo ambas as chaves, a atual e a nova. Nesse caso, qualquer RR estará assinado com a chave atual e ainda não temos uso claro da nova chave.
  3. Nesse momento, a zona é re-assinada utilizando a nova chave. A chave antiga permanece disponível na zona.
  4. A partir desse ponto e nas próximas 24h (tempo definido do TTL ou TTL máximo da zona), a assinatura de qualquer RR requisitado à um servidor recursivo, por exemplo o RR A para www.exemplo.com, pode ter sido feita com a chave antiga (caso o RR já estava no cache) ou com a chave nova (caso o cache tenha expirado e o servidor recursivo obteve o registro novamente em um servidor autoritativo). Reforçamos que a especificação do DNSSEC diz que todas as chaves disponíveis deveriam ser checadas antes de rejeitar os dados como sendo inválidos. Em qualquer caso, um RR DNSKEY que irá autenticar com sucesso os dados estará no cache ou, se o RR DNSKEY tiver expirado ou não disponível no cache, pode ser obtido do servidor autoritativo.
  5. Depois de 24h da assinatura da zona com a nova chave, podemos garantir que todos os caches contém apenas registros assinados com a nova chave. A chave antiga pode então ser removida do RR DNSKEY e a zona re-assinada com a nova chave.

Método double-signing

Diferente do método de pre-publish, onde a nova chave era adicionada à zona porém ser ter uma utilidade clara no início, no método de double-signing utilizamos tanto a chave atual quanto a nova para assinar os registros da zona. Ou seja, usando double-signing teremos duas assinaturas para cada conjunto de RRs. Se a chave que estiver sendo substituída for a ZSK, toda a zona será assinada duas vezes. Já se for a KSK somente os registros DNSKEY serão assinados duas vezes.

Uma vez que os registros de recurso são assinados com todas as chaves, não corremos o risco de um servidor recursivo, que armazena uma das chaves em cache, falhe ao autenticar os dados de uma consulta (o mesmo vale para configuração de âncoras ou do registro DS na zona parent). Quando todos os usuários da chave tiverem atualizado suas configurações (o registro DS foi atualizado na zona parent ou as âncoras de segurança foram atualizadas), a chave antiga pode ser removida e a zona re-assinada somente com a nova chave.

Conclusão

Escolher o método que será utilizado na substituição de chaves é uma decisão operacional, porém para diminuir o volume de registros envolvidos, especialmente em zonas grandes, o método pre-publish é mais recomendado para substituição da Chave de Assinatura da Zona (ZSK) enquanto que o método double-signing para a substituição da Chave de Assinatura de Chaves (KSK). A justificativa para essa escolha baseia-se no fato de que, como a ZSK assina todos os registros da zona, seria muito custo duplicar a assinatura desses registros. Dessa forma, como a KSK assina somente um conjunto de RRs, o DNSKEY, não há maiores problemas em duplicar essa assinatura.

No geral o procedimento de troca de chaves envolve um certo planejamento e pode envolver outros administradores de zona. Os passos envolvidos na troca de chaves no geral não são complexos, porém o processo como um todo pode assumir certa complexidade. Principalmente se observarmos que os dados da zona podem se tornar indisponíveis. Já existem algumas ferramentas para automatizar o procedimento, trataremos delas em um outro tutorial.

Disponibilizamos um procedimento para substituição manual de chaves DNSSEC. Nesse procedimentos utiliza-se a técnica de pre-publish para substituição da ZSK e double-signing para substituição da KSK. A periodicidade dessa substituição é definida pela Política de publicação e administração de chaves DNSSEC do POP-BA.

Documentos relacionados

Referências

  • R. Aitchison, Pro DNS and BIND, Apress, 2005.