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 criptografado (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 criptografado (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 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 controles SP 800-53. Os autores: Scott Rose (NIST), Cricket Liu e Ross Gibson (Infoblox). Além do perímetro federal americano, este guia se torna 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: por que 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 criptografado 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 controles SP 800-53 (AC, SC, AU) para organizar o documento em torno dos papéis operacionais DNS. Essa escolha reflete o feedback das equipes de infraestrutura: um administrador de zona não raciocina em termos de controles 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 se baseia na integração de Response Policy Zones (RPZ), listas de bloqueio mantidas por equipes 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 justificar qualquer infraestrutura DNS sem capacidades PDNS.
A questão é considerável: se 92% dos malwares se comunicam com 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 criptografia das consultas entra na norma
O SP 800-81r3 oficializa a recomendação de utilizar protocolos DNS criptografados 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 criptografado 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 gerenciamento de mobilidade.
O SP 800-81r3 também aborda a tensão entre criptografia e visibilidade de rede. O DNS criptografado impede a inspeção do tráfego DNS pelos equipamentos de rede tradicionais (firewall, IDS/IPS). O documento recomenda combinar DNS criptografado e Protective DNS: a criptografia 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 sendo a base da integridade DNS. O DNS criptografado 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. Criptografar 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 criptografado.
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 do monitoramento 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 controle
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 usuário, 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 conexão TCP ou TLS, ele resolve um nome de domínio. O resolvedor se torna, 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-registrados (NRD), consultas DNS incomuns (tunneling, exfiltração via registros 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 seçã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 conexã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 criptografar nem validar, a segurança se desloca 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 detectar comportamentos anômalos. O documento enfatiza o isolamento: um resolver OT nunca deve ser compartilhado 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 registro 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 registrado 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 baixar seu payload), detectar 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 coletar as respostas DNS observadas para constituir um histórico de resolução. Esse histórico permite detectar mudanças suspeitas (um domínio legítimo que de repente aponta para um IP em um provedor de hospedagem bulletproof) e correlacionar indicadores de comprometimento. Para implementar um monitoramento contínuo dos seus registros DNS, consulte nosso guia de monitoramento 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 criptografado | 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 | Seçã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 seçã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 equipes de infraestrutura, que podem se concentrar nas seçõ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 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 criptografado 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 se estende aos provedores de nuvem via FedRAMP. Todo provedor de serviços em nuvem que busca uma autorização FedRAMP precisará demonstrar que sua infraestrutura DNS respeita as recomendações do SP 800-81r3. Isso afeta AWS GovCloud, Azure Government, Google Cloud for Government e todos os provedores 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 alinhar sua postura DNS para manter 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 em 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 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 faturamento 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% do faturamento 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 se impõe como padrão de facto por diversos mecanismos indiretos.
As seguradoras de riscos cibernéticos estão incluindo cada vez mais a postura DNS em seus questionários de subscrição. Uma organização incapaz de demonstrar capacidades PDNS, implantação de DNSSEC ou registro de logs DNS poderá ter cobertura negada ou prêmios majorados.
A pressão da cadeia de fornecimento também atua. Se seus clientes são agências federais ou entidades NIS2, eles exigirão de 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 registros DNS. Um resolvedor que valida o endereço IP de um remetente contra um registro SPF depende da integridade da resposta DNS. Se um invasor envenenar o cache do resolvedor e substituir um registro SPF falsificado, toda a cadeia de autenticação de e-mail desmorona.
O DNSSEC protege contra esse cenário. Ao assinar os registros 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 registros 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 criptografia 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 seus registros 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. Planeje 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 criptografado. 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 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 registro em modo de observação).
5. Centralizar os logs DNS. Configure o registro 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 detectar DNS tunneling, resoluções para domínios NRD e picos de erros SERVFAIL.
6. Proteger a cadeia de e-mail. Valide que seus registros SPF, DKIM e DMARC estão corretamente publicados e protegidos pelo DNSSEC. Implante DANE (TLSA) nos seus servidores de e-mail se o seu provedor 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 aspectos: DNSSEC, DNS criptografado (DoT, DoH, DoQ), Protective DNS, integração Zero Trust, registro 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 controle de malware, exfiltração de dados). O mecanismo se baseia 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 criptografia 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 criptografado (DoT, DoH, DoQ) protege a confidencialidade do transporte, mas não verifica se a resposta provém de fato 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 registros DNS. A validação de um e-mail depende da consulta a esses registros pelo servidor destinatário. Sem DNSSEC, um invasor pode envenenar o cache DNS e substituir registros 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 criptografado, Protective DNS e registro de logs. A Executive Order de janeiro de 2025 impõe um prazo de 180 dias para o DNS criptografado nas agências federais.
O SP 800-81r3 se aplica a PMEs?
O SP 800-81r3 é direcionado às agências federais americanas, mas 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 faturamento nos setores cobertos) devem documentar sua postura DNS. As PMEs fora do perímetro regulatório também se beneficiam de um arcabouço estruturado para priorizar 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 sua autenticidade e integridade.
- DoT (DNS over TLS): protocolo de criptografia 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 criptografia DNS definido pelo RFC 8484. Encapsula as consultas DNS em tráfego HTTPS na porta 443.
- DoQ (DNS over QUIC): protocolo de criptografia DNS definido pelo RFC 9250. Utiliza o transporte QUIC para combinar criptografia 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.
