[ Início ]

Esta publicação não trata de uma vulnerabilidade nem de um ataque, embora o sintoma tenha levado muita gente a suspeitar disso: a partir de 11 de outubro de 2026, redes inteiras perderam a resolução de nomes de uma hora para outra.

A causa foi operacional, e está num mecanismo de segurança: a validação DNSSEC feita pelo dnsmasq, que funciona como forwarder com cache. Ele encaminha as consultas a servidores upstream e guarda as respostas, mas, quando o DNSSEC está ativo, é ele quem valida as assinaturas, com as próprias âncoras de confiança. Onde a nova chave da raiz não estava entre essas âncoras, a validação passou a falhar para todos os domínios.

Na prática, a rede parece estar sem internet: o link continua de pé e o ping para endereços IP responde, mas nenhum nome resolve. O problema não está no provedor nem no hardware do roteador. Ele começa na raiz do DNS, que trocou a chave usada para assinar a sua própria zona.

Este artigo explica o que mudou, por que o dnsmasq foi especialmente afetado, como diagnosticar o problema e como corrigi-lo no Ubiquiti EdgeOS e em outras plataformas. No fim, relato outras falhas que apareceram durante a mesma manutenção, num EdgeRouter X com duas WANs.

Resumo

Em 11/10/2026, a zona raiz do DNS passou a assinar seu conjunto de chaves (DNSKEY) apenas com a nova Key Signing Key, a KSK-2024 (key tag 38696), no lugar da KSK-2017 (key tag 20326). Todo resolvedor que valida DNSSEC precisa ter a nova chave como âncora de confiança. A maioria dos resolvedores aprende essa chave sozinha, pelo mecanismo da RFC 5011. O dnsmasq não implementa a RFC 5011: suas âncoras são estáticas. Onde a âncora 38696 não foi incluída manualmente ou por atualização de pacote, a validação da raiz falha, e o resolvedor passa a responder SERVFAIL a praticamente todas as consultas.

Ficha técnica

O que mudou na raiz do DNS

O DNSSEC funciona como uma cadeia de confiança. Cada zona assina seus registros, e a zona-pai publica um resumo (registro DS) da chave da zona-filha. A raiz não tem pai, então a confiança nela começa numa cópia local da sua chave pública, guardada pelo próprio resolvedor. Essa cópia é a âncora de confiança (trust anchor).

A chave que a raiz usa para assinar seu conjunto DNSKEY é a KSK. Trocá-la é um processo longo e cuidadoso:

• Julho de 2024: a IANA publica a âncora da nova chave, KSK-2024, para que fabricantes e mantenedores de pacotes comecem a distribuí-la.
• 11 de janeiro de 2025: a KSK-2024 é pré-publicada na zona raiz, ao lado da KSK-2017, mas ainda sem assinar nada. Resolvedores com RFC 5011 passam a observá-la e a incorporá-la.
• 11 de outubro de 2026: a KSK-2024 passa a assinar o conjunto DNSKEY da raiz, e a KSK-2017 deixa de assinar.
• 2027: a KSK-2017 deve ser revogada e removida da zona raiz.

A partir de 11/10, uma assinatura feita pela KSK-2024 não significa nada para um resolvedor que só conhece a 20326. Ele não consegue validar a raiz e, por consequência, não consegue validar nenhum domínio abaixo dela.

Por que o dnsmasq foi afetado

Resolvedores como Unbound, BIND e Knot Resolver costumam atualizar a âncora sozinhos, com o mecanismo descrito na RFC 5011. Eles detectaram a KSK-2024 publicada desde janeiro de 2025 e passaram a confiar nela antes da troca.

O dnsmasq é um forwarder com cache que também pode validar DNSSEC, mas não implementa a RFC 5011. As âncoras vêm de linhas trust-anchor= escritas na configuração, ou de um arquivo de âncoras distribuído com o pacote. O projeto dnsmasq incluiu a âncora 38696 no seu arquivo trust-anchors.conf em setembro de 2024. Isso, porém, só chega a quem atualizou o pacote, e não cobre sistemas que definem as âncoras na própria configuração, como o EdgeOS.

No caso que motivou este artigo, um EdgeRouter X com EdgeOS 3.0.1, a configuração tinha duas âncoras: a 20326, correta mas prestes a sair de uso, e a 19036, obsoleta desde 2018. A 38696 não estava lá.

Quem pode estar exposto

O dnsmasq está presente em muitos equipamentos, porque é leve e reúne DNS e DHCP num único programa. Mas usar o dnsmasq não basta para ser afetado. A falha exige duas condições ao mesmo tempo: o DNSSEC ativo no dnsmasq e uma lista de âncoras sem a key tag 38696.

Equipamentos e sistemas em que o DNSSEC pode ser ativado

Estes são os casos mais expostos, porque alguém pode ter ligado a validação por iniciativa própria:

• Ubiquiti EdgeRouter (EdgeOS) e gateways UniFi: no EdgeOS, as âncoras ficam na própria configuração e não são atualizadas por pacote.
• OpenWrt e derivados, como os roteadores GL.iNet e os equipamentos industriais Teltonika (RutOS): a validação exige o pacote dnsmasq-full.
• Roteadores ASUS, com firmware original ou Asuswrt-Merlin: ambos oferecem uma opção de DNSSEC na interface.
• DD-WRT e FreshTomato: trazem opção de DNSSEC em diversas versões.
• Pi-hole: o motor dele (FTL) é derivado do dnsmasq, e a validação DNSSEC é uma opção nas configurações.
• pfSense e OPNsense, quando usam o serviço de encaminhamento baseado no dnsmasq (“DNS Forwarder” no pfSense, “Dnsmasq DNS & DHCP” no OPNsense). O resolvedor padrão de ambos é o Unbound, que atualiza as âncoras automaticamente e não foi afetado.
• Servidores e estações Linux com o dnsmasq instalado como serviço próprio e a validação ativada.

Equipamentos que normalmente passaram ilesos

Muitos roteadores domésticos de marcas como TP-Link, Netgear e Linksys, além de equipamentos fornecidos por operadoras, embutem o dnsmasq no firmware original. Na maioria desses casos, o DNSSEC vem desligado, ou o dnsmasq nem é compilado com suporte a ele, então a troca da chave não teve efeito. O mesmo vale, em geral, para usos internos do dnsmasq em sistemas Linux, como o cache local do NetworkManager e as redes virtuais do libvirt, onde a validação raramente está ativa.

A disponibilidade da opção de DNSSEC varia conforme o modelo e a versão do firmware. Na dúvida, verifique a configuração do equipamento. O risco é maior em dispositivos com firmware desatualizado ou que já não recebem atualizações do fabricante, porque eles não receberão a nova âncora por conta própria.

Sintomas e diagnóstico

O quadro típico é este:

• Os dispositivos da rede não abrem sites nem aplicativos, mas o ping para um IP (por exemplo, 1.1.1.1) funciona.
• Consultas ao resolvedor local retornam status: SERVFAIL para qualquer domínio.
• Consultas feitas diretamente a um resolvedor público funcionam.

Para confirmar a partir de um cliente da rede, troque IP-DO-RESOLVEDOR pelo IP do seu roteador ou servidor dnsmasq:

dig @IP-DO-RESOLVEDOR www.google.com
dig @1.1.1.1 www.google.com

Se a primeira consulta falha e a segunda funciona, o problema está no resolvedor local. Em seguida, verifique se o DNSSEC está ativo e quais âncoras estão configuradas.

No EdgeOS:

show configuration commands | match "dns forwarding"

Em sistemas Linux ou OpenWrt com dnsmasq:

grep -rn -E "^\s*(dnssec|trust-anchor)" /etc/dnsmasq.conf /etc/dnsmasq.d /usr/share/dnsmasq* 2>/dev/null

Se houver dnssec ativo e nenhuma linha com 38696, o diagnóstico está fechado.

Como corrigir

1. Conferir o digest oficial

Antes de qualquer alteração, confira o digest da nova chave na fonte oficial, o arquivo root-anchors.xml da IANA, no bloco com <KeyTag>38696</KeyTag>. Como o DNS da rede afetada não funciona, faça a consulta de outra conexão, como o celular no 4G. O valor esperado é:

683D2D0ACB8C9B712A1948B27F741219298D0A450D612C483AF444A4C0FB2B16

Um único caractere errado na âncora impede toda a validação, e o problema continua.

2. Ubiquiti EdgeOS (EdgeRouter)

Os comandos set e delete só funcionam dentro do modo de configuração (configure). Fora dele, o EdgeOS responde “Invalid command”.

configure
set service dns forwarding options trust-anchor=.,38696,8,2,683D2D0ACB8C9B712A1948B27F741219298D0A450D612C483AF444A4C0FB2B16
delete service dns forwarding options trust-anchor=.,19036,8,2,49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5
commit
save
exit
clear dns forwarding cache

A segunda linha remove a âncora obsoleta de 2010, se ela existir na sua configuração. A âncora 20326 pode ficar até a revogação da KSK-2017, prevista para 2027. Para confirmar:

show configuration commands | match trust-anchor

3. Outros sistemas com dnsmasq

O procedimento geral é garantir que o dnsmasq carregue a linha da nova âncora e depois reiniciar o serviço. Em distribuições Linux, um caminho simples é criar um arquivo próprio, desde que o diretório /etc/dnsmasq.d esteja incluído na configuração (diretiva conf-dir):

echo 'trust-anchor=.,38696,8,2,683D2D0ACB8C9B712A1948B27F741219298D0A450D612C483AF444A4C0FB2B16' | sudo tee /etc/dnsmasq.d/ksk-2024.conf
sudo systemctl restart dnsmasq

Repetir uma âncora que já existe num arquivo do pacote não causa problema. Mesmo assim, o caminho preferível é atualizar o pacote do dnsmasq para uma versão cujo arquivo de âncoras já traga a 38696.

No OpenWrt, a validação DNSSEC exige o pacote dnsmasq-full, que traz um arquivo de âncoras próprio. Atualize o pacote ou adicione a linha à configuração e reinicie com /etc/init.d/dnsmasq restart. No Pi-hole, que usa um derivado do dnsmasq, atualize a instalação e confirme se a âncora 38696 está presente antes de reativar o DNSSEC. Em ambos, o local exato do arquivo de âncoras varia conforme a versão, então use o grep da seção anterior para encontrá-lo.

4. Validar a correção

Depois de aplicar a correção, rode dois testes a partir de um cliente da rede:

dig @IP-DO-RESOLVEDOR dnssec-failed.org
dig @IP-DO-RESOLVEDOR www.isc.org +dnssec

O primeiro domínio foi quebrado de propósito: o DS publicado na zona .org não corresponde à chave dele. Um validador saudável deve responder SERVFAIL. Em resolvedores com suporte à RFC 8914 (Extended DNS Errors), a resposta pode trazer um código de erro estendido explicando a falha, como “no SEP matching the DS found”.

O segundo domínio é assinado corretamente. A resposta deve ser status: NOERROR, com o flag ad (Authenticated Data) na linha flags:. Se os dois resultados aparecerem como descrito, a validação está funcionando nos dois sentidos: recusa o que é inválido e autentica o que é válido.

Há também um teste específico de âncora, baseado nos sentinels da RFC 8509 (nomes como root-key-sentinel-is-ta-38696). Ele só é conclusivo em resolvedores que implementam esse mecanismo, o que nem sempre é o caso de forwarders simples. Para o dnsmasq, os dois testes acima são mais confiáveis.

5. Paliativo de emergência

Se for preciso restabelecer o acesso antes de conferir o digest, desativar temporariamente a validação DNSSEC resolve. No EdgeOS:

configure
delete service dns forwarding options dnssec
delete service dns forwarding options dnssec-check-unsigned
commit
exit

Trate isso como medida provisória. Sem validação, a rede volta a funcionar, mas perde a proteção contra respostas DNS forjadas. Assim que a âncora estiver correta, reative o DNSSEC.

O que mais apareceu na mesma manutenção

Corrigida a âncora, a revisão do resolvedor no EdgeRouter X expôs outros problemas, comuns em instalações com mais de uma WAN.

Upstreams misturados com os DNS das operadoras

O comando show dns forwarding nameservers mostrou que o dnsmasq usava, ao mesmo tempo, os servidores públicos configurados manualmente e os servidores DNS entregues pelas duas operadoras, via PPPoE e via DHCP. Isso cria dois riscos. Resolvedores de operadoras nem sempre repassam corretamente os registros DNSSEC (RRSIG, DS), o que causa falhas intermitentes de validação. E esses servidores costumam recusar consultas vindas da rede de outra operadora, o que gera atrasos e falhas justamente durante o failover.

A solução foi impedir que as WANs alterassem a lista de DNS e fixar os upstreams nos servidores definidos no sistema. Os nomes das interfaces abaixo são os do caso analisado; ajuste-os ao seu ambiente.

configure
set interfaces ethernet eth1 pppoe 1 name-server none
set interfaces ethernet eth0 dhcp-options name-server no-update
set service dns forwarding system
commit
save
exit

Como redundância de provedor, e não só de endereço, foram mantidos dois servidores da Cloudflare e um do Google. Os dois endereços de um mesmo provedor podem cair juntos por um erro de configuração do próprio provedor, como já aconteceu.

Servidores IPv6 sem IPv6 na rede

A lista de upstreams incluía servidores IPv6, mas o roteador não tinha IPv6 configurado nas WANs. Um ping para esses endereços retornou “Network is unreachable”. Servidores inalcançáveis não acrescentam redundância e podem atrasar consultas. Foram removidos até que o IPv6 seja configurado.

DNS do roteador parado durante o failover

Este foi o achado mais interessante. Ao desligar o link principal, os dispositivos da rede continuavam navegando pela WAN de reserva, mas a resolução de nomes parava. O ping a partir de um cliente funcionava; o ping a partir do próprio roteador retornava “Network is unreachable”.

A causa estava na tabela de rotas. O load-balance do EdgeOS encaminha o tráfego da LAN por tabelas próprias, então os clientes não sentiam a queda. Já o tráfego gerado pelo roteador, incluindo as consultas do dnsmasq aos upstreams, precisa de uma rota padrão na tabela principal. A única rota padrão era a da WAN principal, que ficou inativa. A PPPoE de reserva estava com default-route auto, que só instala uma rota padrão quando não existe outra, e como a rota inativa da principal continuava presente, a reserva nunca instalava a sua.

As opções lb-local e lb-local-metric-change do grupo de load-balance já estavam ativas, mas não bastavam sozinhas. A correção foi adicionar uma rota padrão de reserva pela PPPoE, com distância administrativa maior que a da rota recebida por DHCP (210):

configure
set protocols static interface-route 0.0.0.0/0 next-hop-interface pppoe1 distance 250
commit
save
exit

Com o link principal ativo, a rota de distância 210 continua preferida. Quando ele cai, a rota de distância 250 assume, o roteador volta a alcançar os upstreams, e a resolução, com validação DNSSEC, segue funcionando para toda a rede. Quando o link principal volta, a preferência retorna automaticamente para ele.

Para conferir o comportamento com o link principal desligado:

show load-balance status
show ip route
ping 1.1.1.1 count 3

E, a partir de um cliente, consulte um nome que provavelmente não está em cache. Um Query time acima de zero, com NOERROR e o flag ad, confirma que a consulta foi de fato aos upstreams pela WAN de reserva.

Checklist

• A âncora 38696 está presente em todos os resolvedores que validam DNSSEC, com digest conferido na IANA.
• A âncora obsoleta 19036 foi removida, onde existia.
• O teste com dnssec-failed.org retorna SERVFAIL, e o teste com um domínio assinado retorna NOERROR com o flag ad.
• Os upstreams são consistentes, preferencialmente de mais de um provedor, e todos repassam registros DNSSEC.
• Os upstreams configurados são alcançáveis (atenção a servidores IPv6 em redes sem IPv6).
• O relógio do resolvedor está correto e sincronizado por NTP, porque assinaturas DNSSEC têm validade.
• Em ambientes com failover, o próprio resolvedor tem rota de saída pela WAN de reserva.

Próximos marcos

A troca ainda não terminou. A revogação e a remoção da KSK-2017 estão previstas para 2027. Depois disso, a âncora 20326 pode ser removida das configurações estáticas. Ela não causa problema enquanto estiver lá, mas a remoção mantém a configuração limpa.

A lição que fica é que DNSSEC com âncora estática é uma dívida técnica com data de vencimento. Quem opera dnsmasq, ou qualquer resolvedor sem atualização automática de âncoras, precisa acompanhar os anúncios da IANA e da ICANN e incluir a nova chave antes da próxima troca, e não depois.

Referências

• IANA: Trust Anchors and Rollovers
• IANA: root-anchors.xml (fonte oficial das âncoras)
• IANA: Update to DNSSEC trust anchors (julho de 2024)
• ICANN: Preparing for the Root Zone KSK Rollover: What You Need to Know
• Verisign: The 2024-2026 Root Zone KSK Rollover: Updates and Observations
• Cloudflare: The keys to the Internet change on October 11. Are you ready?
• dnsmasq-discuss: patch que adiciona a âncora KSK-2024 ao trust-anchors.conf
• RFC 5011: Automated Updates of DNS Security (DNSSEC) Trust Anchors
• RFC 8509: A Root Key Trust Anchor Sentinel for DNSSEC
• RFC 8914: Extended DNS Errors
• RFC 9718: DNSSEC Trust Anchor Publication for the Root Zone