--- id: "root-zone" kind: "glossary-term" title: "zona raiz" language: "pt-BR" category: "DNS e fundamentos técnicos" updated: "2026-10-10T23:13:20Z" canonical: "https://tldlog.com/pt/glossario/zona-raiz/" translations: en: "https://tldlog.com/glossary/root-zone/" es: "https://tldlog.com/es/glosario/zona-raiz/" de: "https://tldlog.com/de/glossar/root-zone/" fr: "https://tldlog.com/fr/glossaire/zone-racine/" it: "https://tldlog.com/it/glossario/zona-radice/" ru: "https://tldlog.com/ru/glossariy/kornevaya-zona/" zh-Hans: "https://tldlog.com/zh/cihui/genqu/" --- # zona raiz O nível mais alto do DNS. Lista todos os TLDs, como .com ou .es, e os servidores de nomes de cada um. Adicionar um novo TLD à internet significa adicioná-lo à zona raiz, um processo coordenado por meio da IANA. A zona raiz é o topo do sistema de nomes de domínio (DNS): uma lista pequena e pública de todos os domínios de topo (TLDs), como .com ou .es, e dos servidores que respondem por cada um deles. Quando um resolvedor não sabe onde encontrar um TLD, ele pergunta a um servidor raiz, que responde a partir da zona raiz. Um TLD só funciona na internet depois de constar dela. ## O que é a zona raiz e o que ela contém Segundo a IANA, a zona raiz é formada principalmente pelas delegações dos domínios de topo. Para cada TLD, ela guarda os servidores de nomes, como registros NS, e os registros DS que ligam o TLD à cadeia de confiança do DNSSEC. Também traz os endereços dos próprios servidores raiz. Ela não contém domínios individuais como example.com: apenas aponta para os servidores de cada TLD. Qualquer pessoa pode baixar da IANA o arquivo completo da zona raiz, com os mesmos dados que os servidores raiz servem. A IANA também mantém a Root Zone Database (base de dados da zona raiz), que registra o gerente, os detalhes técnicos e os contatos de cada TLD. A zona raiz é assinada com DNSSEC desde julho de 2010. ## Servidores raiz: quantos são e quem os opera A zona raiz é servida por 13 identidades nomeadas, de a.root-servers.net a m.root-servers.net. Esse número conta nomes e endereços, não máquinas: a IANA descreve uma rede de centenas de servidores em muitos países. Em 9 de outubro de 2026, o root-servers.org contava 2.047 instâncias em operação, mantidas por 12 organizações independentes; a Verisign opera duas identidades, a e j. Segundo uma declaração do RSSAC de 2019, os operadores devem permanecer independentes uns dos outros e de qualquer governo ou organização superior, e atuam sob jurisdições legais diferentes. ## Como um TLD é incluído na raiz ou removido dela Incluir um TLD se chama delegação, uma etapa separada da candidatura. Para um novo gTLD, ela vem depois que a ICANN assina um Contrato de Registro e realiza os testes de pré-delegação. O operador de registro então envia seu gerente, contatos, servidores de nomes e registros DS pelo sistema de gestão da zona raiz da IANA (Root Zone Management), e os registros NS dele são incluídos na zona raiz. Toda alteração na zona raiz, inclusive novos servidores de nomes para um TLD existente, passa pelas análises e pelos testes técnicos da IANA e deve ser confirmada pelos contatos do TLD antes de ser implementada. Uma mudança substancial de controle é tratada como redelegação, com critérios próprios. Um ccTLD existe porque seu país ou território tem um código na norma ISO 3166-1. Quando o código é removido, a IANA emite um aviso de remoção (Notice of Removal). Em outubro de 2026, o ccTLD é retirado após cinco anos por padrão, ou no máximo 10 se uma prorrogação for pedida nos 12 meses seguintes ao aviso. A Diretoria da ICANN adotou essa política em 22 de setembro de 2022. Um gTLD cujo Contrato de Registro é rescindido, e que a ICANN não transfere para um operador de registro sucessor, tem sua delegação revogada; a string pode ser oferecida de novo em uma futura rodada de candidaturas. ## Quem controla as alterações: a IANA, a mantenedora e os operadores - **A IANA**, cujas funções são executadas pela PTI, uma afiliada da ICANN, verifica cada pedido de alteração e mantém a Root Zone Database. As alterações partem do gerente do TLD, que as envia on-line e precisa confirmá-las. - **A Verisign**, como mantenedora da zona raiz (Root Zone Maintainer) por um acordo com a ICANN, compila a zona conforme as instruções da IANA, assina-a com a chave de assinatura da zona e a envia aos operadores. Em outubro de 2026, o acordo (assinado em 28 de setembro de 2016 e alterado em 20 de outubro de 2024) vale por prazos de oito anos renovados automaticamente. - **Os operadores de servidores raiz** servem a zona exatamente como foi distribuída. O RSSAC001 (dezembro de 2015) observa que um operador não conseguiria alterar os dados assinados sem invalidar as assinaturas. ## Mitos sobre “desligar a internet” na raiz - **Não existe um interruptor único.** Doze operadores independentes, em jurisdições diferentes, mantêm mais de 2.000 instâncias. - **Os operadores não podem alterar entradas às escondidas.** As assinaturas DNSSEC revelariam a alteração. - **Uma interrupção curta quase não se nota.** Segundo a RFC 8806, os resolvedores costumam manter os dados dos TLDs em cache por algo em torno de um ou dois dias. Isso não torna a raiz imune. Em 23 de dezembro de 2025, um ataque DDoS atingiu 10 das 13 identidades, chegou a mais de um terabit por segundo no pico e durou pouco menos de dez minutos. O relatório dos operadores de julho de 2026 não encontrou erros conhecidos visíveis para os usuários finais, apenas pequenos atrasos em algumas consultas, e atribui esse resultado à independência e à diversidade dos operadores. ## Cópias locais da raiz e por que os resolvedores as mantêm Um resolvedor normalmente parte das root hints, uma lista curta de nomes e endereços de servidores raiz, em geral embutida no seu software; a IANA publica a versão oficial. Ao iniciar, o resolvedor pede a um servidor raiz a lista atual, uma etapa chamada priming (RFC 9609, fevereiro de 2025), porque os endereços dos servidores raiz mudam de vez em quando. Uma raiz hiperlocal vai além: o resolvedor mantém uma cópia completa da zona raiz na mesma máquina e responde apenas a si mesmo (RFC 8806, junho de 2020). A cópia deve ser validada com DNSSEC e idêntica à zona real; se não puder ser atualizada a tempo, o resolvedor deve voltar imediatamente aos servidores raiz. Os objetivos declarados são a confiabilidade durante ataques e a privacidade. A RFC 8806 prevê pouco ganho de velocidade para os TLDs existentes, que em geral já estão em cache, e alerta que uma configuração com falhas pode entregar dados errados aos usuários. Uma raiz hiperlocal copia a zona oficial; uma raiz alternativa a modifica. Em 9 de outubro de 2026, a troca da KSK da raiz está prevista para 11 de outubro de 2026, quando a KSK-2024 substitui a KSK-2017. Os resolvedores que validam, inclusive as raízes hiperlocais, precisam da âncora de confiança atualizada. ## Fontes - [Root Zone Management (IANA)](https://www.iana.org/domains/root) - [Root Zone Change Request Process (IANA)](https://www.iana.org/help/root-zone-process) - [December 2025 DDoS against multiple DNS root servers (root server operators)](https://root-servers.org/media/news/2025-12-23_DDoS.pdf) - [RFC 8806: Running a Root Server Local to a Resolver](https://www.rfc-editor.org/rfc/rfc8806.txt) ## termos relacionados - [servidor raiz](https://tldlog.com/pt/glossario/servidor-raiz/) - [delegação (TLD)](https://tldlog.com/pt/glossario/delegacao-tld/) - [IANA](https://tldlog.com/pt/glossario/iana/) - [PTI](https://tldlog.com/pt/glossario/pti/)