NIST SP 800-81r3: o que muda com o novo guia de segurança DNS
Por CaptainDNS
Publicado em 21 de março de 2026
- O NIST publicou o SP 800-81r3 em 19 de março de 2026, primeira atualização do guia de segurança DNS em 13 anos
- Cinco novidades principais: Protective DNS, DNS encriptado (DoT/DoH/DoQ), Zero Trust, OT/IoT e logging forense
- Obrigatório para agências federais americanas (Executive Order Biden), documento de referência para conformidade NIS2 na Europa
- DNSSEC reforçado com QNAME minimization, Compact Denial-of-Existence e migração para ECDSA
- Impacto direto na segurança de e-mail: SPF, DKIM e DMARC dependem da integridade do DNS
- Plano de ação em 6 etapas para se adequar às novas exigências
Em 19 de março de 2026, o National Institute of Standards and Technology publicou a revisão 3 do Special Publication 800-81, o guia federal de referência para a segurança do DNS. A última atualização era de 2013: treze anos durante os quais o cenário DNS foi transformado. Explosão da nuvem, arquiteturas Zero Trust, ransomware industrializado, DNS encriptado (DoT, DoH, DoQ), implantação massiva da IoT. O documento de 2013 não cobria nenhum desses temas.
A urgência dessa revisão fica evidente nos números. Segundo relatórios da IDC e da Infoblox, 92% dos malwares utilizam o DNS como canal de comunicação com os seus servidores de comando (C2). Entre 88% e 90% das organizações sofreram pelo menos um ataque direcionado à sua infraestrutura DNS. O custo médio por incidente ultrapassa 1,1 milhão de dólares. Em 2024, a pesquisa Infoblox "Sitting Ducks" revelou mais de 800.000 domínios vulneráveis ao sequestro, dos quais 70.000 já estavam comprometidos. No mesmo ano, a falha KeyTrap (CVE-2023-50387), uma vulnerabilidade DNSSEC latente por 24 anos, demonstrou que as próprias fundações precisavam de reforço.
O SP 800-81r3 possui 52 páginas e reestrutura inteiramente a doutrina em torno dos papéis operacionais DNS (resolvedor, servidor autoritativo, administrador de zona) em vez das famílias de controlos SP 800-53. Os autores: Scott Rose (NIST), Cricket Liu e Ross Gibson (Infoblox). Além do perímetro federal americano, este guia torna-se uma referência internacional. A ENISA já o cita como documento de implementação para a diretiva europeia NIS2.
Seu domínio segue as recomendações do NIST?
13 anos de atraso: porque essa revisão era urgente
O SP 800-81-2, publicado em setembro de 2013, refletia um DNS ainda amplamente em texto claro. O DNSSEC existia, mas era incipiente. O conceito de DNS encriptado ainda não tinha RFC. O Zero Trust era apenas uma ideia académica. A IoT industrial não existia na escala que conhecemos hoje.
Desde 2013, o cenário mudou fundamentalmente. Em 2016, o RFC 7858 padronizou o DNS over TLS (DoT). Em 2018, o RFC 8484 introduziu o DNS over HTTPS (DoH). Em 2022, o RFC 9250 adicionou o DNS over QUIC (DoQ). Em 2020, o próprio NIST publicou o SP 800-207, a referência de Zero Trust Architecture, sem jamais atualizar o guia DNS para integrar essa doutrina.
A evolução dos ataques tornou a obsolescência insustentável. O ataque "Sitting Ducks", documentado pela Infoblox em 2024, explora delegações DNS órfãs para sequestrar domínios sem comprometer o registrar. Dos 800.000 domínios identificados como vulneráveis, 70.000 já haviam sido sequestrados por grupos cibercriminosos (Vacant Viper, Horrid Hawk, Vextrio). No mesmo ano, a vulnerabilidade KeyTrap (CVE-2023-50387) mostrou que um único pacote DNS especialmente construído podia paralisar um resolvedor DNSSEC por várias horas, uma falha presente no protocolo desde 1999.
No que diz respeito à adoção do DNSSEC, os números estão estagnados. Cerca de 35% dos domínios mundiais são assinados. Nos Estados Unidos, apenas 37% dos domínios .gov possuem validação DNSSEC completa. O SP 800-81-2 já recomendava o DNSSEC, mas sem fornecer orientação operacional suficiente para alcançar uma implantação massiva.
Outra mudança estrutural: a revisão 3 abandona o alinhamento com as famílias de controlos SP 800-53 (AC, SC, AU) para organizar o documento em torno dos papéis operacionais DNS. Essa escolha reflete o feedback das equipas de infraestrutura: um administrador de zona não raciocina em termos de controlos NIST, mas em termos de tarefas cotidianas (assinatura de zona, rotação de chaves, configuração de resolvedor).
Os 5 pilares do NIST SP 800-81r3
Protective DNS: o DNS como arma defensiva
O Protective DNS (PDNS) é a novidade mais estruturante do SP 800-81r3. O conceito: transformar o resolvedor DNS em ponto de filtragem ativo, alimentado por fluxos de threat intelligence, para bloquear resoluções para domínios maliciosos em tempo real.
O funcionamento baseia-se na integração de Response Policy Zones (RPZ), listas de bloqueio mantidas por equipas de segurança e bases de threat intelligence. Quando uma estação de trabalho ou servidor tenta resolver um domínio identificado como malicioso (phishing, C2, exfiltração), o resolvedor PDNS intercepta a requisição e retorna uma resposta de bloqueio ou redirecionamento para uma página de aviso.
O SP 800-81r3 torna o Protective DNS uma recomendação formal, e não apenas uma boa prática. Essa mudança de status tem consequências diretas para as agências federais, que precisarão de justificar qualquer infraestrutura DNS sem capacidades PDNS.
A questão é considerável: se 92% dos malwares se comunicam com a sua infraestrutura de comando via DNS, o PDNS corta esse canal antes mesmo que o malware consiga operar. O programa CISA Protective DNS já está implantado em várias agências. Resolvedores públicos como o Quad9 (9.9.9.9) integram nativamente capacidades PDNS. As soluções comerciais (Infoblox BloxOne Threat Defense, Cisco Umbrella, Akamai Enterprise Threat Protector) adicionam camadas de análise comportamental e machine learning.
O SP 800-81r3 não prescreve uma implementação específica. Ele exige que os resolvedores DNS das organizações disponham de capacidade de filtragem baseada na reputação dos domínios, com atualizações regulares das fontes de threat intelligence.
A encriptação das consultas entra na norma
O SP 800-81r3 oficializa a recomendação de utilizar protocolos DNS encriptados para o tráfego entre o stub resolver (cliente) e o resolvedor recursivo. É uma virada em relação à revisão 2, que não cobria o tema.
A Executive Order de janeiro de 2025 sobre o fortalecimento da cibersegurança acelerou a formalização. Ela impõe às agências federais a implantação do DNS encriptado em um prazo de 180 dias. O SP 800-81r3 fornece o arcabouço técnico para essa obrigação.
Três protocolos são cobertos. DNS over TLS (DoT), definido pelo RFC 7858, utiliza a porta dedicada 853 e um canal TCP/TLS. É o protocolo mais maduro no lado da infraestrutura. DNS over HTTPS (DoH), definido pelo RFC 8484, transita pela porta 443, misturado ao tráfego HTTPS comum. Está amplamente implantado nos navegadores (Firefox, Chrome, Edge). DNS over QUIC (DoQ), definido pelo RFC 9250, combina as vantagens do TLS com o transporte QUIC: sem bloqueio head-of-line, retomada 0-RTT, melhor gestão de mobilidade.
O SP 800-81r3 também aborda a tensão entre encriptação e visibilidade de rede. O DNS encriptado impede a inspeção do tráfego DNS pelos equipamentos de rede tradicionais (firewall, IDS/IPS). O documento recomenda combinar DNS encriptado e Protective DNS: a encriptação protege a confidencialidade das consultas na rede, enquanto o resolvedor PDNS mantém a visibilidade necessária para a filtragem.
DNSSEC reforçado, não substituído
O SP 800-81r3 confirma que o DNSSEC continua a ser a base da integridade DNS. O DNS encriptado protege a confidencialidade do transporte, mas somente o DNSSEC garante a autenticidade e integridade das respostas. As duas tecnologias são complementares, não intercambiáveis. Encriptar uma mentira não a torna verdade: sem DNSSEC, um resolver não consegue distinguir uma resposta autêntica de uma falsificada, mesmo através de um canal encriptado.
A revisão 3 introduz três avanços para o DNSSEC. O primeiro é a QNAME minimization (RFC 9156): em vez de enviar o nome de domínio completo a cada servidor autoritativo na cadeia de resolução, o resolvedor envia apenas a parte necessária para avançar. Isso reduz os vazamentos de informação para os servidores intermediários.
O segundo é o Compact Denial-of-Existence, uma alternativa ao NSEC3 para provar a inexistência de um domínio. O NSEC3 utiliza hashes para evitar a enumeração de zona, mas continua custoso em cálculo e largura de banda. O Compact Denial-of-Existence simplifica o mecanismo mantendo a proteção contra enumeração.
O terceiro é a migração algorítmica. O SP 800-81r3 recomenda a transição para ECDSA P-256 (algoritmo 13) para novas zonas e incentiva a depreciação progressiva do RSA. As assinaturas ECDSA são mais curtas (64 bytes contra 256 do RSA-2048), o que reduz o tamanho das respostas DNS e mitiga os riscos de amplificação.
As lições do KeyTrap foram integradas. O documento destaca a importância das atualizações regulares dos resolvedores e da monitorização dos advisories de segurança relacionados ao DNSSEC. Para entender em detalhes o funcionamento da validação DNSSEC, consulte nosso guia sobre a cadeia de confiança DNSSEC.
Zero Trust: o DNS como ponto de controlo
O SP 800-207 (Zero Trust Architecture), publicado em 2020, define os princípios do "nunca confie, sempre verifique". O SP 800-81r3 integra o DNS nessa arquitetura posicionando o resolvedor como um Policy Enforcement Point (PEP).
Em uma arquitetura Zero Trust, cada solicitação de acesso é avaliada com base no contexto: identidade do utilizador, estado do terminal, localização na rede, horário. O DNS intervém no primeiríssimo estágio da comunicação de rede. Antes que um terminal estabeleça uma ligação TCP ou TLS, ele resolve um nome de domínio. O resolvedor torna-se, portanto, o primeiro ponto onde uma política de acesso pode ser aplicada.
O SP 800-81r3 detalha como segmentar os resolvedores DNS por zonas de confiança. Os terminais da rede interna utilizam um resolvedor PDNS com políticas rígidas. Os terminais de visitantes ou BYOD passam por um resolvedor distinto, com restrições adicionais. Os sistemas críticos (OT, SCADA) dispõem de resolvedores dedicados, isolados da rede corporativa.
Os sinais DNS também são explorados para alimentar os sistemas SIEM e SOAR. Um pico de resoluções para domínios recém-registados (NRD), consultas DNS incomuns (tunneling, exfiltração via registos TXT) ou uma mudança repentina no padrão de resolução podem acionar alertas automatizados.
OT/IoT: segurança DNS nas fronteiras da rede
Pela primeira vez, um documento SP 800-81 dedica uma secção aos ambientes de tecnologia operacional (OT) e à Internet das Coisas. O SP 800-81r3 é categórico: equipamentos industriais e dispositivos conectados são pontos cegos do DNS na maioria das organizações.
As restrições são reais. Muitos dispositivos IoT utilizam stub resolvers mínimos, incapazes de validar DNSSEC ou negociar uma ligação TLS. Controladores industriais (SCADA, CLPs) operam em redes segmentadas, com largura de banda limitada e atualizações de software pouco frequentes. Alguns equipamentos suportam apenas DNS em texto claro via porta UDP 53.
O SP 800-81r3 recomenda uma abordagem em camadas. Como os próprios dispositivos não conseguem encriptar nem validar, a segurança desloca-se para a infraestrutura: resolvers PDNS dedicados para os segmentos OT/IoT, gateways DNS que realizam a validação DNSSEC em nome dos clientes, e logging centralizado do tráfego DNS desses segmentos para detetar comportamentos anómalos. O documento enfatiza o isolamento: um resolver OT nunca deve ser partilhado com a rede corporativa.
Esse pilar reconhece uma realidade que os guias anteriores ignoravam: em um mundo onde um sensor de temperatura comprometido pode se tornar o ponto de entrada para um ransomware industrial, o DNS muitas vezes é o único sinal observável.
Logging e forense DNS
É a primeira vez que um documento NIST da série SP 800-81 detalha os requisitos de registo de logs DNS. A revisão 2 mencionava brevemente o assunto. A revisão 3 o transforma em um pilar por completo.
O SP 800-81r3 especifica o que deve ser registado no nível do resolvedor: cada consulta e cada resposta, com os metadados associados. No mínimo: timestamp, endereço IP de origem, QNAME (nome de domínio consultado), QTYPE (tipo de consulta: A, AAAA, MX, TXT), RCODE (código de resposta: NOERROR, NXDOMAIN, SERVFAIL) e indicadores DNSSEC (AD flag, validation status).
O documento recomenda a integração direta dos logs DNS em um SIEM. Os casos de uso forense são explícitos: rastrear a cadeia de ataque por meio das resoluções DNS (um ransomware sempre resolve o domínio do C2 antes de descarregar o seu payload), detetar a exfiltração de dados via subdomínios DNS (o DNS tunneling codifica dados nas consultas), identificar os domínios de staging utilizados antes de um ataque.
A retenção dos logs é abordada sem prescrever uma duração fixa. O SP 800-81r3 recomenda alinhar a retenção com a política da organização e com os requisitos regulatórios aplicáveis (FISMA, NIS2, PCI DSS).
O Passive DNS (pDNS) também é coberto. Trata-se de recolher as respostas DNS observadas para constituir um histórico de resolução. Esse histórico permite detetar mudanças suspeitas (um domínio legítimo que de repente aponta para um IP em um fornecedor de alojamento bulletproof) e correlacionar indicadores de comprometimento. Para implementar uma monitorização contínua dos seus registos DNS, consulte nosso guia de monitorização DNS resiliente.
O que mudou em relação à revisão 2
A tabela abaixo resume as diferenças entre o SP 800-81-2 (2013) e o SP 800-81r3 (2026).
| Tema | SP 800-81-2 (2013) | SP 800-81r3 (2026) |
|---|---|---|
| DNS encriptado | Não coberto | DoT, DoH, DoQ recomendados |
| Protective DNS | Não coberto | Recomendação formal |
| Zero Trust | Anterior ao conceito | Integração SP 800-207 |
| DNSSEC | Orientação básica | QNAME min., Compact DoE, migração algo |
| OT/IoT | Não coberto | Secção dedicada |
| Logging | Mencionado brevemente | Requisitos detalhados, SIEM |
| Estrutura | Alinhado SP 800-53 | Por papéis operacionais |
| Autores | NIST sozinho | NIST + Infoblox |
Três pontos merecem destaque. A coautoria com a Infoblox é inédita para um SP 800-81: ela traduz a vontade do NIST de ancorar o documento na realidade operacional em vez da teoria. A secção OT/IoT reconhece que os ambientes industriais têm restrições específicas (resolvedores embarcados, largura de banda limitada, impossibilidade de implantar DNSSEC em determinados equipamentos). A reestruturação por papéis operacionais facilita a leitura pelas equipas de infraestrutura, que podem se concentrar nas secções que lhes dizem respeito diretamente.
Impacto regulatório: quem é afetado?
Agências federais americanas
Para as agências federais, o SP 800-81r3 é diretamente aplicável no âmbito do Federal Information Security Modernization Act (FISMA). Cada agência deve alinhar a sua postura DNS com as recomendações do documento no seu próximo ciclo de avaliação.
A Executive Order de janeiro de 2025 reforça essa obrigação. Ela impõe a implantação do DNS encriptado em um prazo de 180 dias para todas as agências do poder executivo. O SP 800-81r3 fornece o arcabouço técnico de referência para atender a essa exigência.
O impacto estende-se aos fornecedores de nuvem via FedRAMP. Todo fornecedor de serviços em nuvem que busca uma autorização FedRAMP precisará de demonstrar que a sua infraestrutura DNS respeita as recomendações do SP 800-81r3. Isso afeta AWS GovCloud, Azure Government, Google Cloud for Government e todos os fornecedores SaaS que tratam dados federais.
A cadeia de fornecimento também é visada. Os subcontratados e prestadores de serviço das agências federais precisarão de alinhar a sua postura DNS para manter os seus contratos governamentais. O SP 800-81r3 se tornará um critério de avaliação nas licitações federais.
Impacto da diretiva europeia NIS2
A diretiva NIS2, em vigor desde outubro de 2024, impõe às entidades essenciais e importantes a implementação de medidas de segurança de rede proporcionais aos riscos. O DNS é explicitamente coberto pelo perímetro da diretiva.
A ENISA (Agência da União Europeia para a Cibersegurança) cita o SP 800-81 como documento de implementação de referência nos seus guias técnicos. A publicação do SP 800-81r3 atualiza essa referência. As organizações sujeitas à NIS2 poderão se apoiar no SP 800-81r3 para documentar a sua postura DNS junto às autoridades nacionais.
Os setores afetados pela NIS2 são amplos: energia, transportes, saúde, água, infraestrutura digital, serviços financeiros, administração pública, espaço, alimentação, química, pesquisa. Toda organização desses setores com mais de 50 funcionários ou faturação acima de 10 milhões de euros está potencialmente no perímetro.
As sanções da NIS2 são dissuasivas: até 10 milhões de euros ou 2% da faturação global para entidades essenciais, 7 milhões de euros ou 1,4% para entidades importantes.
Organizações privadas
As empresas fora do perímetro federal ou NIS2 não estão diretamente sujeitas ao SP 800-81r3. Porém, o documento impõe-se como padrão de facto por diversos mecanismos indiretos.
As seguradoras de riscos cibernéticos estão a incluir cada vez mais a postura DNS nos seus questionários de subscrição. Uma organização incapaz de demonstrar capacidades PDNS, implantação de DNSSEC ou registo de logs DNS poderá ter cobertura negada ou prêmios majorados.
A pressão da cadeia de fornecimento também atua. Se os seus clientes são agências federais ou entidades NIS2, eles exigirão dos seus fornecedores uma postura DNS alinhada ao SP 800-81r3. Essa exigência desce em cascata por toda a cadeia de subcontratação.
A segurança de e-mail depende do DNS
SPF, DKIM e DMARC são registos DNS. Um resolvedor que valida o endereço IP de um remetente contra um registo SPF depende da integridade da resposta DNS. Se um invasor envenenar o cache do resolvedor e substituir um registo SPF falsificado, toda a cadeia de autenticação de e-mail desmorona.
O DNSSEC protege contra esse cenário. Ao assinar os registos MX, SPF (TXT), DKIM (TXT) e DMARC (TXT), o DNSSEC garante que o resolvedor valide dados autênticos. Sem DNSSEC, um invasor capaz de realizar cache poisoning pode usurpar a identidade de e-mail de um domínio, contornar as políticas DMARC e enviar e-mails fraudulentos em nome da organização alvo.
O SP 800-81r3 destaca essa dependência. Ele recomenda considerar a segurança de e-mail e a segurança DNS como um conjunto indissociável. Implantar DMARC com política p=reject sem ativar DNSSEC equivale a trancar a porta da frente deixando a janela aberta.
DANE (DNS-based Authentication of Named Entities) vai além. Por meio de registos TLSA protegidos pelo DNSSEC, o DANE permite autenticar o certificado TLS do servidor de e-mail destinatário. Isso elimina a dependência de autoridades certificadoras terceiras e garante a encriptação de ponta a ponta do transporte SMTP.
MTA-STS constitui uma alternativa quando o DNSSEC ainda não está implantado no domínio. Ele utiliza HTTPS para publicar uma política de transporte seguro. O SP 800-81r3 recomenda ambas as abordagens, com preferência pelo DANE quando o DNSSEC está disponível.
Verifique agora se os seus registos de autenticação de e-mail estão corretamente configurados com nosso DMARC Checker.
Plano de ação: 6 etapas para se adequar
1. Auditar a infraestrutura DNS existente. Comece por um inventário completo das suas zonas DNS, servidores autoritativos e resolvedores. Identifique as zonas não assinadas, os resolvedores sem capacidade de validação DNSSEC e os fluxos DNS em texto claro. O CaptainDNS pode automatizar essa verificação.
2. Implantar DNSSEC em todas as zonas. Assine cada zona com DNSSEC priorizando o algoritmo ECDSA P-256 (algoritmo 13). Verifique se os DS records estão corretamente propagados no TLD. Planeie uma rotação regular das chaves (ZSK a cada 3 meses, KSK a cada 12 a 24 meses). Consulte nosso guia passo a passo para ativar DNSSEC para uma implantação sem interrupção de serviço.
3. Ativar o DNS encriptado. Implante DoT nos seus resolvedores internos para proteger o tráfego das estações de trabalho. Para trabalhadores remotos, configure DoH para que as consultas DNS transitem pela porta 443, compatível com a maioria das redes públicas. Teste DoQ se o seu resolvedor o suportar, especialmente em ambientes com alta latência.
4. Implementar o Protective DNS. Avalie as soluções PDNS adequadas ao seu porte: Quad9 como resolvedor público com filtragem, RPZ em um resolvedor interno (BIND, Unbound, PowerDNS Recursor) ou uma solução comercial para organizações maiores. Configure fluxos de threat intelligence e defina uma política de bloqueio (NXDOMAIN, redirecionamento para página informativa ou apenas registo em modo de observação).
5. Centralizar os logs DNS. Configure o registo de logs em cada resolvedor e servidor autoritativo. Exporte os logs para o seu SIEM (Splunk, Elastic, Microsoft Sentinel) com os campos mínimos recomendados pelo SP 800-81r3: timestamp, IP de origem, QNAME, QTYPE, RCODE, indicadores DNSSEC. Defina regras de correlação para detetar DNS tunneling, resoluções para domínios NRD e picos de erros SERVFAIL.
6. Proteger a cadeia de e-mail. Valide que os seus registos SPF, DKIM e DMARC estão corretamente publicados e protegidos pelo DNSSEC. Implante DANE (TLSA) nos seus servidores de e-mail se o seu fornecedor DNS suportar DNSSEC. Configure MTA-STS como medida complementar. Ative TLS-RPT para receber relatórios sobre falhas de negociação TLS.
FAQ
O que é o NIST SP 800-81r3?
O NIST SP 800-81r3 é a terceira revisão do guia federal americano "Secure Domain Name System (DNS) Deployment Guide". Publicado em 19 de março de 2026 pelo National Institute of Standards and Technology, substitui a revisão 2, de 2013. O documento cobre a segurança do DNS em todos os aspetos: DNSSEC, DNS encriptado (DoT, DoH, DoQ), Protective DNS, integração Zero Trust, registo de logs e ambientes OT/IoT.
O SP 800-81r3 é obrigatório?
Ele é obrigatório para as agências federais americanas no âmbito do FISMA e da Executive Order de janeiro de 2025 sobre cibersegurança. Para as organizações europeias, serve como referência de implementação no contexto da diretiva NIS2. Para as empresas privadas, constitui um padrão de facto, cada vez mais exigido por seguradoras de riscos cibernéticos e contratantes sujeitos a obrigações regulatórias.
O que é o Protective DNS?
O Protective DNS (PDNS) é um resolvedor DNS enriquecido com capacidades de filtragem baseadas em threat intelligence. Ele bloqueia em tempo real as resoluções para domínios identificados como maliciosos (phishing, comando e controlo de malware, exfiltração de dados). O mecanismo baseia-se em Response Policy Zones (RPZ) e fluxos de inteligência de ameaças atualizados continuamente.
Qual a diferença entre DoT, DoH e DoQ?
DNS over TLS (DoT) utiliza um canal TCP/TLS dedicado na porta 853. DNS over HTTPS (DoH) encapsula as consultas DNS em tráfego HTTPS na porta 443. DNS over QUIC (DoQ) utiliza o protocolo QUIC diretamente, combinando encriptação TLS e transporte sem bloqueio head-of-line. DoT é o mais maduro no lado da infraestrutura, DoH o mais difundido nos navegadores, DoQ o mais performático em ambientes com latência variável.
O DNSSEC ainda é recomendado em 2026?
Sim. O SP 800-81r3 reafirma o DNSSEC como a única tecnologia que garante a autenticidade e integridade das respostas DNS. O DNS encriptado (DoT, DoH, DoQ) protege a confidencialidade do transporte, mas não verifica se a resposta provém de facto do servidor autoritativo legítimo. As duas tecnologias são complementares. O SP 800-81r3 acrescenta recomendações sobre QNAME minimization, Compact Denial-of-Existence e migração para o algoritmo ECDSA P-256.
Qual é a relação entre DNS e segurança de e-mail?
SPF, DKIM e DMARC são registos DNS. A validação de um e-mail depende da consulta a esses registos pelo servidor destinatário. Sem DNSSEC, um invasor pode envenenar o cache DNS e substituir registos falsificados, contornando toda a cadeia de autenticação de e-mail. O SP 800-81r3 recomenda tratar a segurança DNS e a segurança de e-mail como um conjunto indissociável.
Quanto tempo leva para se adequar?
A duração depende da maturidade existente. Uma organização que já possui DNSSEC e um resolvedor centralizado pode se adequar em 3 a 6 meses. Uma organização partindo do zero precisará de 6 a 12 meses para uma implantação completa cobrindo DNSSEC, DNS encriptado, Protective DNS e registo de logs. A Executive Order de janeiro de 2025 impõe um prazo de 180 dias para o DNS encriptado nas agências federais.
O SP 800-81r3 aplica-se a PMEs?
O SP 800-81r3 é direcionado às agências federais americanas, mas as suas recomendações são relevantes para qualquer organização. As PMEs europeias sujeitas à NIS2 (mais de 50 funcionários ou 10 milhões de euros de faturação nos setores cobertos) devem documentar a sua postura DNS. As PMEs fora do perímetro regulatório também se beneficiam de um arcabouço estruturado para priorizar os seus investimentos em segurança DNS.
Glossário
- NIST: National Institute of Standards and Technology. Agência federal americana que publica os padrões e guias de segurança da informação de referência para o governo federal.
- SP 800-81: Special Publication 800-81, guia NIST dedicado à implantação segura do DNS. A revisão 3 (r3) é a versão publicada em 19 de março de 2026.
- DNSSEC: Domain Name System Security Extensions. Conjunto de extensões que adicionam assinaturas criptográficas às respostas DNS para garantir a sua autenticidade e integridade.
- DoT (DNS over TLS): protocolo de encriptação DNS definido pelo RFC 7858. Utiliza um canal TLS dedicado na porta TCP 853 entre o cliente e o resolvedor.
- DoH (DNS over HTTPS): protocolo de encriptação DNS definido pelo RFC 8484. Encapsula as consultas DNS em tráfego HTTPS na porta 443.
- DoQ (DNS over QUIC): protocolo de encriptação DNS definido pelo RFC 9250. Utiliza o transporte QUIC para combinar encriptação e desempenho (sem head-of-line blocking, retomada 0-RTT).
- Protective DNS (PDNS): resolvedor DNS enriquecido com capacidades de filtragem em tempo real. Bloqueia resoluções para domínios maliciosos com base em fluxos de threat intelligence.
- RPZ (Response Policy Zone): mecanismo DNS que permite definir políticas de resposta personalizadas. Utilizado por resolvedores PDNS para bloquear ou redirecionar consultas a domínios maliciosos.
- QNAME minimization: técnica (RFC 9156) que reduz a quantidade de informação transmitida aos servidores autoritativos intermediários durante a resolução. Apenas a parte do nome necessária para avançar na resolução é enviada.
- Zero Trust: modelo de segurança baseado no princípio "nunca confie, sempre verifique". O SP 800-207 do NIST define a arquitetura de referência.
- NIS2: diretiva europeia (2022/2555) sobre segurança de redes e informação. Em vigor desde outubro de 2024, impõe obrigações de cibersegurança às entidades essenciais e importantes.
- FISMA: Federal Information Security Modernization Act. Lei americana que impõe às agências federais a implementação de programas de segurança em conformidade com os padrões NIST.
