Neste início dessa semana, alguns equipamentos que utilizam o dnsmasq com DNSSEC pararam de resolver nomes, por causa da troca da chave da raiz do DNS. O caso está explicado em detalhes na nossa publicação em Troca da chave da raiz do DNS: por que o dnsmasq com DNSSEC parou de resolver nomes em 11/10/2026. O episódio nos levou a explicar melhor a importância de usar o DNSSEC junto com o dnsmasq, e os cuidados que essa combinação exige.

O dnsmasq é o DNS de milhões de roteadores, firewalls e servidores pequenos. Ele encaminha as consultas para servidores upstream e guarda as respostas em cache. O que pouca gente sabe é que ele também pode validar DNSSEC, e que essa validação exige um cuidado que outros resolvedores dispensam: as âncoras de confiança.

Este artigo tem duas partes. A primeira explica como o dnsmasq trata o DNSSEC e por que a âncora de confiança é responsabilidade de quem o administra. A segunda mostra, de forma prática, como ativar e testar a validação nas plataformas mais comuns.

1. O dnsmasq e o DNSSEC

O que o DNSSEC protege

Sem DNSSEC, um resolvedor de DNS aceita qualquer resposta que pareça vir do servidor consultado. Isso abre espaço para envenenamento de cache e para respostas forjadas ou manipuladas no caminho, inclusive por intermediários tais como provedores. O DNSSEC acrescenta assinaturas criptográficas aos registros, e um resolvedor validador recusa qualquer resposta cuja assinatura não confere.

No cenário típico, o dnsmasq encaminha para resolvedores públicos (Cloudflare, Google, Quad9) que já validam DNSSEC. A validação local cobre o trecho que esses resolvedores não cobrem: o caminho entre eles e o seu roteador, por onde as consultas trafegam sem criptografia. Os dispositivos da LAN, em geral, não validam nada e confiam no roteador. Se o roteador valida, a rede inteira se beneficia.

E se o domínio não for assinado?

Ativar o DNSSEC no dnsmasq não bloqueia domínios sem assinatura, que ainda são muitos. Para cada resposta, o dnsmasq tenta montar a cadeia de confiança a partir da raiz. Se a cadeia confere, a resposta é classificada como SECURE e entregue com o flag ad (Authenticated Data).

Se a zona-pai mostra que o domínio não tem registro DS, ou seja, que ele nunca foi assinado, a resposta é classificada como INSECURE e entregue normalmente, só que sem o flag ad. Para o usuário, nada muda: o site abre como antes. O SERVFAIL fica reservado às respostas BOGUS, cuja assinatura existe mas não confere, ou cuja cadeia está quebrada.

O ponto delicado é distinguir um domínio que nunca foi assinado de um domínio assinado cujas assinaturas foram removidas no caminho por um atacante.

É isso que faz a opção dnssec-check-unsigned. Com ela, o dnsmasq só aceita uma resposta como INSECURE se a zona-pai provar, com uma negação de existência assinada (registros NSEC ou NSEC3), que o domínio realmente não tem DS. Sem essa prova, a resposta é tratada como BOGUS.

Sem a opção, o dnsmasq aceita respostas não assinadas sem pedir prova, e um atacante poderia anular a proteção simplesmente apagando as assinaturas. Por isso, DNSSEC sem dnssec-check-unsigned oferece uma proteção bem mais fraca do que parece.

O DNSSEC vem desligado

Mesmo quando o dnsmasq foi compilado com suporte a DNSSEC, a validação fica desativada por padrão. Para confirmar se o seu binário tem esse suporte:

dnsmasq --version

Na linha de opções de compilação deve aparecer DNSSEC. Se aparecer no-DNSSEC, ele não valida, e é preciso instalar outra variante do pacote (no OpenWrt, por exemplo, o dnsmasq-full).

A âncora de confiança é responsabilidade sua

A validação DNSSEC começa pela raiz do DNS. Para confiar nela, o resolvedor precisa de uma cópia local da chave da raiz, a âncora de confiança (trust anchor). Resolvedores como Unbound, BIND e Knot Resolver mantêm essa âncora atualizada automaticamente, pelo mecanismo da RFC 5011.

O dnsmasq não faz isso. Ele usa apenas as âncoras que recebe pela configuração: linhas trust-anchor= escritas à mão ou um arquivo de âncoras distribuído com o pacote. Esse arquivo só muda quando o pacote é atualizado, e em alguns sistemas, como o Ubiquiti EdgeOS, as âncoras ficam na própria configuração e nunca são atualizadas por pacote.

A consequência apareceu em 11 de outubro de 2026. A raiz passou a usar a nova chave, KSK-2024 (key tag 38696), e todo dnsmasq com DNSSEC ativo sem essa âncora começou a responder SERVFAIL para qualquer domínio. A proteção virou indisponibilidade.

Vale a pena, então?

Vale, desde que você trate a âncora como item de manutenção, com o mesmo cuidado de um certificado com data de validade. Os custos são pequenos: algumas consultas extras para buscar a cadeia de chaves e um pouco de latência na primeira resolução de cada domínio. O risco real é operacional: âncora desatualizada, relógio errado ou upstream que não repassa os registros DNSSEC.

2. como configurar o DNSSEC no dnsmasq

Pré-requisitos

• Âncora atual da raiz. Hoje, a key tag 38696. Confira o digest na fonte oficial, o arquivo root-anchors.xml da IANA:

trust-anchor=.,38696,8,2,683D2D0ACB8C9B712A1948B27F741219298D0A450D612C483AF444A4C0FB2B16

A âncora anterior (20326) pode ficar até a revogação da KSK-2017, prevista para 2027. A 19036, de 2010, é obsoleta e deve ser removida.

• Upstreams compatíveis. Os servidores upstream precisam devolver os registros DNSSEC (RRSIG, DS, DNSKEY). Cloudflare, Google e Quad9 fazem isso. Resolvedores de operadoras nem sempre.
• Relógio correto. As assinaturas DNSSEC têm validade, e com o relógio errado tudo parece inválido. Isso pesa em roteadores sem relógio de hardware, que ligam com a data errada e dependem do NTP. Mas o NTP precisa de DNS para encontrar o servidor de horário, e o DNS precisa da hora certa para validar. Há duas saídas: configurar o NTP por endereço IP, ou usar a opção dnssec-timestamp=, descrita adiante.

Linux (Debian, Ubuntu e similares)

No /etc/dnsmasq.conf, ou num arquivo em /etc/dnsmasq.d/:

dnssec
conf-file=/usr/share/dnsmasq-base/trust-anchors.conf
dnssec-check-unsigned

O caminho do arquivo de âncoras varia por distribuição. Para encontrá-lo e conferir se ele já traz a nova chave:

find / -name "trust-anchors.conf" 2>/dev/null
grep 38696 /caminho/encontrado/trust-anchors.conf

Se o arquivo não tiver a 38696, atualize o pacote ou substitua a linha conf-file= pela linha trust-anchor= mostrada nos pré-requisitos. Depois, reinicie o serviço:

sudo systemctl restart dnsmasq

OpenWrt

A validação exige o pacote dnsmasq-full, no lugar do dnsmasq padrão. Com ele instalado:

uci set dhcp.@dnsmasq[0].dnssec='1'
uci set dhcp.@dnsmasq[0].dnsseccheckunsigned='1'
uci commit dhcp
/etc/init.d/dnsmasq restart

O script de inicialização inclui o arquivo de âncoras do pacote. Confira se a 38696 está nele, porque em versões antigas do OpenWrt ela não estará.

Ubiquiti EdgeOS

Os comandos abaixo só funcionam dentro do modo de configuração (configure):

configure
set service dns forwarding options dnssec
set service dns forwarding options dnssec-check-unsigned
set service dns forwarding options trust-anchor=.,38696,8,2,683D2D0ACB8C9B712A1948B27F741219298D0A450D612C483AF444A4C0FB2B16
commit
save
exit

No EdgeOS, as âncoras ficam na configuração e não mudam com atualizações de firmware. Elas só mudam se você mudar.

Pi-hole

O DNSSEC é ativado nas configurações de DNS da interface web. Mantenha o Pi-hole atualizado, porque as âncoras vêm com o próprio software.

Opções úteis

• dnssec-check-unsigned: exige prova de que domínios sem assinatura realmente não são assinados (veja a Parte 1). É a configuração recomendada, mas também a mais sensível a upstreams problemáticos. Se surgirem falhas intermitentes, é a primeira suspeita.
• dnssec-timestamp=/caminho/arquivo: resolve o problema do relógio em roteadores. O dnsmasq só ativa a verificação de validade das assinaturas quando a hora do sistema passa da data gravada no arquivo, o que indica que o NTP já sincronizou.
• log-queries: útil para depuração. O log mostra o resultado da validação de cada resposta (SECURE, INSECURE ou BOGUS). Desative depois, porque o volume é alto.

Teste a configuração

A partir de um cliente da rede, troque IP-DO-RESOLVEDOR pelo endereço do seu dnsmasq:

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

O primeiro domínio foi quebrado de propósito e deve retornar SERVFAIL. O segundo deve retornar NOERROR com o flag ad na linha flags:. Os dois juntos mostram que a validação recusa o que é inválido e autentica o que é válido.

Mantenha a âncora em dia

Coloque na rotina três verificações:

• Atualizações: acompanhe os anúncios de troca de chave da raiz, publicados pela IANA e pela ICANN com anos de antecedência.
• Inventário: compare periodicamente as âncoras configuradas com o root-anchors.xml da IANA.
• Pacotes: mantenha o pacote do dnsmasq e o firmware dos equipamentos atualizados, e lembre que equipamentos sem suporte do fabricante não receberão novas âncoras.

O próximo marco é a revogação da KSK-2017, prevista para 2027. O DNSSEC no dnsmasq protege de verdade, desde que a âncora seja tratada como o que é: um item de configuração com prazo de validade.

Referências

• IANA: root-anchors.xml (fonte oficial das âncoras)
• IANA: Trust Anchors and Rollovers
• ICANN: Preparing for the Root Zone KSK Rollover: What You Need to Know
• dnsmasq-discuss: patch que adiciona a âncora KSK-2024 ao trust-anchors.conf
• RFC 5011: Automated Updates of DNS Security (DNSSEC) Trust Anchors
• RFC 4035: Protocol Modifications for the DNS Security Extensions