As vulnerabilidades no DNS abordadas neste artigo afetam versões específicas do PowerDNS Recursor, do PowerDNS Authoritative Server e do BIND 9. Confira os riscos, as versões corrigidas e os cuidados para atualizar a infraestrutura da sua empresa.
Em 21 de outubro de 2026, o PowerDNS e o ISC publicaram correções para vulnerabilidades em softwares responsáveis pela resolução DNS. Os avisos incluem problemas que podem provocar consumo excessivo de recursos, interrupção do serviço e, em condições específicas, envenenamento de cache ou execução remota de código.
Para empresas, MSPs e provedores, a prioridade é identificar os componentes utilizados, conferir as configurações afetadas e aplicar as atualizações correspondentes. Os avisos do PowerDNS Recursor e as correções do BIND 9 ajudam a começar essa revisão.
Quando o DNS falha, os usuários podem deixar de acessar sistemas mesmo com o link de internet funcionando. Uma vulnerabilidade nessa camada também pode comprometer a confiabilidade das respostas usadas para localizar serviços. Por isso, a segurança DNS nas empresas inclui a manutenção da infraestrutura que atende às consultas.
Quem precisa revisar o ambiente
A verificação começa por dois papéis diferentes. O resolvedor recursivo busca respostas em nome dos dispositivos e pode armazená-las em cache. O servidor autoritativo publica os registros de uma zona DNS, como os endereços associados ao domínio de uma empresa.
O PowerDNS mantém produtos separados para essas funções: Recursor e Authoritative Server. O BIND 9 pode ser configurado para diferentes papéis. Identificar apenas o nome do fornecedor é insuficiente para escolher a correção.
Quem administra esses servidores deve conferir o produto, a versão e as condições de cada aviso. A revisão também alcança softwares DNS incorporados a appliances, máquinas virtuais e contêineres, conforme os componentes presentes em cada instalação.
Quando o serviço é terceirizado, cabe solicitar ao fornecedor uma confirmação sobre a aplicabilidade das falhas e as medidas adotadas. Um DNS local que encaminha consultas para outro serviço também precisa entrar no inventário: o encaminhamento não atualiza o software instalado na empresa.
PowerDNS Recursor e a falha na validação DNSSEC
A CVE-2026-85555 permite contornar a validação DNSSEC em uma situação específica: quando um registro de servidor de nomes, ou NS, aponta para uma zona local. Nesse caminho de resolução, o programa pode deixar de validar também as etapas seguintes da consulta.
Isso abre a possibilidade de envenenamento de cache, quando dados DNS indevidos são armazenados e passam a influenciar respostas posteriores. Para a operação, o risco é utilizar informações incorretas ao localizar um serviço.
O problema está no processamento do resolvedor. O aviso não descreve uma quebra da criptografia do DNSSEC, que valida a autenticidade e a integridade dos dados DNS assinados. A correção exige atualizar a implementação vulnerável.
Outras falhas podem afetar o funcionamento do Recursor
O boletim 2026-12 reúne sete CVEs. Além da falha de DNSSEC, há problemas no tratamento de pacotes, conexões e recursos do processo.
| Vulnerabilidade | Efeito descrito no aviso |
|---|---|
| CVE-2026-73206 | Consumo excessivo de recursos na descompressão de nomes DNS, com risco de negação de serviço. |
| CVE-2026-73205 | Acúmulo de conexões TCP encerradas em estado TIME_WAIT, que pode impedir novas conexões de saída. |
| CVE-2026-85556 | Aceitação de uma opção EDNS que deveria ser rejeitada, contornando uma proteção relacionada a EDNS Client Subnet (ECS). |
| CVE-2026-85557 | Um cliente pode monopolizar o acesso ao servidor web interno quando seu TLS está habilitado. |
| CVE-2026-85558 | Vazamento de memória pela retenção de endereços de clientes TCP já desconectados. |
| CVE-2026-85559 | Possível encerramento do Recursor em configurações que aceitam EDNS Client Subnet nas consultas recebidas. |
As condições variam entre as falhas. A indisponibilidade da interface web, por exemplo, tem um alcance diferente do encerramento do resolvedor. A equipe deve usar o boletim para relacionar cada problema aos recursos habilitados no ambiente.
O PowerDNS Authoritative Server também recebeu correção
A CVE-2026-73206 também aparece no aviso 2026-13 do PowerDNS Authoritative Server, publicado no mesmo dia. O processamento de pacotes preparados para explorar a descompressão de nomes pode consumir recursos em excesso e causar negação de serviço.
Esse ponto interessa especialmente a provedores e equipes que hospedam zonas DNS. Uma interrupção nos servidores autoritativos pode afetar a obtenção dos registros de um domínio, dependendo da redundância disponível e das respostas ainda mantidas em cache pelos resolvedores.
Recursor e Authoritative Server têm versões e atualizações próprias. Corrigir um deles não atualiza automaticamente o outro.
BIND 9 tem falhas de disponibilidade e risco de execução de código
O ISC divulgou quatro vulnerabilidades no BIND 9. A aplicabilidade depende da versão e, em parte dos casos, de funcionalidades específicas da configuração.
Consumo excessivo de CPU e memória
A CVE-2026-19630 afeta o processamento de determinadas mensagens DNS no resolvedor. Essas mensagens podem exigir uma quantidade desproporcional de CPU e memória, levando à negação de serviço.
Na operação, isso pode aparecer como demora nas respostas ou indisponibilidade. Aumento de consumo, sozinho, não comprova exploração: a investigação precisa considerar os registros do serviço e as condições de tráfego.
Corrupção de memória em mensagens GSS-TSIG
A CVE-2026-94300 envolve o tratamento de mensagens autenticadas com GSS-TSIG. O aviso descreve corrupção de memória, encerramento do processo named e possibilidade de execução remota de código.
A exploração exige condições específicas, incluindo acesso a uma mensagem UDP previamente assinada e sua reutilização enquanto a chave negociada continua válida. A possibilidade de executar código depende ainda de condições adicionais descritas pelo ISC.
Interrupção em configurações com redirecionamento e RPZ
A CVE-2026-96888 pode encerrar um resolvedor que combine uma zona do tipo redirect com qname-minimization strict.
Já a CVE-2026-97313 envolve servidores que permitem recursão e têm pelo menos duas zonas RPZ, usadas para aplicar políticas às respostas DNS. A condição descrita inclui uma zona com recursive-only yes e outra com recursive-only no. Certos padrões de consulta podem encerrar o processo.
Nos quatro boletins consultados em 23 de outubro, o ISC informa não conhecer exploração ativa nem soluções alternativas conhecidas. As recomendações apontam para a atualização. A existência dessas falhas não demonstra, por si só, que uma empresa tenha sido atacada.
Quais versões receberam as correções
As versões abaixo são as primeiras correções indicadas pelos fabricantes para os ramos apresentados, nos avisos de 21 de outubro de 2026. Elas servem como referência histórica; antes de atualizar, confira a versão corrigida e suportada vigente.
| Produto e ramo | Versões afetadas no ramo | Primeira correção |
|---|---|---|
| PowerDNS Recursor 5.3 | Até 5.3.11 | 5.3.12 |
| PowerDNS Recursor 5.4 | Até 5.4.7 | 5.4.8 |
| PowerDNS Authoritative 4.9 | Até 4.9.17 | 4.9.18 |
| PowerDNS Authoritative 5.0 | Até 5.0.7 | 5.0.8 |
| PowerDNS Authoritative 5.1 | Até 5.1.4 | 5.1.5 |
| BIND 9.20 | 9.20.0 a 9.20.29 | 9.20.30 |
No PowerDNS, os lançamentos do Recursor 5.3.12 e do Authoritative Server registram as correções. O fabricante publicou ainda o Recursor 5.3.13 no mesmo dia, com um ajuste de desempenho relacionado ao uso de EDNS Client Subnet. Quem acompanha a série 5.3 deve considerar também essa atualização.
No BIND, a versão estável indicada pelo ISC na data da verificação é a 9.20.30. A 9.21.27 também recebeu correções, mas pertence ao ramo de desenvolvimento. Para clientes da Supported Preview Edition, os avisos indicam a 9.20.30-S1.
Versões antigas exigem atenção ao suporte. O BIND 9.18 aparece como encerrado no ISC, e o PowerDNS Recursor 5.2 e anteriores estão em fim de vida no suporte open source. A ausência de uma correção para um ramo antigo não significa que ele esteja protegido. Em pacotes de distribuições, appliances ou contratos com suporte estendido, confirme o boletim aplicável e a atualização fornecida pelo responsável.
O que revisar na infraestrutura DNS
Mapeie o caminho das consultas
Identifique os resolvedores utilizados pelas estações, pelos servidores e pelas filiais. Inclua encaminhadores locais e serviços externos. Para cada componente, registre produto, versão, função e responsável pela manutenção.
Em um MSP, faça esse levantamento por cliente. Em um provedor, confira também os diferentes nós que atendem aos assinantes. Um endereço virtual ou balanceado pode representar vários servidores, e a atualização precisa alcançar cada instalação afetada.
Planeje a atualização conforme a função de cada servidor
Leia as notas de atualização e preserve uma cópia da configuração antes da mudança. Verifique a compatibilidade das zonas locais, integrações e políticas utilizadas. Em ambientes redundantes, planeje a sequência para manter capacidade de atendimento durante a manutenção.
Dois servidores com a mesma versão vulnerável continuam expostos à mesma falha. A redundância ajuda na continuidade, mas também precisa entrar no planejamento das correções.
Confira as condições descritas nos boletins
No PowerDNS, observe os cenários com zonas locais, EDNS Client Subnet e servidor web interno. No BIND, a revisão deve considerar GSS-TSIG, RPZ e a combinação de redirecionamento com minimização estrita de QNAME.
Esses detalhes ajudam a priorizar os ambientes. Alterações improvisadas em mecanismos de segurança podem trazer outros efeitos para a operação; siga a correção indicada para o produto e valide qualquer medida temporária com o responsável técnico.
Valide a resolução depois da mudança
Confirme que os processos estão executando a versão esperada. Teste a resolução dos serviços usados pela organização, o acesso às zonas internas e as políticas de bloqueio e liberação existentes. Onde houver validação DNSSEC, verifique também seu funcionamento.
Acompanhe latência, erros de resolução, consumo de CPU e memória e reinicializações inesperadas. Compare o comportamento com o padrão do ambiente. Um processo que voltou a funcionar após reiniciar ainda precisa da correção que trata a vulnerabilidade.
O que solicitar ao fornecedor de DNS gerenciado
Uma empresa pode depender desses componentes sem administrá-los diretamente. Nesse caso, peça ao fornecedor informações que permitam acompanhar o tratamento do risco:
- O serviço utiliza algum dos produtos e configurações contemplados pelos avisos?
- As correções aplicáveis foram implantadas em todos os nós que atendem à empresa?
- Como o fornecedor monitora falhas de resolução e mantém o atendimento durante atualizações?
- Há alguma ação necessária nos encaminhadores, appliances ou demais componentes locais?
Registre a resposta e as pendências com responsáveis e prazos. O guia sobre o que avaliar em uma solução de Protective DNS ajuda a ampliar essa conversa para disponibilidade, redundância e visibilidade do serviço.
Quando considerar um DNS recursivo gerenciado
Manter um resolvedor recursivo próprio exige acompanhar vulnerabilidades, aplicar atualizações e cuidar da disponibilidade do serviço. Para empresas e MSPs que preferem delegar essa operação, o Lumiun DNS é uma alternativa para assumir a resolução dos domínios da internet.
O serviço oferece validação DNSSEC, que verifica a autenticidade e a integridade dos dados DNS assinados, e suporte a DNS sobre HTTPS (DoH) e DNS sobre TLS (DoT). Quando configurados nos dispositivos ou encaminhadores, DoH e DoT criptografam a comunicação desses componentes com o Lumiun DNS.
A plataforma também reúne filtros de segurança e políticas de acesso para bloquear domínios associados a phishing e malware, além de logs e relatórios de consultas e bloqueios. Esses recursos ajudam a equipe de TI a investigar tentativas de acesso a domínios suspeitos e ajustar as regras de navegação.
A adoção pode ser feita por meio do encaminhamento de consultas de um servidor existente. Em ambientes com Active Directory ou zonas internas, o DNS local pode continuar responsável pelos nomes da organização, enquanto as consultas à internet seguem para o Lumiun DNS. Os componentes que permanecerem em uso continuam precisando de manutenção e atualização.
