Info! Please note that this translation has been provided as best effort, for your convenience. The English page remains the official version.

Serviço DNSSEC AFRINIC

Imprimir amigável, PDF e e-mail

O AFRINIC gerencia e publica os dados da zona DNS reverso (RDNS) para o espaço IP que alocamos ou atribuímos aos membros.

As zonas incluem

IPv4

  • 41.in-addr.arpa.
  • 196.in-addr.arpa.
  • 197.in-addr.arpa.
  • 102.in-addr.arpa.
  • 105.in-addr.arpa.
  • 154.in-addr.arpa.

IPv6

  • 0.c.2.ip6.arpa.
  • 3.4.1.0.0.2.ip6.arpa.
  • 2.4.1.0.0.2.ip6.arpa.
Objetivo

A implantação do DNSSEC na AFRINIC visa

  • Assine essas zonas.
  • Publicar registro do DS nas zonas pai
  • Aceitar registros DS de nossos membros

Ele permite que a comunidade valide dados DNS oficiais das zonas RDNS do AFRINIC e os membros publiquem registros do DS para criar a cadeia de confiança para suas zonas RDNS.

A implantação de DNSSEC é um projeto coordenado por NRO, pois os blocos ERX precisam de ações coordenadas. Todas as comunicações relacionadas a esses projetos devem ser enviadas para dnssec-ops [at] afrinic [dot] net

Adotamos um plano para uma implantação cuidadosamente incremental do DNSSEC em AFRINIC. 

Plano de preparação

Depois que a fase de teste estiver concluída, o AFRINIC integrará o Signatário ao sistema de provisionamento em 3 fases. Nesta fase, o sistema de provisionamento continua funcionando como está. Quando novas zonas são geradas, cópias das zonas não assinadas distribuídas são transmitidas ao assinante para produzir uma zona assinada.

Fases de teste de implantação

  • Instale as ferramentas (Opendnssec, NSD, BIND, DSC, etc.)
  • Gerar chaves para as zonas - KSK RSA 2048 / ZSK RSA 1024
  • Entre na zona Unsigned no OpenDNSSEC e assine
  • Publique as zonas assinadas nos servidores DNS locais
  • Consultar e analisar tamanhos de resposta em UDP e TCP
  • Validação usando chaves como chaves confiáveis
  • Rolagem das Chaves de Teste: ZSK e KSK
  • Substituições programadas de chaves e substituição de chaves de emergência
  • Conclusões e lições aprendidas

Fase 1 - Zonas sem sinalização publicadas

A zona assinada é verificada e carregada em um servidor DNS público. Todos os testes são realizados em torno do servidor DNS público. O AFRINIC avaliará aqui a operação do assinante e o sistema de provisionamento atualizado. 

  • O novo sistema de provisionamento: geração consistente de zonas assinadas
  • Verificação de consistência para conteúdo de zonas: consultas não DNSSEC em ambas (não assinadas e assinadas)
  • Consultas DNSSEC para as zonas assinadas
  • Conclusões e lições aprendidas

Fase 2 - Publicar zonas assinadas

Com um estágio anterior bem-sucedido, a próxima etapa será começar a publicar zonas assinadas em vez de zonas não assinadas. Nesta fase, o sistema de provisionamento DNS reverso começará a publicar zonas assinadas com notificação adequada e um plano de reversão. Somente as zonas produzidas pelo assinante são distribuídas para os servidores NS.

teste

  • As zonas transferem consistência de mestre / escravo
  • Consultas não dnssec em todos os NS
  • Consultas DNSsec em todos os NS
  • Conclusões e lições aprendidas

Plano de reversão

A reversão da fase em que o AfriNIC está publicando zonas assinadas sem DS nas zonas pai é a seguinte:

  1. Uma janela de manutenção para a reversão está aberta.
  2. Um aviso da manutenção iminente, com uma descrição técnica da mudança, será enviado à comunidade.
  3. Durante a janela de manutenção, o AfriNIC começará a servir zonas não assinadas, sem todas as informações de DNSSEC. O SOA serial aumenta para acionar a distribuição da zona não assinada.
  4. Um relatório técnico detalhado das circunstâncias que levaram à reversão e a execução da reversão são enviados à comunidade.

Fase 3 - publicação do DS nas zonas pai

Com a publicação das zonas assinadas concluída, as zonas AFRINIC RDNS ainda não estão protegidas pelo DNSSEC. Os registros DS de KSKs devem ser publicados nas zonas pai. Os registros do DS serão gerados e enviados para a IANA por meio de seu sistema de gerenciamento RDNS. 

O provisionamento será configurado para processar registros DS para subdomínios. O signatário e a publicação das zonas não são modificados. Com um sistema DNSSEC completo testado e lançado com medidas em vigor para operar de acordo com o DPS, o projeto passará para as operações AFRINIC normais. O monitoramento e a medição do desempenho serão atividades constantes.

Testes

  • Consulta para o registro DS em todos os servidores ip6.arpa e in-addr.arpa
  • Validação DNSSEC de RRs assinados em zonas assinadas AFRINIC com chave raiz como chave confiável
  • Conclusões e lições aprendidas

Plano de reversão

A reversão da fase em que o AfriNIC está publicando zonas assinadas com o DS nas zonas pai é a seguinte:

  1. Uma janela de manutenção para a reversão está aberta.
  2. O aviso das circunstâncias e a ação corretiva pretendida, com detalhes técnicos, serão enviados à comunidade.
  3. O AfriNIC executará uma substituição KSK de emergência para remover os registros do DS das zonas pai.
  4. A comunicação pública com a comunidade continuará, com o objetivo de garantir que as notícias da situação e as ações que estão sendo tomadas sejam comunicadas ao maior público possível.
  5. Após o atraso de publicação apropriado, conforme especificado pelo DPS, o AfriNIC executará uma transição para zonas não assinadas, conforme descrito na fase em que o AfriNIC está publicando zonas assinadas sem DS nas zonas pai.

Publicação de registros de membros DS

Testes

  • Processamento do DS e assinatura de RRs do DS
  • Validação de cadeia de confiança da zona raiz para a criança (com registros do DS publicados)
  • Conclusões e lições aprendidas 

Declaração de Prática DNSSEC - DPS

Parâmetros de assinatura de zona - Comprimentos de chave e algoritmos

  • Chave de assinatura de chave: usamos um comprimento de chave de 2048 bits com o RSA como algoritmo de geração.
  • Chave de assinatura de zona: usamos um comprimento de chave de 1024 bits com RSA como o algoritmo de geração.
  • Negação de existência autenticada: A negação de existência autenticada será fornecida por meio do uso de registros NSEC, conforme especificado no RFC 4034.
  • Formato de assinatura: nossas assinaturas são criadas com o hash SHA2-256 usando RSA.
  • Substituição da chave de assinatura de zona: Vamos implementar o ZSK mensalmente com um esquema de pré-publicação, conforme descrito na RFC 4641, seção 4.2.1.1.
  • Mudança de chave de assinatura de chave: Faremos a rolagem do KSK anualmente com um esquema de assinatura dupla, conforme descrito na RFC 4641, seção 4.2.1.2.
  • Assinatura vitalícia e frequência de nova assinatura: Assinamos novamente nossas zonas assim que uma nova zona é gerada com assinatura vitalícia de 15 dias.

Tempo de vida dos registros de recursos - tipo de registro TTL

  • DNSKEY: igual ao TTL usado para o registro SOA
  • NSEC: Igual ao campo mínimo do registro SOA
  • RRSIG: Igual ao TTL mais baixo do conjunto de registros coberto
  • DS: igual ao TTL usado para o registro NS

Delegações DNSSEC

Procedimento para solicitar delegações DNSSEC (data: abril de 2012 - versão: 1.0)

Esta seção descreve como solicitar delegações DNSSEC. É um complemento ao procedimento existente para solicitar delegações reversas.

Observe que, até novo aviso do AfriNIC, o DS RECORDS não estará visível no DNS. Cuidado com as próximas notícias nossas.

1 - O objeto DOMAIN

Você pode solicitar a delegação reversa enviando objetos de domínio via auto-dbm (e-mail) ou via MyAFRINIC, que é o método recomendado [1]. DNSSEC não significará nenhuma mudança nos mecanismos de autorização existentes. Para habilitar a delegação DNSSEC, o objeto de domínio agora inclui um atributo "ds-rdata:".

domínio: [obrigatório] [único] [chave primária / de pesquisa]
descr: [obrigatório] [múltiplo] []
org: [opcional] [múltiplo] [chave inversa]
admin-c: [obrigatório] [múltiplo] [chave inversa]
tech-c: [obrigatório] [múltiplo] [chave inversa]
zona-c: [obrigatório] [múltiplo] [chave inversa]
nserver: [opcional] [múltiplo] [chave inversa]
ds-rdata: [opcional] [múltiplo] [chave inversa]
subdomínio: [opcional] [múltiplo] [chave inversa]
dom-net: [opcional] [múltiplo] []
observações: [opcional] [múltiplo] []
notificar: [opcional] [múltiplo] [chave inversa]
mnt-by: [opcional] [múltiplo] [chave inversa]
mnt-lower: [opcional] [múltiplo] [tecla inversa]
consulte: [opcional] [único] []
alterado: [obrigatório] [múltiplo] []
fonte: [obrigatório] [único] []

 2- O atributo "ds-rdata:"

No DNSSEC, o Registro de recursos do signatário da delegação (DS) é criado a partir de um registro de recursos DNSKEY comparando-o com a chave pública. O pai publica e assina o DS Resource Record. O atributo "ds-rdata:" contém o RDATA dos registros de recursos DS relacionados ao domínio (conforme mostrado no atributo "domínio:").

Ds-rdata: 55555 8 2 CABC3A8AF15E93741BF45096DB1D3451D93B2F541166EA44F2D4781753328CB8

 3- Cheques de Delegação

Quando você envia sua atualização pelo MyAFRINIC, o mecanismo de atualização realiza várias verificações, conforme mostrado na figura abaixo.

dnssec FlowchartDSValidation

  • Mantenha todas as verificações padrão que o MyAfrinic faz na delegação reversa
  • A verificação de sintaxe é feita para garantir que o DS inserido esteja no formato correto:
  • keytag: {0-65535}; Algorithm:{3|5|6|7|8|10|12|253|254}; Digest type:{1-3}; Digest:{alphanumeric}
  • O comprimento do resumo depende do tipo de resumo da seguinte forma: Tipo 1 (Sha1): 160 bits (40 caracteres) / Tipo 2 (Sha256) ou 3 (gost): 256 bits (64 caracteres)
  • Verifique se existe uma chave na zona filho com a tag key no registro do DS
  • Verifique se o algoritmo da chave corresponde ao algoritmo da chave nos atributos do DS
  • Verifique se o resumo corresponde à chave com a tag correspondente na zona filho
  • Verifique se existe um RRSIG que cubra o DNSKEY correspondente ao DS enviado e é válido.

[1] Atualmente, não há verificação e validação para o DS enviado por meio do auto-dbm


Plano de comunicação AFRINIC DNSSEC

A comunicação eficaz é fundamental para o sucesso desse esforço, a transição sendo realizada com um impacto potencial nos serviços AFRINIC RDNS. A comunicação com os membros da AFRINIC e com a comunidade em geral é importante. A estratégia de implantação em etapas permite que o impacto dessas etapas incrementais seja comunicado à equipe que as executa. Para que as decisões corretas sejam tomadas, é vital que existam canais apropriados para incentivar a comunicação.

Anúncios, lançamentos e outras informações pertinentes serão publicadas no site da AFRINIC. Atualizações periódicas do status técnico serão enviadas para várias listas de discussão, a fim de manter as comunidades técnicas e operacionais informadas sobre os desenvolvimentos.

O endereço de e-mail dnssec-ops [at] AFRINIC.net permitirá que qualquer parte interessada se comunique diretamente com a equipe do projeto. Uma lista de discussão dnssec-discuss [at] afrinic.net será usada para discutir a implantação e serviços DNSSEC da AFRINIC 

Slides da oficina

  1. DNSSEC AFRINIC
  2. DNSSEC-Tutorial-Crypto-Defs
  3. Introdução-DNSSEC
  4. Visão geral de criptografia curta

 

 

Última modificação em -
Data e hora nas Maurícias -