O tag np do DMARCbis e seu ponto cego DNSSEC: o que todo admin deve verificar

Q: O tag np realmente protege meus subdomínios inexistentes?

Sim, mas com uma condição que nem sempre é atendida: o DNS deve retornar um verdadeiro NXDOMAIN para os nomes inexistentes. Se a sua zona está assinada com DNSSEC e pratica o compact denial of existence, ela retorna NOERROR no lugar. O avaliador DMARC acredita então que o subdomínio existe, descarta np e aplica sp . Se sp é mais permissivo que np , a proteção é neutralizada sem nenhum sinal.

Q: O compact denial of existence também quebra o SPF ou o DKIM?

Não. SPF e DKIM não dependem da detecção de inexistência de um subdomínio. O compact denial afeta unicamente a lógica DMARCbis que escolhe entre sp e np conforme o nome exista ou não. Suas verificações SPF e DKIM, assim como a política p do seu domínio raiz, não são afetadas.

Q: Sou afetado se não uso DNSSEC?

Em geral não: uma zona não assinada retorna um NXDOMAIN clássico para os nomes inexistentes, e np é acionado normalmente. Uma exceção: os wildcards. Um registro *.captaindns.com em A ou AAAA faz "existir" qualquer nome do ponto de vista do DNS, o que anula np mesmo sem DNSSEC. Verifique se você não tem um wildcard abrangente.

Q: É preciso desativar o DNSSEC para que np funcione?

Não, de jeito nenhum. O DNSSEC protege a integridade das suas respostas DNS e desativá-lo abriria riscos muito mais graves que o ponto cego de np . A correção certa não é mexer no DNSSEC, mas alinhar sp com np no seu registro DMARC, para que a proteção não dependa mais do código de resposta.

Q: Qual política publicar para estar protegido apesar do ponto cego?

Torne sp tão estrito quanto np . Por exemplo v=DMARC1; p=reject; sp=reject; np=reject . Com sp=reject , não importa se o receptor acredita que o subdomínio existe ou não: nos dois casos ele rejeita. É a única configuração que fecha o ponto cego seja qual for o comportamento DNSSEC da sua zona. Publique primeiro registros dedicados nos seus subdomínios emissores legítimos.

Q: Os resolvedores públicos como o 8.8.8.8 corrigem o problema?

Não. Nossos testes confirmam que 8.8.8.8, 1.1.1.1 e 9.9.9.9 repassam o NOERROR de uma zona em compact denial sem reconstituir NXDOMAIN. A flag opcional CO (Compact Answers OK), que permitiria essa reconstituição, não está ativada por padrão. O avaliador DMARC posicionado atrás desses resolvedores recebe, portanto, um NOERROR.

Q: O Google Cloud DNS está mesmo a salvo?

Sim, de acordo com nossos testes. Uma consulta a um nome inexistente em uma zona assinada pelo Google Cloud DNS retorna um status: NXDOMAIN clássico, com prova de ausência em NSEC3. O tag np é acionado, portanto, normalmente. É o contraexemplo que mostra que o problema não é inerente ao DNSSEC, mas à escolha do compact denial feita por alguns provedores.

Q: A IETF vai corrigir esse comportamento?

A questão foi levantada no grupo de trabalho dmarc da IETF, mas nenhuma solução foi decidida até o momento e a RFC 9989 não a aborda. Existem três caminhos (ler o pseudo-tipo NXNAME, generalizar a flag CO, reintegrar o NODATA), nenhum tem cronograma. Não conte com uma correção rápida: proteja do lado da configuração agora.

Q: O tag np substitui o sp?

Não, eles são complementares. O tag sp se aplica aos subdomínios que existem no seu DNS, np àqueles que não existem. A cadeia de fallback vai de np para sp para p . É justamente porque o receptor recai sobre sp quando não consegue confirmar a inexistência que a diferença entre os dois valores cria o ponto cego.

Por CaptainDNS
Publicado em 7 de julho de 2026

O tag np do DMARCbis, que deveria bloquear os subdomínios inexistentes, contornado por uma resposta NOERROR em uma zona DNSSEC em compact denial

TL;DR

O tag np do DMARCbis (RFC 9989, maio de 2026) aplica uma política aos subdomínios que não existem no seu DNS. É a nova arma contra a falsificação de subdomínios fabricados.
np depende de uma única coisa: o código de resposta NXDOMAIN. O avaliador DMARC só o aciona se o DNS confirmar, por um NXDOMAIN estrito, que o nome não existe.
Muitas zonas DNSSEC modernas respondem NOERROR, e não NXDOMAIN. Para economizar assinaturas, elas praticam o compact denial of existence ou as "black lies". O avaliador acredita então que o subdomínio existe e recai sobre sp.
Resultado: np=reject é neutralizado sem a menor mensagem de erro assim que sp é mais permissivo. Um email falsificado a partir de fatura.captaindns.com passa.
A correção cabe em uma linha de configuração: tornar sp tão estrito quanto np e publicar registros DMARC explícitos nos seus subdomínios emissores legítimos.

O DMARCbis é um padrão publicado. As RFC 9989, 9990 e 9991 (maio de 2026) substituem a antiga RFC 7489 e introduzem o tag np, uma resposta enfim adequada para uma velha brecha do DMARC: o subdomínio que nunca foi declarado. Antes do np, um atacante podia enviar a partir de fatura.captaindns.com sem que nenhuma política se aplicasse, porque esse nome não existia em lugar nenhum da zona. O tag np fecha essa porta, em teoria.

Em teoria. Porque np se apoia em um sinal DNS preciso, o código NXDOMAIN, e esse sinal desapareceu discretamente de boa parte das zonas DNSSEC realmente implantadas. Em uma zona assinada pela Cloudflare, AWS Route 53, Microsoft Azure DNS ou NS1, uma consulta a um nome inexistente não retorna NXDOMAIN. Ela retorna NOERROR. E, para um avaliador DMARC, NOERROR significa "este subdomínio existe". Ele aplica então sp, e não np. Se sp for mais permissivo, a proteção evapora.

Veredito. Quem é afetado: todo domínio que conta com np mais estrito que sp, hospedado em uma zona DNSSEC em compact denial. Gravidade: degradação silenciosa, não uma pane. Nada quebra, nenhum log se acende, seu email legítimo sai como antes. Apenas a promessa antifalsificação de np é esvaziada de substância. Não é uma falha do DNSSEC: o DNSSEC faz exatamente o que se pede dele. É uma premissa do DMARCbis que não se sustenta mais diante do DNS moderno.

Verifique a compatibilidade DMARCbis e DNSSEC do seu domínio

DMARCbis Checker Verificar DNSSEC

Para que serve o tag np e em que ele difere de sp?

O tag np define a política DMARC aplicada aos subdomínios que não existem no DNS, ao passo que sp define a política dos subdomínios que existem. A diferença está em uma única palavra: inexistente. Todo o problema está aí.

Retomemos o problema que np resolve. Seu domínio captaindns.com publica seus servidores de email, seus registros SPF e DKIM, uma política DMARC estrita. Mas um atacante não precisa de um subdomínio que você declarou. Ele fabrica o seu próprio. Ele envia uma fatura falsa a partir de fatura.captaindns.com, um nome que você nunca criou na sua zona. Sob o DMARC v1, nenhuma política descia a esse nível de forma confiável para os nomes não declarados, e a falsificação passava despercebida. O tag np preenche exatamente essa brecha. Para todo o contexto do padrão, veja nosso guia DMARCbis.

O DMARCbis distingue então três escopos, com uma cadeia de fallback estrita:

Tag	Aplica-se a	Valores	Fallback se ausente
`p`	O próprio domínio organizacional	`none` / `quarantine` / `reject`	Nenhum (obrigatório)
`sp`	Os subdomínios que existem no DNS	`none` / `quarantine` / `reject`	Recai sobre `p`
`np`	Os subdomínios inexistentes (NXDOMAIN)	`none` / `quarantine` / `reject`	Recai sobre `sp`, depois `p`

Um caso de uso típico: p=none, sp=none, np=reject

A configuração mais comum entre as organizações que implantam np é parecida com esta:

_dmarc.captaindns.com. 3600 IN TXT "v=DMARC1; p=none; sp=none; np=reject; rua=mailto:dmarc@captaindns.com"

A lógica do administrador é razoável. O domínio raiz está em observação (p=none), porque é preciso monitorar o tráfego legítimo antes de endurecer. Os subdomínios reais também (sp=none), enquanto se mapeiam os serviços que enviam. Mas os subdomínios que não existem, ninguém tem uma razão legítima para usá-los: melhor rejeitá-los de imediato (np=reject). É o reflexo certo. O problema não é a lógica. O problema é que, em uma zona DNSSEC moderna, esse np=reject talvez nunca seja acionado.

Guarde a mecânica do fallback: np só é consultado se o receptor tiver estabelecido que o subdomínio não existe. Caso contrário, ele aplica sp. Toda a brecha está nesse "estabeleceu que o subdomínio não existe".

Como o DMARCbis decide que um subdomínio não existe?

O DMARCbis considera que um subdomínio não existe unicamente quando o DNS retorna o código NXDOMAIN. É um critério estrito, herdado de um princípio DNS formalizado pela RFC 8020: "nada abaixo". Se um nome retorna NXDOMAIN, então esse nome e tudo o que poderia existir abaixo dele não existem. O receptor DMARC se apoia nessa garantia para escolher entre sp e np.

A palavra "NXDOMAIN" aqui é tudo menos trivial. Ela não significa "não encontrei nada". Ela significa precisamente "este nome não existe na zona". E o DNS distingue duas situações de ausência que costumam ser confundidas.

A diferença entre `NXDOMAIN` e `NODATA`

Duas respostas DNS significam "ausência", mas não dizem a mesma coisa. O receptor DMARC só reage à primeira.

NXDOMAIN (código de status NXDOMAIN): o próprio nome não existe. Nenhum registro, de nenhum tipo, nesse nome. É o que o DMARCbis espera para acionar np.
NODATA (código de status NOERROR, seção de resposta vazia): o nome existe, mas não para o tipo solicitado. Por exemplo, blog.captaindns.com tem um registro AAAA mas não tem MX. A consulta MX retorna NOERROR sem dados. O nome existe. np não se aplica.

A distinção é perfeitamente lógica em um DNS clássico. Um atacante que envia a partir de um subdomínio fabricado provoca um NXDOMAIN, porque o nome nunca foi criado. np morde. Tudo certo. O deslize ocorre quando a zona é assinada com DNSSEC e decide nunca mais retornar NXDOMAIN.

O estreitamento introduzido pelo DMARCbis

Um detalhe histórico explica por que a brecha é mais ampla do que se pensa. A extensão experimental anterior, a RFC 9091 (PSD DMARC), era mais tolerante: para julgar a existência de um subdomínio, ela também aceitava uma ausência de dados nos tipos A, AAAA e MX, não apenas um NXDOMAIN puro. Em outras palavras, um NODATA nesses tipos contava como "este subdomínio não recebe email".

O DMARCbis apertou esse teste. A RFC 9989 se apoia apenas em NXDOMAIN como sinal de inexistência. Essa escolha torna o padrão mais limpo no papel: um critério único, sem ambiguidade de tipo. Mas ela suprime a rede que, sob a RFC 9091, teria capturado parte das zonas DNSSEC que respondem NOERROR. O estreitamento, pensado para o rigor, é precisamente o que abre o ponto cego diante do compact denial.

O que é o compact denial of existence?

O compact denial of existence é uma técnica DNSSEC que prova a inexistência de um nome retornando NOERROR com um único registro NSEC sintetizado dinamicamente, em vez do NXDOMAIN clássico. Muitos grandes provedores de DNS assinado a adotaram por uma razão simples: o custo.

Provar uma ausência em DNSSEC custa caro. O método tradicional (NSEC ou NSEC3) exige retornar registros que delimitam o nome solicitado na ordem canônica da zona, cada um acompanhado de sua assinatura RRSIG. Para um serviço que assina milhões de zonas e vê passar torrentes de consultas a nomes inexistentes (varreduras, erros de digitação, sondas), isso representa assinaturas a calcular, armazenar e transmitir permanentemente. O compact denial contorna o problema: em vez de localizar os vizinhos reais, o servidor fabrica dinamicamente um intervalo NSEC mínimo em torno do nome solicitado, assina-o uma vez e responde NOERROR. Menos cálculo, menos bytes na rede, uma única assinatura.

Para sinalizar que a ausência é real e não um simples NODATA, a técnica marca a resposta com um pseudo-tipo chamado NXNAME (tipo 128). Um resolvedor que entende esse marcador sabe que "o nome não existe" se esconde atrás desse NOERROR. O problema: essa tradução fica no resolvedor, ela não sobe até o avaliador DMARC na forma de NXDOMAIN.

A flag CO que poderia mudar tudo

A especificação prevê uma salvaguarda, em teoria. Uma flag opcional no lado do resolvedor, "CO" (Compact Answers OK), permite que o resolvedor anuncie que trata o compact denial e, em troca, reconstitua um verdadeiro NXDOMAIN para o seu cliente quando a resposta carrega o marcador NXNAME. No papel, esse mecanismo fecha o ponto cego.

Na prática, ninguém a ativa. Os grandes resolvedores públicos não definem essa flag por padrão, e o avaliador DMARC que roda por trás deles recebe o NOERROR bruto. A correção existe no texto, não no tráfego real.

Para se aprofundar. NSEC e NSEC3 são os dois mecanismos históricos de prova de ausência em DNSSEC; o NSEC3 aplica hash aos nomes para dificultar a enumeração da zona, o NSEC os expõe em claro. O cache agressivo dos resolvedores (RFC 8198) permite reutilizar uma prova NSEC para responder a outros nomes inexistentes sem consulta, mas ele também não restaura o código NXDOMAIN quando a prova é um NSEC sintético em NOERROR. O cache acelera, ele não corrige nada para np.

O cenário passo a passo: quando NOERROR faz np recair sobre sp

Veja o desenrolar completo, do envio fraudulento à entrega. A zona captaindns.com está assinada em compact denial e publica p=none; sp=none; np=reject. Um atacante envia uma fatura falsa a partir de fatura.captaindns.com, um subdomínio que não existe na zona.

O email chega ao receptor com From: contabilidade@fatura.captaindns.com. A autenticação SPF e DKIM falha, o que é esperado: o atacante não controla o domínio.
O receptor inicia o tree walk DMARCbis e sobe os rótulos até encontrar a política. Ele a descobre em _dmarc.captaindns.com: p=none; sp=none; np=reject.
Agora ele precisa decidir: esse subdomínio fatura.captaindns.com existe ou não? Da sua resposta depende a escolha entre sp (existente) e np (inexistente).
Ele consulta o DNS para fatura.captaindns.com. A zona está assinada em compact denial.
A resposta volta como NOERROR, com um NSEC sintetizado carregando o marcador NXNAME. O código de status, aquele que o avaliador DMARC lê, é NOERROR, não NXDOMAIN.
O receptor conclui que o subdomínio existe. Para ele, NOERROR significa presença. Ele descarta np e seleciona sp.
Ele aplica sp=none. A fatura falsa é entregue. O np=reject publicado nunca foi consultado.

Sete etapas, nenhum erro, nenhum log de anomalia. O administrador publicou np=reject de boa-fé e acredita que seus subdomínios inexistentes estão protegidos. Eles não estão.

A observação é reproduzível. Veja o que retorna uma consulta direta a um nome inexistente em uma zona assinada pela Cloudflare:

$ dig +dnssec +norecurse randomabc123.cloudflare.com A @ns3.cloudflare.com
;; ->>HEADER<<- opcode: QUERY, status: NOERROR
randomabc123.cloudflare.com. IN NSEC \000.randomabc123.cloudflare.com. RRSIG NSEC TYPE128

O status é NOERROR. O NSEC cobre um intervalo mínimo (\000.randomabc123...) e a presença do tipo 128 (NXNAME) confirma o compact denial. Um avaliador DMARC posicionado atrás de um resolvedor clássico verá esse NOERROR tal como está.

Em uma zona em compact denial, a resposta NOERROR faz o DMARC recair de np=reject para sp=none e o email falsificado passa

Em contraste, uma zona assinada que responde corretamente:

$ dig +dnssec randomabc123.fbi.gov A
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN

Status NXDOMAIN, prova de ausência em NSEC3. Aqui, np é acionado normalmente. Mesma família de protocolo, comportamento oposto. O provedor de DNS faz toda a diferença.

Quem é realmente afetado por esse ponto cego?

Três condições precisam estar reunidas simultaneamente para que a brecha morda. Se uma faltar, seu np continua honrado. É o que muitos artigos silenciam: o problema não é universal nem inevitável.

Três condições precisam estar reunidas

Sua política publica np mais estrito que o fallback sp. Se np e sp são idênticos, não há nada a perder: não importa qual deles o receptor aplique, o resultado é o mesmo.
Sua zona está assinada com DNSSEC e pratica o compact denial ou as "black lies". Uma zona não assinada, ou assinada mas retornando um verdadeiro NXDOMAIN, não apresenta esse problema.
O avaliador DMARC do receptor confia no código de resposta. É o comportamento padrão da quase totalidade das implementações: elas leem NOERROR contra NXDOMAIN, não o pseudo-tipo NXNAME.

A nuance que todo mundo perde: np contra sp

O ponto decisivo: np só é derrotado se for mais estrito que sp. Enquanto o receptor recai sobre sp, é o valor de sp que decide o destino do email falsificado.

Política publicada	O que `np` promete	Aplicado em zona em compact denial	Exposto?
`sp=none; np=reject`	Rejeitar os subdomínios falsos	`sp=none`: o email passa	Sim, brecha escancarada
`sp=quarantine; np=reject`	Rejeitar	`sp=quarantine`: spam em vez de rejeição	Parcial
`sp=reject; np=reject`	Rejeitar	`sp=reject`: rejeição mesmo assim	Não
`sp` ausente, `p=reject`, `np=reject`	Rejeitar	Fallback para `p=reject`	Não

A última linha é a sua saída. Se sp (ou seu fallback) já é tão estrito quanto np, o ponto cego não tem nenhum efeito. É a base da correção.

A armadilha dos wildcards

O compact denial não é a única forma de neutralizar np. Um wildcard DNS também faz isso, e sem nenhum DNSSEC. Se a sua zona contém *.captaindns.com, então qualquer nome sob captaindns.com retorna uma resposta positiva: o wildcard fabrica uma existência para todo mundo. Um subdomínio que você nunca declarou passa a "existir" do ponto de vista do DNS, então np nunca se aplica e o receptor recai sobre sp. Um wildcard A ou AAAA abrangente anula o seu np de forma tão certeira quanto uma zona em compact denial.

Do lado dos provedores, nossos próprios testes com dig, que você pode reproduzir, dão a tabela a seguir. Vários dos maiores serviços de DNS gerenciado respondem NOERROR em vez de NXDOMAIN nas zonas que assinam:

Provedor DNS	Domínio assinado testado	Resposta ao nome inexistente	`np` honrado?
Cloudflare	cloudflare.com	NOERROR + NSEC com NXNAME (tipo 128)	Não
NS1 (IBM)	ns1.com	NOERROR + NSEC com NXNAME	Não
AWS Route 53	login.gov	NOERROR + NSEC mínimo, sem NXNAME	Não
Azure DNS	office.com, hhs.gov	NOERROR + NSEC mínimo, sem NXNAME	Não
Google Cloud DNS	fbi.gov	NXDOMAIN (NSEC3)	Sim

Dois aprendizados. Primeiro, duas variantes distintas quebram np. O compact denial estrito com marcador NXNAME (Cloudflare, NS1) e as "black lies" mais antigas, um NOERROR nu sem NXNAME (Route 53, Azure). Não importa a variante: o denominador comum é o código, NOERROR em vez de NXDOMAIN. Isso amplia nitidamente o perímetro. Depois, não é uma fatalidade: o Google Cloud DNS retorna um NXDOMAIN clássico e deixa np funcionar. O provedor conta.

Uma palavra de honestidade sobre o alcance. Não avançamos nenhum percentual: medir a prevalência exata das zonas em compact denial exigiria uma varredura global que não conduzimos. Mas a Cloudflare figura entre os maiores provedores de DNS do mundo, e tanto a Route 53 quanto o Azure DNS pesam muito na infraestrutura corporativa. Quando quatro atores desse calibre retornam NOERROR nas suas zonas assinadas, uma grande parte das zonas DNSSEC realmente implantadas é afetada. Para o Oracle Cloud DNS e o Dyn, não observamos zona assinada explorável: não os classificamos nem em um campo nem no outro.

Árvore de decisão: sou afetado pelo ponto cego np no DNSSEC segundo meu provedor e minha política sp

Como verificar se o seu np é honrado?

Três verificações bastam para saber se o seu np é realmente aplicado. Cada uma responde a uma das três condições da brecha. Conte cinco minutos.

Etapa 1: sua zona está assinada com DNSSEC?

Comece pelo mais simples. Se a sua zona não está assinada, o ponto cego do compact denial não afeta você (atenção, ainda assim, à armadilha do wildcard vista acima). Verifique a presença de registros DNSKEY e DS com o verificador DNSSEC da CaptainDNS, ou pela linha de comando:

dig DNSKEY captaindns.com +short
dig DS captaindns.com +short

Uma zona assinada retorna pelo menos uma chave DNSKEY e, do lado do pai, um registro DS. Zona assinada: passe para a etapa 2. Zona não assinada: a etapa 3 continua útil para o caso do wildcard.

Etapa 2: um subdomínio falso retorna `NXDOMAIN` ou `NOERROR`?

É o teste central. Consulte um nome que você nunca criou e leia o código de status, não os dados:

dig +dnssec um-nome-que-nao-existe-9x7q.captaindns.com A

Localize a linha ;; ->>HEADER<<-. Dois resultados possíveis:

status: NXDOMAIN: perfeito, seu np é acionado normalmente. Você está no caso do Google Cloud DNS.
status: NOERROR: sua zona mascara a inexistência atrás de um NOERROR. Seu np recai sobre sp. Passe para a etapa 3 para medir a exposição real.

Aproveite para testar a partir de um resolvedor público, pois é o que os receptores de email veem. Nossos testes confirmam que 8.8.8.8, 1.1.1.1 e 9.9.9.9 repassam o NOERROR sem reconstituir NXDOMAIN. Como a flag CO não está ativada, o avaliador DMARC a jusante recebe de fato um NOERROR.

Etapa 3: np é mais estrito que sp?

Última pergunta, a mais decisiva. Recupere o seu registro e compare np com sp (e com o fallback p se sp estiver ausente):

dig TXT _dmarc.captaindns.com +short

Confronte os valores com a tabela da seção anterior. Se np é mais estrito que o fallback sp, e a etapa 2 deu NOERROR, a sua proteção dos subdomínios inexistentes está neutralizada. Para ler a sintaxe completa e detectar um tag malformado, passe o registro pelo verificador de registro DMARC. Se np e o fallback já estão no mesmo nível, respire: o ponto cego não tem qualquer influência sobre você.

Como proteger seus subdomínios desde já?

A correção não depende de um patch futuro do DNS ou da IETF. Você a implanta hoje, no lado da configuração, tornando a sua política insensível ao fato de que np possa ser ignorado. O princípio: nunca deixar np sustentar sozinho uma proteção que sp não garante.

A receita com dupla proteção

Alinhe sp com np. Se você quer rejeitar os subdomínios inexistentes, rejeite também os subdomínios existentes não legítimos, e faça disso o seu fallback:

_dmarc.captaindns.com. 3600 IN TXT "v=DMARC1; p=reject; sp=reject; np=reject; rua=mailto:dmarc@captaindns.com"

Com sp=reject, não importa se o receptor acredita que o subdomínio existe ou não: nos dois casos ele rejeita. O compact denial não tem mais nenhuma influência. É a única configuração que fecha o ponto cego seja qual for o comportamento da sua zona DNSSEC. Se o seu domínio raiz não está pronto para p=reject, você pode manter p mais flexível, mas mantenha sp e np no mesmo nível estrito.

Publicar registros nos subdomínios emissores

sp=reject bloqueia tudo o que não é explicitamente autorizado. Seus subdomínios que enviam legitimamente (newsletter.captaindns.com, notifications.captaindns.com) devem, portanto, ter a sua própria configuração de autenticação e, idealmente, o seu próprio registro DMARC. Mapeie primeiro os seus emissores pelos relatórios agregados rua, depois publique um registro dedicado para cada um antes de endurecer sp. Esse inventário é também o que evita rejeitar por engano um serviço interno.

Um registro limpo, com p, sp e np coerentes, é gerado e validado sem esforço. A ferramenta de migração DMARCbis retoma o seu registro existente e o adapta ao padrão sem quebrar a retrocompatibilidade v=DMARC1.

A escolha do provedor DNS conta

O comportamento de prova de ausência não é configurável na maioria dos provedores gerenciados: ele é imposto pelo serviço. Se você exige que np funcione do lado do receptor sem depender de sp, o comportamento NXDOMAIN do seu provedor passa a ser um critério de seleção por si só, tanto quanto a latência ou o preço. Não é motivo para fugir da Cloudflare ou da Route 53, cujas vantagens continuam reais. É motivo para conhecer a resposta delas a um nome inexistente e configurar o seu sp de acordo. Enquanto sp estiver alinhado com np, o provedor deixa de ser um problema.

Em que ponto está a IETF sobre esse assunto?

Até o momento, nenhuma solução foi decidida. A tensão entre o tag np e o compact denial of existence foi levantada no grupo de trabalho dmarc da IETF, mas ainda não resultou em uma correção normativa, e a RFC 9989 não aborda a questão. É mais uma razão para proteger do lado da configuração, sem esperar.

Três caminhos circulam, nenhum está decidido:

Ler o pseudo-tipo NXNAME. As bibliotecas DMARC poderiam aprender a interpretar o marcador NXNAME (tipo 128) como um NXDOMAIN, o que restabeleceria np para as zonas em compact denial estrito. Isso deixaria de fora as "black lies" sem NXNAME, como as da Route 53 ou do Azure.
Implantar a flag CO. O ecossistema poderia generalizar a ativação da flag Compact Answers OK no lado dos resolvedores, para reconstituir NXDOMAIN a montante do avaliador DMARC. Isso pressupõe uma coordenação ampla que nada permite prever a curto prazo.
Reintegrar o NODATA. Uma futura revisão do padrão poderia restabelecer a tolerância da RFC 9091, aceitando novamente um NODATA em A, AAAA e MX como sinal de inexistência.

Nenhum desses caminhos tem cronograma. Não conte com uma correção rápida. A boa notícia: você não precisa dela. Alinhar sp com np neutraliza o ponto cego já hoje, independentemente do que a IETF venha a decidir.

🎯 Plano de ação: proteger np em uma zona DNSSEC

Teste a sua zona. Consulte um nome inexistente: dig +dnssec bidon-9x7q.captaindns.com A. Um status: NOERROR sinaliza o ponto cego.
Compare np e sp. Recupere o seu registro _dmarc e verifique se np é mais estrito que o fallback sp. Se sim, e a etapa 1 deu NOERROR, você está exposto.
Alinhe sp com np. Publique sp=reject; np=reject (ou o nível estrito que você almeja) para tornar a proteção independente do código de resposta DNS.
Inventarie os seus emissores. Mapeie os subdomínios que realmente enviam pelos relatórios rua, antes de endurecer sp, para não rejeitar nada legítimo.
Publique registros dedicados em cada subdomínio emissor legítimo.
Elimine os wildcards abrangentes (*.captaindns.com em A/AAAA) que fazem "existir" qualquer nome e anulam np, com DNSSEC ou sem.
Integre o comportamento NXDOMAIN do seu provedor DNS aos seus critérios, sem fazer disso um motivo de migração precipitada.

FAQ

O tag np realmente protege meus subdomínios inexistentes?

Sim, mas com uma condição que nem sempre é atendida: o DNS deve retornar um verdadeiro NXDOMAIN para os nomes inexistentes. Se a sua zona está assinada com DNSSEC e pratica o compact denial of existence, ela retorna NOERROR no lugar. O avaliador DMARC acredita então que o subdomínio existe, descarta np e aplica sp. Se sp é mais permissivo que np, a proteção é neutralizada sem nenhum sinal.

Como saber se a minha zona DNSSEC responde NOERROR ou NXDOMAIN?

Consulte um nome que você nunca criou e leia o código de status: dig +dnssec um-nome-falso-9x7q.captaindns.com A. Localize a linha ;; ->>HEADER<<-. Um status: NXDOMAIN significa que np funciona. Um status: NOERROR sinaliza que a sua zona mascara a inexistência, e que np recai sobre sp.

O compact denial of existence também quebra o SPF ou o DKIM?

Não. SPF e DKIM não dependem da detecção de inexistência de um subdomínio. O compact denial afeta unicamente a lógica DMARCbis que escolhe entre sp e np conforme o nome exista ou não. Suas verificações SPF e DKIM, assim como a política p do seu domínio raiz, não são afetadas.

Sou afetado se não uso DNSSEC?

Em geral não: uma zona não assinada retorna um NXDOMAIN clássico para os nomes inexistentes, e np é acionado normalmente. Uma exceção: os wildcards. Um registro *.captaindns.com em A ou AAAA faz "existir" qualquer nome do ponto de vista do DNS, o que anula np mesmo sem DNSSEC. Verifique se você não tem um wildcard abrangente.

É preciso desativar o DNSSEC para que np funcione?

Não, de jeito nenhum. O DNSSEC protege a integridade das suas respostas DNS e desativá-lo abriria riscos muito mais graves que o ponto cego de np. A correção certa não é mexer no DNSSEC, mas alinhar sp com np no seu registro DMARC, para que a proteção não dependa mais do código de resposta.

Qual política publicar para estar protegido apesar do ponto cego?

Torne sp tão estrito quanto np. Por exemplo v=DMARC1; p=reject; sp=reject; np=reject. Com sp=reject, não importa se o receptor acredita que o subdomínio existe ou não: nos dois casos ele rejeita. É a única configuração que fecha o ponto cego seja qual for o comportamento DNSSEC da sua zona. Publique primeiro registros dedicados nos seus subdomínios emissores legítimos.

Os resolvedores públicos como o 8.8.8.8 corrigem o problema?

Não. Nossos testes confirmam que 8.8.8.8, 1.1.1.1 e 9.9.9.9 repassam o NOERROR de uma zona em compact denial sem reconstituir NXDOMAIN. A flag opcional CO (Compact Answers OK), que permitiria essa reconstituição, não está ativada por padrão. O avaliador DMARC posicionado atrás desses resolvedores recebe, portanto, um NOERROR.

O Google Cloud DNS está mesmo a salvo?

Sim, de acordo com nossos testes. Uma consulta a um nome inexistente em uma zona assinada pelo Google Cloud DNS retorna um status: NXDOMAIN clássico, com prova de ausência em NSEC3. O tag np é acionado, portanto, normalmente. É o contraexemplo que mostra que o problema não é inerente ao DNSSEC, mas à escolha do compact denial feita por alguns provedores.

A IETF vai corrigir esse comportamento?

A questão foi levantada no grupo de trabalho dmarc da IETF, mas nenhuma solução foi decidida até o momento e a RFC 9989 não a aborda. Existem três caminhos (ler o pseudo-tipo NXNAME, generalizar a flag CO, reintegrar o NODATA), nenhum tem cronograma. Não conte com uma correção rápida: proteja do lado da configuração agora.

O tag np substitui o sp?

Não, eles são complementares. O tag sp se aplica aos subdomínios que existem no seu DNS, np àqueles que não existem. A cadeia de fallback vai de np para sp para p. É justamente porque o receptor recai sobre sp quando não consegue confirmar a inexistência que a diferença entre os dois valores cria o ponto cego.

Glossário

NXDOMAIN: código de resposta DNS que significa que o nome solicitado não existe na zona. É o único sinal que o DMARCbis aceita para acionar np.
NODATA: resposta em NOERROR com seção de dados vazia. O nome existe, mas não para o tipo solicitado. Não aciona np.
NOERROR: código de status DNS que indica a ausência de erro. Usado tanto para uma resposta positiva quanto, no compact denial, para provar uma inexistência, o que engana o avaliador DMARC.
Compact denial of existence: técnica DNSSEC que prova a inexistência de um nome por meio de um único NSEC sintetizado e uma resposta NOERROR, para economizar assinaturas e largura de banda.
NXNAME (tipo 128): pseudo-tipo que marca, em uma resposta em compact denial, que a ausência é real (o nome não existe), e não um simples NODATA.
Black lies: variante mais antiga do mesmo princípio, um NOERROR com NSEC mínimo mas sem marcador NXNAME, usada sobretudo pela AWS Route 53 e pelo Azure DNS.
Flag CO (Compact Answers OK): opção no lado do resolvedor que permite reconstituir um NXDOMAIN a partir de uma resposta em compact denial. Raramente ativada na prática.
Tag np: política DMARCbis aplicada aos subdomínios inexistentes. Fallback: sp, depois p.

Gere um registro limpo em um minuto: produza uma política DMARC com p, sp e np coerentes usando o gerador DMARC, depois valide o resultado antes de publicar.