Skip to main content
Resources

Revisão da KSK da zona raiz

Esta página também está disponível em:

Root Zone KSK Rollover

Visão geral
Recursos
Participe
Histórico
Cronograma preliminar
Planos operacionais

Visão geral

A ICANN está planejando realizar uma revisão da chave de assinatura de chaves (KSK) das Extensões de Segurança do Sistema de Nomes de Domínio (DNSSEC), conforme exigido pela Declaração sobre as práticas de DNSSEC do operador da KSK [TXT, 99 KB].

A revisão da KSK significa gerar um novo par de chaves criptográficas públicas e privadas e distribuir o novo componente público para as partes que operam resolvedores de validação, incluindo: Provedores de Serviços de Internet; administradores de redes corporativas e outros operadores de resolvedores do DNS (Sistema de Nomes de Domínio); desenvolvedores de software de resolvedores do DNS; integradores de sistemas; e distribuidores de hardware e software que instalam ou enviam a "âncora de confiança" da raiz. A KSK é usada para assinar criptograficamente a Zone Signing Key (ZSK), usada pela mantenedora da zona raiz para assinar a zona raiz do DNS da Internet.

Manter a KSK atualizada é essencial para garantir que os nomes de domínio assinados pelas DNSSEC continuem sendo validados depois da revisão. Sem a KSK atualizada, os validadores habilitados por DNSSEC não poderão verificar se as respostas de DNS não foram alteradas e, portanto, retornarão uma resposta de erro a todas as consultas assinadas por DNSSEC.

Os planos de revisão da KSK foram desenvolvidos pelos parceiros de gerenciamento da zona raiz: a ICANN como operadora das funções da IANA, a Verisign como mantenedora da zona raiz, e a Administração de telecomunicações e informações (NTIA) do Departamento de comércio dos Estados Unidos como administradora da zona raiz. Os planos incorporarão as recomendações da equipe de projeto [PDF, 1.01 MB], da revisão da KSK da zona raiz [PDF, 1.01 MB], e as ajustarão de acordo com os requisitos e as limitações operacionais. Agora que foram desenvolvidos planos colaborativos, a ICANN realizará as futuras revisões da KSK de acordo com eles.

Recursos

É possível encontrar informações adicionais sobre a transição nos documentos:

Participe

Faça perguntas
Para fazer perguntas, envie um e-mail para globalsupport@icann.org com o assunto "KSK Rollover".

Participe de um evento
Confira o calendário de eventos com as próximas apresentações da revisão da KSK.

Interaja nas redes sociais
Use a hashtag #KeyRoll para entrar na conversa: https://twitter.com/icann

Entre na lista de discussão sobre a revisão da KSK
Inscreva-se na lista de e-mails para a discussão pública de assuntos relacionados: https://mm.icann.org/listinfo/ksk-rollover

Divulgue
Compartilhe esta página com outras pessoas para ajudá-las a buscar mais informações sobre a revisão da KSK e seus efeitos.

Histórico

Em 2009, os parceiros de gerenciamento da zona raiz trabalharam em conjunto para implementar as DNSSEC na zona raiz, o que culminou na primeira publicação de uma zona raiz assinada em validada em julho de 2010.

Os requisitos [PDF, 116 KB] para gerar e manter a KSK da zona raiz e as respectivas responsabilidades de cada parceiro de gerenciamento foram especificados pela NTIA. Os procedimentos realizados pela mantenedora da zona raiz (Verisign) e a operadora das funções da IANA (ICANN) para atender a esses requisitos foram publicados em declarações independentes sobre as práticas de DNSSEC (DPS): DPS do serviço de assinatura de DNSSEC da Verisign [PDF, 138 KB] e DPS do operador de KSK da zona raiz [TXT, 99 KB].

O Contrato de funções da IANA entre a NTIA e a ICANN foi modificado em julho de 2010 para incluir responsabilidades associadas ao gerenciamento de KSK da zona raiz, e esses requisitos foram transferidos a versões subsequentes desse contrato.

O acordo de cooperação entre a NTIA e a Verisign também foi emendado em julho de 2010, refletindo as responsabilidades da Verisign como operadora da Zone Signing Key (ZSK) da zona raiz.

O contrato de funções da IANA exige que a ICANN realize a revisão da KSK da zona raiz, mas não fornece detalhes sobre os requisitos, nem um cronograma ou plano de implementação detalhado. O DPS do operador de KSK da zona raiz contém esta declaração, que define a necessidade de uma revisão, na Seção 6.5:

"Cada KSK da zona raiz deverá ser revisada conforme necessário durante a cerimônia de chaves ou depois de cinco anos de operação".

Cronograma preliminar

Datas sujeitas a alterações com base em considerações operacionais.

  • 11 de outubro de 2016: início do processo de revisão e geração da nova KSK.
  • 11 de julho de 2017: publicação da nova KSK no DNS.
  • 19 de setembro de 2017: Aumento de tamanho para resposta de DNSKEY de parte de servidores de nomes de raiz.
  • 11 de outubro de 2017: início do uso da nova KSK para assinar o conjunto de chaves da zona raiz (o evento de revisão em si).
  • 11 de janeiro de 2018: revogação da KSK antiga.
  • 22 de março de 2018: O último dia em que o KSK antigo aparecerá na zona raiz.
  • Agosto de 2018: A chave antiga será eliminada dos equipamentos em ambas as instalações de administração da chave da ICANN.

Planos operacionais

  1. Plano operacional de implementação da revisão da KSK 2017 [PDF, 741 KB] - Explica detalhadamente as etapas operacionais para a execução do projeto de revisão da KSK 2017, inclusive o cronograma das oito fases do processo.
  2. Plano de reversão da revisão da KSK 2017 [PDF, 506 KB] - explica os desvios esperados do plano operacional de implementação com base em anomalias ocorridas durante a execução do plano operacional.
  3. Plano de teste externo da revisão da KSK 2017 [PDF, 516 KB] - Cobre a preparação dos ambientes de teste operacional, acessados pelo público geral da Internet, a fim de avaliar se os sistemas externos estão preparados para participar da revisão da KSK.
  4. Plano de monitoramento da revisão da KSK 2017 [PDF, 437 KB] - Descreve o plano para monitorar os efeitos da mudança da âncora de confiança da zona raiz sobre o tráfego para os servidores raiz.
  5. Plano de teste de sistemas para a revisão da KSK 2017 [PDF, 519 KB] - Descreve as ações necessárias para testar as mudanças na infraestrutura da ICANN envolvidas na revisão da KSK.
Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as""icann.org"" is not an IDN."