A zona raiz do Sistema de Nomes de Domínio (DNS) terá em breve um novo tipo de registro para garantir ainda mais segurança, estabilidade e resiliência ao DNS global diante das novas abordagens emergentes para a operação do DNS —os registros ZONEMD—. Embora essa mudança seja imperceptível para a grande maioria dos operadores do DNS (por exemplo, registradores, provedores de serviços da Internet e organizações em geral), fornece uma camada adicional valiosa de segurança criptográfica para garantir a confiabilidade dos dados da zona raiz.
Nesta nota vamos discutir essas novas propostas, bem como os registros ZONEMD. Compartilharemos os planos de implantação, como estes podem afetar determinados usuários e o que os operadores do DNS precisam considerar de antemão para garantir que as interrupções sejam mínimas ou inexistentes.
A zona raiz do DNS é o ponto de partida para a maioria das buscas de nomes de domínio na Internet. A zona raiz contém delegações para quase 1500 domínios de nível superior, incluindo .com, .net, .org e muitos outros. Desde a sua criação em 1984, diferentes organizações conhecidas coletivamente como operadores de servidores raiz fornecem o serviço para o que agora chamamos de sistema de servidores raiz (RSS, por sua sigla em inglês). Nesse sistema, um número infindável de servidores responde diariamente a cerca de 80 bilhões de consultas à zona raiz.
Embora o RSS continue desempenhando esse papel com alto grau de confiabilidade, existem propostas recentes para usar a zona raiz de uma forma um pouco diferente. Mesmo que essas propostas gerem algumas eficiências para os operadores do DNS, elas também apresentam novos desafios.
NOVAS PROPOSTAS
Em 2020, a Internet Engineering Task Force (IETF) publicou o RFC 8806, Running a Root Server Local to a Resolver. Na mesma linha, em 2021, o Escritório do Diretor de Tecnologia da Corporação da Internet para a Designação de Nomes e Números (ICANN OCTO, por sua sigla em inglês) publicou o documento OCTO-027, Hyperlocal Root Zone Technical Analysis. As duas propostas compartilham a ideia de que os servidores de nomes recursivos podem receber e carregar toda a zona raiz localmente e responder diretamente às consultas para a zona raiz.
Mas em um cenário em que toda a zona raiz está disponível para milhões de servidores de nomes recursivos, surge uma nova pergunta: como os consumidores de dados de uma zona podem verificar que o conteúdo da zona não foi modificado antes de chegar aos seus sistemas?
Poderia se pensar que as extensões de segurança para o DNS (DNSSEC) ajudariam. No entanto, embora a zona raiz esteja sim assinada com DNSSEC, a maioria dos registros da zona são considerados não autoritativos (quer dizer, todos os registros NS e glue) e, portanto, não possuem assinaturas. O que acontece com algo como uma assinatura Pretty Good Privacy (PGP) no arquivo da zona raiz? Isso apresenta seu próprio desafio: no PGP, a assinatura se separa facilmente dos dados. Por exemplo, não há como incluir uma assinatura PGP sobre uma transferência de zona DNS e não há maneira fácil de saber qual versão da zona acompanha a assinatura.
APRESENTADO O ZONEMD
O RFC 8976 oferece uma solução para esse problema. Desenvolvido pela Verisign e intitulado Message Digest for DNS Zones (comumente conhecido como ZONEMD), este protocolo requer que um hash criptográfico dos dados da zona seja incorporado na própria zona. Após isso, os consumidores dos dados da zona podem assinar e verificar esse registro ZONEMD. Assim é como funciona:
Cada vez que uma zona é atualizada, o editor de zona calcula o registro ZONEMD tendo previamente ordenado e canonizado todos os registros na zona e fornecendo-os como entrada para uma função hash de mensagem. As ações de ordenar e canonizar, neste caso, são as mesmas que para o DNSSEC. De fato, o cálculo do ZONEMD pode ser executado ao mesmo tempo em que a zona é assinada. O cálculo do hash exclui necessariamente o próprio registro ZONEMD, portanto, a etapa final é atualizar o registro ZONEMD e suas assinaturas.
Um destinatário de uma transferência de zona que inclui um registro ZONEMD repete o mesmo cálculo e compara o valor do hash calculado com o hash publicado. Se a zona estiver assinada, o destinatário também poderá validar se o hash publicado é correto. Assim, os destinatários podem verificar a autenticidade dos dados da zona antes de usá-los.
Hoje existem —ou daqui a pouco existirão— vários produtos de software do DNS de código aberto que oferecem suporte à verificação de zona usando o ZONEMD. Estes incluem Unbound (versão 1.13.2), NSD (versão 4.3.4), Knot DNS (versão 3.1.0), PowerDNS Recursor (versão 4.7.0) e BIND (versão 9.19).
QUEM É AFETADO?
A Verisign, a ICANN e os operadores de servidores raiz estão tomando medidas para garantir que a adição do registro ZONEMD não afete de forma alguma a capacidade do sistema de servidores raiz de receber atualizações das zonas e de responder consultas. É por isso que a maioria dos usuários da Internet não é afetada por essa mudança.
Também é improvável que alguém que use o RFC 8806 ou uma técnica semelhante para carregar dados da zona raiz no seu resolvedor local seja afetado. Os produtos de software que implementam esses recursos deveriam ser capazes de processar totalmente uma zona que inclua o novo tipo de registro, principalmente pelos motivos descritos abaixo. Uma vez adicionado o registro, os usuários podem aproveitar a verificação de dados transferidos mediante ZONEMD para garantir que os dados da zona raiz sejam autênticos.
Os usuários com maior probabilidade de serem afetados são aqueles que recebem dados da zona raiz dos servidores de internic.net (ou de alguma outra fonte) e usam software personalizado para analisar o arquivo de zona. Dependendo de como esse software personalizado seja projetado, existe a possibilidade de tratar o novo registro ZONEMOD como inesperado e gerar uma condição de erro. Os principais objetivos desta postagem são aumentar a conscientização sobre essa mudança, dar tempo suficiente para resolver problemas de software e minimizar a probabilidade de interrupções para esses usuários.
PLANO DE IMPLANTAÇÃO
Em 2020, a Verisign solicitou ao Comitê de Revisão da Evolução da Zona Raiz (RZERC) que considerasse uma proposta para adicionar proteções de dados à zona raiz por meio do ZONEMD. EM 2021, O RZERC publicou suas recomendações na resolução RZERC003. Uma dessas recomendações foi que a Verisign e a ICANN desenvolvessem um plano de implantação e educassem a comunidade sobre os detalhes do plano. O restante deste artigo resume esse plano.
IMPLANTAÇÃO POR FASES
Um dos atributos de um registro ZONEMD é a escolha do algoritmo de hash usado para criar o hash. O RFC 8976 define dois algoritmos hash padrões—SHA-384 e SHA-512— e uma variedade de algoritmos de “uso privado”.
No início, o registro ZONEMD da zona raiz vai ter um algoritmo hash de uso privado. Isso nos permite incluir primeiro o registro na zona sem que ninguém se preocupe com a validade dos valores hash. Uma vez que o algoritmo hash é de uso privado, um consumidor dos dados da zona não saberá como calcular o valor hash. Quando o DNSSEC foi adicionado à zona raiz em 2010, foi usada uma técnica semelhante conhecida como “Zona raiz deliberadamente não validável”.
Após um período de mais de dois meses, o registro ZONEMD fará a transição para um algoritmo hash padrão.
ALGORITMO HASH
Por motivos de compatibilidade, o SHA-384 foi selecionado para a implantação inicial.
Os desenvolvedores do BIND implementaram o protocolo ZONEMD com base em um rascunho da Internet anterior, antes de este ser publicado como RFC. Infelizmente, a implantação inicial do BIND aceita apenas registros ZONEMD com um comprimento hash de 48 bytes (quer dizer, o comprimento de SHA-384). Como hoje são muito usadas as versões do BIND que têm esse comportamento, o uso do algoritmo hash SHA-512 provavelmente causaria problemas para muitas instalações do BIND, talvez até mesmo para alguns operadores de servidores raiz.
FORMATO DE APRESENTAÇÃO
A distribuição da zona entre o mantenedor da zona raiz e os operadores de servidores raiz é feita principalmente por meio do protocolo de transferência de zona DNS. Neste protocolo, os dados de zona são transmitidos em “formato de rede”.
A zona raiz também é armazenada e serve como um arquivo nos servidores web e FTP do internic.net. Aqui, os dados da zona estão em “formato de apresentação”. Nesses arquivos, o registro ZONEMD aparecerá usando seu formato de apresentação nativo. Por exemplo:
. 86400 IN ZONEMD 2021101902 1 1 ( 7d016e7badfd8b9edbfb515deebe7a866bf972104fa06fec
e85402cc4ce9b69bd0cbd652cec4956a0f206998bfb34483 )
Alguns usuários dos dados de zona recebidos dos servidores web e FTP poderiam estar usando software que não reconhece o formato de apresentação do ZONEMD. Esses usuários poderiam enfrentar alguns inconvenientes quando o registro ZONEMD aparecer pela primeira vez. De fato, consideramos a possibilidade de usar um formato de registro genérico; no entanto, em consulta com a ICANN, acreditamos que o formato nativo é uma solução melhor ao longo prazo.
CRONOGRAMA
Hoje, nosso objetivo é a implantação inicial do ZONEMD na zona raiz até 13 de setembro de 2023. Conforme observado acima, o registro ZONEMD será publicado primeiro com um número de algoritmo hash de uso privado. Nosso objetivo é começar a usar o algoritmo hash SHA-384 em 6 de dezembro de 2023. A partir de então o registro ZONEMD da zona raiz será verificável.
CONCLUSÃO
A implantação do ZONEMD na zona raiz ajuda a aumentar a segurança, estabilidade e resiliência do DNS. Em breve, os servidores de nomes recursivos que optarem por servir dados da zona raiz localmente terão melhores garantias em relação à validade da zona.
Se você estiver interessado em acompanhar o progresso da implantação do ZONEMD, procure nossos anúncios na lista de correio DNS Operations.
