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
Plano de comunicação

Novidades técnicas

1º de fevereiro 2018 – Anúncio do plano para continuar com a revisão da KSK

18 de dezembro de 2017 – Atualização sobre o projeto de revisão da KSK da zona raiz

17 de outubro de 2017 – Adiamento da revisão da KSK da zona raiz

27 de setembro de 2017 – ICANN anuncia adiamento na revisão da KSK

4 de setembro de 2017 – Verificação das âncoras de confiança atuais nos resolvedores que validam o DNS

4 de setembro de 2017 – Atualização dos resolvedores que validam o DNS com a âncora de confiança mais recente

11 de julho de 2017 – A KSK-2017 é publicada no DNS

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 de Zona Raiz [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 resolvedores do DNS que validam as DNSSEC continuem funcionando depois da revisão. Se não tiverem a KSK atual da zona raiz, os resolvedores do DNS que validam as DNSSEC não poderão resolver consultas do DNS.

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. A função da NTIA terminou em 1° de outubro de 2016. Os planos de revisão da KSK foram publicados em julho de 2016 e incorporam as recomendações da equipe de projeto da revisão da KSK da zona raiz [PDF, 1.01 MB].

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 sobre a revisão da KSK.

Interaja nas redes sociais
Use a hashtag #KeyRoll para participar das conversas: 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 saber mais 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 e 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].

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.

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.

contrato de funções da IANA exigia a realização de uma revisão da KSK da zona raiz, mas não fornecia 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

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

  • 27 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 da resposta DNSKEY de servidores de nome raiz.
  • 1 de fevereiro de 2018: início do período para comentários públicos sobre o plano de prosseguindo da revisão da KSK. O período se encerra em 2 de abril de 2018.
  • Mais datas serão anunciadas conforme o projeto de revisão da KSK seja atualizado

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. - Este documento está sendo atualizado para refletir o adiamento anunciado em 27 de setembro de 2017.
  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.- Este documento está sendo atualizado para refletir o adiamento anunciado em 27 de setembro de 2017.
  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, 480 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.

Plano de comunicação

A ICANN vai realizar uma grande campanha de divulgação para garantir que os usuários da KSK fiquem sabendo sobre a mudança.

Arquivo de notícias

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."