Troca da chave raiz do DNSSEC em 11 de outubro: o que eu checaria hoje no meu provedor

De onde eu falo: eu trabalho com DNS e estava num curso quando isso apareceu

Meu nome é Josimar, eu tenho empresa de tecnologia e eu trabalho com DNS. Entre as várias tecnologias com que eu trabalho está o DNS, e a gente tem o nosso próprio sistema de DNS. Não é palpite de quem leu manchete: é o tipo de coisa que, se der errado, cai no meu colo.

E por conta disso eu estava fazendo uma certificação recentemente, e me trouxeram essa informação. Eu já sabia que a troca de chave existia, mas não lembrava que ia ter uma agora. Conversando lá no curso, a conclusão da turma foi a mesma que a minha: como é só a segunda vez na história, muita gente fez isso na mão uma vez e não ativou o automático. É esse o ponto inteiro do que eu quero te contar.

Aviso logo: gravei isso meio como curiosidade com humor, com a piada da Sociedade do Anel e tudo. Mas o fundo é sério, e se você trabalha em provedor ou em empresa com DNS próprio, o final deste texto é uma lista de conferência pra você fazer antes de domingo.

Como o DNS funciona, bem singelo

Pra você acessar agora o youtube.com, tem o DNS, o resolvedor de nome. Ele existe pra você não precisar digitar um IPv4 — e um IPv6, que aí não tem como você digitar. Quer dizer, até tem, mas você teria que entender como simplificar o endereço, e eu não vou entrar nisso aqui. (De IP eu já falei bastante quando contei da fila de quase um ano pelo meu bloco IPv4.)

Pra isso funcionar, o mundo inteiro tem que estar sincronizado, e tem uma hierarquia. Você registra um domínio, um .com.br. O NIC.br, que está ligado ao LACNIC, que está ligado à ICANN — o órgão gestor dessa treta toda no mundo, bloco de IP, domínio e tal. Então fica todo mundo informado de que aquele domínio agora é seu. (Se você ainda está nessa etapa, eu tenho um texto sobre escolher o nome do domínio antes de criar o site.)

Aí, pra ter um site, você precisa de um DNS respondendo por esse domínio. Muita gente usa a Cloudflare: cria uma conta gratuita e diz "o domínio josimarjmv.com resolve pro IP tal". Não vou entrar no proxy ativado ou desativado pra não esticar — disso eu tratei quando falei dos limites da Cloudflare que ninguém te conta. Ou você pode ter o seu próprio DNS, igual a gente tem. E é aí que mora o perigo.

A falha: dava pra te mandar pro banco errado

A internet funcionava assim, que beleza. Só que descobriram uma forma de falsificar o DNS. E presta atenção no tamanho do perigo: é você digitar o endereço certo do seu banco — o certo mesmo, não estou falando de o cara registrar um domínio parecido — e, no meio do caminho, um atacante te jogar pra uma página que ele criou. Página igualzinha, bonitinha. Você, inocente, faz login achando que está no site do banco, e blum.

Não é à toa que banco e emissora grande foram na ICANN pedir a terminação com o próprio nome — um processo meio caro, com uma série de regras pra seguir. Eu poderia ter a minha também; só falta dinheiro pra isso.

Apuração minha, porque na gravação me faltou o nome e eu chutei o ano. Eu disse "um maluco que eu esqueci o nome", "em 2005, se eu não me engano". Fui conferir: a falha que deixou o envenenamento de cache de DNS prático de verdade foi divulgada em 8 de julho de 2008, e a nota de vulnerabilidade VU#800113 do CERT credita Dan Kaminsky. O 2005 que estava na minha cabeça tem dono também: é o ano das especificações atuais do DNSSEC, a começar pela RFC 4033, de março de 2005.

Esse tipo de ataque no meio do caminho é mais próximo de você do que parece. Uma TV Box dentro da sua casa, dependendo do tipo de acesso que ela tiver, consegue ser um atacante ali no meio e desviar o seu tráfego ou parte dele. É muito sério isso.

O que o DNSSEC faz — e o que ele não faz

Justamente por conta disso criaram o DNSSEC, de security: um DNS seguro. E aqui eu repito duas vezes na gravação, então repito aqui também: DNSSEC não é criptografia de dados. Ele é só autenticação de que aquela resposta de DNS é daquele domínio. São camadas de segurança diferentes.

Basicamente são umas chaves que fazem umas continhas de autenticação, baseadas numa chave mestra — estou sendo bem superficial de propósito. Isso começa lá na ponta: quem hospeda o seu DNS tem as chaves dos domínios que estão com ele, cria o registro, e o resolvedor valida a cadeia de chaves até chegar nos root servers. Se a cadeia não bater, não abre. É esse "não abre" que protege você da página falsa — e é esse mesmo "não abre" que derruba quem estiver com a chave errada no dia 11.

Na gravação eu comento que houve uma tentativa mais antiga de DNS seguro que não pegou. Apuração minha: a própria RFC 4033 registra que ela e as duas RFCs irmãs substituem a RFC 2535, a especificação anterior. É a versão de 2005 que está em uso hoje.

Root servers: a função mais redundante da internet

Os root servers são os servidores de DNS do topo da hierarquia, espalhados no mundo inteiro. Na minha cabeça é a função mais redundante que existe na internet. É de lá pra baixo que os provedores vão se atualizando — sabe a propagação de DNS, que antigamente demorava 72 horas? É esse caminho, do topo até o DNS do seu provedor.

Apuração minha, com o número na mão. Na gravação eu disse "só no Brasil acho que tem 14 instâncias" e que não sabia o total do mundo. Fui olhar em 08/10/2026 no root-servers.org, que é o site dos próprios operadores: são 13 nomes de servidor raiz, de A a M, operados por 12 organizações independentes, somando 2.047 instâncias em operação. E no Brasil é bem mais que 14: contei 76 pontos listados com "BR" nessa página, de São Paulo e Rio a Porto Alegre, Fortaleza, Salvador e Curitiba. Eu chutei baixo. A tese se sustenta com folga: é redundância que não acaba mais.

Um detalhe pra quem vai mexer com isso: a raiz não guarda o IP do seu site. Ela guarda quem responde por cada terminação (.br, .com e as outras), e é a partir dela que a cadeia de confiança do DNSSEC desce. Por isso a chave que fica lá em cima é a mãe de todas.

A Sociedade do Anel: quem são os guardiões e como é a cerimônia

Aqui vem a piada. Tem a galera lá, os guardiões da internet — saiu até matéria anos atrás falando em "sete guardiões". São pessoas escolhidas pela ICANN, gente de instituição espalhada no mundo inteiro. Parece até sociedade secreta. Tem um organograma muito bem feito, com substituto pra tudo. A cerimônia é transmitida ao vivo, as pessoas entram fisicamente numa salinha sem internet, sem nada, pra mexer nessas chaves.

Apuração minha sobre quem são. A IANA chama essas pessoas de Trusted Community Representatives e publica a lista oficial. Quando eu consultei, em 08/10/2026, eram 14 oficiais criptográficos — sete em cada uma das duas instalações, a leste e a oeste, o que explica o "sete" da matéria — mais sete guardiões de partes da chave de recuperação, além dos suplentes. E tem brasileiro: Jorge Etges aparece como oficial criptográfico desde 2022, e Frederico Neves ocupou uma dessas cadeiras de 2010 a 2024.

Nota de cronologia (importante). Do jeito que eu contei na gravação, parece que no dia 11 a turma entra na salinha e troca a chave. Indo na agenda de cerimônias da IANA, a ordem é outra: as cerimônias acontecem em geral quatro vezes por ano, e em cada uma a chave mestra assina as chaves operacionais do trimestre seguinte. A que assinou o quarto trimestre de 2026 — o período onde cai o dia 11 — foi a cerimônia 62, em 12/08/2026; a próxima da lista é a 63, em 12/11/2026. Ou seja: a parte da salinha já aconteceu. O que acontece no dia 11 é a zona raiz passar a usar só a chave nova. Pro seu servidor dá na mesma — a data que importa continua sendo 11/10.

O que acontece em 11/10/2026, com as datas na mão

Esta parte inteira é apuração minha na página da ICANN sobre a troca da KSK e no texto que ela publicou em 27/07/2026 pra preparar os operadores. Eu não tinha essas datas de cabeça quando gravei.

Repara na conta: a chave nova está publicada desde janeiro de 2025. Quem está com o automático funcionando já confia nela há mais de um ano e meio, e não vai sentir nada no domingo. A ICANN diz que mais de 95% dos resolvedores que reportam já reconheceram e adotaram a KSK-2024, numa curva quase igual à de 2018, e que pra maioria dos usuários a troca deve ser invisível.

Então por que eu gravei um vídeo sobre isso? Por causa dos outros 5%, e dos que nem reportam. A mesma ICANN escreve, com todas as letras, que o operador que chegar no dia sem a chave nova vai ter falha total de resolução de DNS na rede dele, cortando o acesso dos usuários. E manda: não presuma que a atualização automática funcionou.

Por que provedor pode cair: fizeram na mão e ninguém mais mexeu

Vamos lá. Todos os provedores que a gente conhece: será que todos estão com essa atualização automática? Primeiro, nem todos usam DNSSEC. Segundo, quem usa tem que atualizar a sua cadeiazinha de chaves — ou atualiza na mão, ou tem um processo automático. É óbvio que a gente coloca processo automático. Só que, por mais que seja óbvio, é só a segunda vez na história.

E aí entra o que eu mais vejo em empresa. O provedor que tem DNS próprio fez isso na mão lá atrás. A pessoa que fez nem está mais lá. Quem cuida hoje talvez nem saiba que isso existe. É aquele negócio que a gente conhece: a pessoa chega na empresa, está funcionando, principalmente o colaborador mais jovem — "sempre foi assim" — e aí não mexe. Ao contrário de chegar questionando: "como é isso aqui? isso aqui está certo?".

Por conta desse medo de mexer naquilo que está funcionando, eu acredito — a gente acredita, lá da turma do curso — que tem provedor que pode cair no dia 11. É o mesmo medo de que eu falo quando o assunto é subir em produção: o que ninguém entende vira área proibida, até o dia em que quebra sozinho.

Lógico que vai ser rápido de descobrir. Começa a não responder, cai um caminhão de chamado no provedor — "não estou conseguindo acessar" — e rapidinho alguém acha o que é. Mas é domingo, e o tempo entre o primeiro chamado e alguém lembrar que existia uma chave pra trocar é o tamanho do seu prejuízo.

"Mais de 50% da internet usa DNSSEC"? O número que eu fui conferir

Na gravação eu digo que mais de 50% da internet está usando DNSSEC, e que se todo mundo estivesse no manual e não fizesse nada cairia um percentual gigante da internet no mundo. O raciocínio vale; o número eu fui medir.

Apuração minha: quem mede isso de forma contínua é o laboratório da APNIC. Na janela de 30 dias fechada em 06/10/2026, a média mundial era de 39,1% dos usuários atrás de resolvedores que validam DNSSEC, e mais 9,1% com validação parcial. Somando dá perto da metade, não mais que metade. Não muda o recado: é gente demais dependendo de uma chave pra alguém deixar isso no "sempre foi assim".

E como muita gente respeita boa prática, a atualização automática já está lá: quando a chave troca em cima, desce cadeia abaixo sozinha. É por isso que a internet do mundo não vai cair. Quem cai é quem ficou de fora dessa fila.

O que eu checaria hoje, se eu fosse do seu provedor

Se você é de provedor, se você trabalha numa empresa que tem DNS próprio, levanta a bandeirinha. A lista abaixo é a orientação da ICANN, na ordem em que eu faria:

1. Descubra se você valida DNSSEC. Se o seu resolvedor recursivo não valida, a troca não te derruba (e aí a conversa é outra: por que não valida?). Se valida, segue a lista.
2. Procure a chave nova no arquivo de âncora de confiança. O que você quer achar é o Key Tag 38696. Segundo a ICANN, o arquivo é bind.keys no ISC BIND, root.key no Unbound e no PowerDNS Recursor, e root.keys no Knot Resolver.
3. Se não achou, veja se a atualização automática está ligada. É o mecanismo da RFC 5011. Lembra do prazo de 30 dias de observação: faltando três dias, esperar o automático aprender sozinho não é mais plano — siga a orientação do fabricante do seu resolvedor pra atualizar a âncora.
4. Confira a permissão de escrita. O processo do resolvedor precisa conseguir gravar na pasta onde guarda a âncora. É o tipo de detalhe que faz o automático "estar ligado" e nunca ter funcionado.
5. Compare com a fonte. As âncoras de confiança oficiais da raiz ficam publicadas na página de arquivos de DNSSEC da IANA. Chave que não bate com o que está lá não é chave.
6. Deixe alguém de sobreaviso no domingo. Se o telefone começar a tocar com "a internet caiu" e o link estiver de pé, você já sabe onde olhar primeiro.

Os itens 2, 3 e 4 são literalmente o que a ICANN manda conferir. O 1, o 5 e o 6 são meus: é o que eu faria na minha operação. E se quem configurou o seu DNS não está mais na empresa, esse é exatamente o seu caso — não espere o chamado pra descobrir.

O que isso diz sobre quem cuida de infraestrutura

É engraçado, e é sério, saber que a internet depende desse tipo de coisa — e que cada vez vai depender mais, por conta das falhas e dos atacantes. Um evento que só aconteceu duas vezes, com oito anos de intervalo, é o teste perfeito pra saber se a sua operação tem processo ou tem memória de uma pessoa que já foi embora.

É por isso que eu bato tanto na tecla de que infraestrutura é o novo superpoder: fazer software está ficando fácil, e quem entende o que está embaixo — DNS, rede, chave, validação — é quem sobra de pé quando o "sempre foi assim" quebra. Não precisa ser guru. Precisa chegar perguntando "como é isso aqui? isso aqui está certo?".

Se você quer aprender esse chão de verdade, é o assunto da minha imersão de infraestrutura; as informações estão na página dela. E se você só veio pela curiosidade: no domingo, se a sua internet funcionar normal, agradece a quem deixou o automático ligado. Um abraço e até a próxima — tem mais dessa linha aqui no blog.

Perguntas frequentes