Cobrimos a RFC 9989, a atualização DMARCbis, quando ela chegou no início deste ano. Uma de suas correções principais foi a tag np=, uma política específica para subdomínios que não existem. Uma análise de um pesquisador de DNSSEC que está circulando esta semana mostra que a correção tem uma brecha própria, e ela se abre justamente nos domínios que deram o passo extra de assinar seu DNS.
A brecha que a np= veio fechar
O design original do DMARC deixava um vazio curioso. Um proprietário de domínio podia publicar p=reject em seu domínio organizacional e sp=reject para seus subdomínios, e ainda assim não ter política definida para um subdomínio que simplesmente não existe. Não havia nada de errado na especificação, mas as implementações variavam em quão rigorosamente tratavam um subdomínio inventado, e os atacantes perceberam. Falsificar algo como inexistente.seubanco.com e apostar que a lógica de fallback de um receptor fosse permissiva virou um caminho de evasão conhecido, discreto o suficiente para que a maioria dos proprietários de domínio nunca visse isso em seus relatórios agregados, porque esse tráfego nem sempre aparecia como um abuso real de subdomínio apareceria.
A RFC 9989 fecha essa brecha diretamente. A tag np= permite que um proprietário de domínio defina uma política explícita para e-mails que afirmam vir de um subdomínio inexistente do domínio organizacional, independente tanto da política raiz (p=) quanto da política de subdomínios existentes (sp=). Com np=reject, uma mensagem que afirma vir de qualquercoisa.seubanco.com, onde “qualquercoisa” nunca foi provisionado, é rejeitada de imediato, sem depender do comportamento de fallback de um receptor para salvá-lo.
Onde o DNSSEC atrapalha
A tag depende de uma única coisa funcionando corretamente: a capacidade do verificador de determinar que um subdomínio realmente não existe. Essa determinação costumava ser simples. Uma consulta DNS para um nome que nunca foi provisionado retorna NXDOMAIN, um sinal inequívoco.
Zonas assinadas com DNSSEC cada vez mais não respondem dessa forma. A RFC 9824, Negação Compacta de Existência em DNSSEC, define um método mais eficiente para provar que um nome não existe, usando um registro NSEC sintetizado marcado com o pseudo-tipo NXNAME em vez de uma resposta NXDOMAIN tradicional. É uma otimização legítima e cada vez mais comum. Cloudflare e NS1 usam isso desde antes de setembro de 2024, e o Amazon Route 53 e o módulo de assinatura online do Knot DNS também dão suporte a ela.
O problema é que a lógica de verificação do DMARC escrita a partir da definição de “inexistente” da RFC 9989 foi, em grande parte, escrita pensando no NXDOMAIN tradicional. Um verificador que não saiba especificamente checar o bit NXNAME em uma resposta NSEC ou NSEC3 de negação compacta pode simplesmente não reconhecer que um subdomínio é inexistente. Quando isso acontece, a tag np= nunca é acionada. A mensagem cai de volta para o que sp= ou p= especificar, o que pode muito bem ser mais permissivo, reabrindo silenciosamente a exata brecha que a np= foi publicada para fechar.
Um levantamento dos principais um milhão de domínios do final de 2024 encontrou que, entre os domínios com DNSSEC válido, 44% já usavam negação compacta baseada em NSEC. Isso não é uma configuração marginal. É o comportamento padrão de algumas das maiores plataformas de DNS gerenciado da internet, implantado em uma fatia significativa dos domínios que são, por definição, aqueles que levam a segurança de DNS a sério o bastante para ter o DNSSEC ativado.
A ironia desconfortável
Os domínios com maior probabilidade de adotar a np= cedo são os preocupados com segurança que já operam um programa maduro de enforcement de DMARC, e boa parte desses mesmos domínios são os que rodam DNSSEC. Não são duas populações separadas. Elas se sobrepõem bastante, o que significa que os domínios que recorrem à np= como próximo passo de reforço têm uma chance desproporcional de estar em infraestrutura onde, sem um verificador ciente de NXNAME do lado receptor, a tag não faz o que sua documentação promete.
O suporte completo à RFC 9824 do lado da resolução e verificação continua inconsistente. Alguns servidores autoritativos implementam o formato de resposta compacta sem que essa consciência se propague por completo até cada implementação de DMARC dos receptores de e-mail. Até que isso se atualize, tratar a np= como um controle garantido, em vez de um esforço de melhor esforço, é um erro que um proprietário de domínio não vai descobrir por um teste que falhou. Ele vai aparecer, se aparecer, como uma mensagem falsificada vinda de um subdomínio que nunca deveria existir.
O que isso significa para o seu programa
Não trate a np= como substituta de um inventário limpo de subdomínios. A tag é um backup para os subdomínios que você não provisionou, não um substituto para saber quais você realmente controla. Continue publicando registros DMARC explícitos, ou no mínimo um sp= restritivo, para o espaço de subdomínios que você de fato controla.
Pergunte ao seu provedor de DNS se a negação compacta de existência está ativada, e pergunte aos provedores de caixa de entrada receptores se seus verificadores de DMARC têm consciência da RFC 9824. A maioria dos proprietários de domínio nunca teve motivo para fazer nenhuma das duas perguntas. Agora tem.
Não presuma que um registro DMARC em modo monitoramento confirma que isso está funcionando. Os relatórios agregados mostram o que os receptores avaliaram e como, mas um verificador que cai silenciosamente além da np= para uma política mais permissiva não vai sinalizar essa queda como erro em nenhum lugar visível para você.
Continue observando seus relatórios agregados em busca de resultados de autenticação ligados a subdomínios que você sabe que não existem. Se você começar a ver resultados de aprovação, ou resultados que pulam a np= por completo, em nomes que nunca provisionou, esse é o sinal de que essa brecha está ativa no seu domínio especificamente, não apenas em teoria.
A conclusão
A RFC 9989 corrigiu um problema real. A RFC 9824 corrigiu um problema real diferente. Nenhum dos grupos de trabalho quebrou a especificação do outro, e nenhum está errado. Mas os dois padrões não foram projetados um contra o outro, e o resultado é uma tag de política que pode falhar silenciosamente justamente nos domínios que fizeram tudo o mais certo. O DMARC sempre dependeu de detalhes como esse se encaixarem corretamente em toda a cadeia, do seu registro DNS até o verificador do receptor. Este é mais um lembrete de que “publicamos a tag” e “a tag está sendo aplicada” são duas afirmações diferentes, e só monitorar seus relatórios reais diz qual das duas é verdadeira para o seu domínio.
A Excello Mail já oferece suporte à RFC 9989, e rastreamos exatamente esse tipo de lacuna entre o DMARC e a infraestrutura de DNS da qual ele depende, para que uma política que você acredita estar em vigor não acabe sendo apenas teórica. Cadastre-se gratuitamente na Excello Mail e tenha visibilidade real do que sua política DMARC está realmente fazendo, não apenas do que seu registro DNS diz que ela deveria fazer.