El tag np de DMARCbis y su punto ciego DNSSEC: lo que todo administrador debe verificar

Q: ¿El tag np protege realmente mis subdominios inexistentes?

Sí, pero con una condición que no siempre se cumple: el DNS debe devolver un NXDOMAIN real para los nombres inexistentes. Si tu zona está firmada con DNSSEC y practica el compact denial of existence, devuelve NOERROR en su lugar. El evaluador DMARC cree entonces que el subdominio existe, descarta np y aplica sp . Si sp es más permisivo que np , la protección queda neutralizada sin ninguna señal.

Q: ¿El compact denial of existence rompe también SPF o DKIM?

No. SPF y DKIM no dependen de la detección de inexistencia de un subdominio. El compact denial afecta únicamente a la lógica DMARCbis que elige entre sp y np según el nombre exista o no. Tus verificaciones SPF y DKIM, así como la política p de tu dominio raíz, no se ven afectadas.

Q: ¿Me afecta si no uso DNSSEC?

En general no: una zona sin firmar devuelve un NXDOMAIN clásico para los nombres inexistentes, y np se activa con normalidad. Una excepción: los wildcards. Un registro *.captaindns.com en A o AAAA hace «existir» cualquier nombre desde el punto de vista del DNS, lo que anula np incluso sin DNSSEC. Comprueba que no tengas un wildcard amplio.

Q: ¿Hay que desactivar DNSSEC para que np funcione?

No, en absoluto. DNSSEC protege la integridad de tus respuestas DNS y desactivarlo abriría riesgos mucho más graves que el punto ciego de np . La solución correcta no es tocar DNSSEC, sino alinear sp con np en tu registro DMARC, para que la protección deje de depender del código de respuesta.

Q: ¿Qué política publicar para estar protegido pese al punto ciego?

Haz que sp sea tan estricto como np . Por ejemplo v=DMARC1; p=reject; sp=reject; np=reject . Con sp=reject , da igual que el receptor crea que el subdominio existe o no: en ambos casos rechaza. Es la única configuración que cierra el punto ciego sea cual sea el comportamiento DNSSEC de tu zona. Publica primero registros dedicados en tus subdominios emisores legítimos.

Q: ¿Los resolvedores públicos como 8.8.8.8 corrigen el problema?

No. Nuestras pruebas confirman que 8.8.8.8, 1.1.1.1 y 9.9.9.9 retransmiten el NOERROR de una zona con compact denial sin reconstruir NXDOMAIN. El indicador opcional CO (Compact Answers OK), que permitiría esa reconstrucción, no está activado por defecto. El evaluador DMARC situado tras esos resolvedores recibe, por tanto, un NOERROR.

Q: ¿Google Cloud DNS se libra realmente?

Sí, según nuestras pruebas. Una consulta a un nombre inexistente en una zona firmada por Google Cloud DNS devuelve un status: NXDOMAIN clásico, con prueba de ausencia en NSEC3. El tag np se activa, por tanto, con normalidad. Es el contraejemplo que muestra que el problema no es inherente a DNSSEC, sino a la elección de compact denial que hacen algunos proveedores.

Q: ¿El IETF va a corregir este comportamiento?

La cuestión se ha planteado en el grupo de trabajo dmarc del IETF, pero no hay ninguna solución cerrada a día de hoy y la RFC 9989 no la aborda. Existen tres vías (leer el pseudotipo NXNAME, generalizar el indicador CO, reintegrar NODATA), ninguna tiene calendario. No cuentes con una corrección rápida: protégete del lado de la configuración ahora.

Q: ¿El tag np sustituye a sp?

No, son complementarios. El tag sp se aplica a los subdominios que existen en tu DNS, np a los que no existen. La cadena de repliegue va de np a sp y a p . Es precisamente porque el receptor recae en sp cuando no puede confirmar la inexistencia por lo que la diferencia entre ambos valores crea el punto ciego.

Por CaptainDNS
Publicado el 7 de julio de 2026

El tag np de DMARCbis, que debería bloquear los subdominios inexistentes, eludido por una respuesta NOERROR en una zona DNSSEC con compact denial

TL;DR

El tag np de DMARCbis (RFC 9989, mayo de 2026) aplica una política a los subdominios que no existen en tu DNS. Es la nueva arma contra la suplantación de subdominios fabricados.
np se apoya en una sola cosa: el código de respuesta NXDOMAIN. El evaluador DMARC solo lo activa si el DNS confirma, mediante un NXDOMAIN estricto, que el nombre no existe.
Muchas zonas DNSSEC modernas responden NOERROR, no NXDOMAIN. Para ahorrar firmas, practican el compact denial of existence o las «black lies». El evaluador cree entonces que el subdominio existe y recae en sp.
Resultado: np=reject queda neutralizado sin el menor mensaje de error en cuanto sp es más permisivo. Un correo suplantado desde factura.captaindns.com pasa.
La corrección cabe en una sola línea de configuración: hacer que sp sea tan estricto como np, y publicar registros DMARC explícitos en tus subdominios emisores legítimos.

DMARCbis es un estándar publicado. Las RFC 9989, 9990 y 9991 (mayo de 2026) reemplazan a la antigua RFC 7489 e introducen el tag np, una respuesta por fin limpia a un viejo agujero de DMARC: el subdominio que nunca se declaró. Antes de np, un atacante podía enviar desde factura.captaindns.com sin que se aplicara ninguna política, porque ese nombre no existía en ningún lugar de la zona. El tag np cierra esa puerta, en teoría.

En teoría. Porque np se apoya en una señal DNS precisa, el código NXDOMAIN, y esa señal ha desaparecido discretamente de buena parte de las zonas DNSSEC realmente desplegadas. En una zona firmada por Cloudflare, AWS Route 53, Microsoft Azure DNS o NS1, una consulta a un nombre inexistente no devuelve NXDOMAIN. Devuelve NOERROR. Y para un evaluador DMARC, NOERROR significa «este subdominio existe». Aplica entonces sp, no np. Si sp es más permisivo, la protección se evapora.

Veredicto. A quién afecta: a todo dominio que confía en un np más estricto que sp, alojado en una zona DNSSEC con compact denial. Gravedad: degradación silenciosa, no una avería. Nada se rompe, ningún log se enciende, tu correo legítimo sale como antes. Solo la promesa anti-suplantación de np queda vaciada de contenido. No es una vulnerabilidad de DNSSEC: DNSSEC hace exactamente lo que se le pide. Es una hipótesis de DMARCbis que ya no se sostiene frente al DNS moderno.

Verifica la compatibilidad DMARCbis y DNSSEC de tu dominio

DMARCbis Checker Verificar DNSSEC

¿Para qué sirve el tag np y en qué se diferencia de sp?

El tag np define la política DMARC que se aplica a los subdominios que no existen en el DNS, mientras que sp define la política de los subdominios que sí existen. La diferencia se reduce a una sola palabra: inexistente. Ahí está todo el problema.

Retomemos el problema que resuelve np. Tu dominio captaindns.com publica sus servidores de correo, sus registros SPF y DKIM, una política DMARC estricta. Pero un atacante no necesita un subdominio que tú hayas declarado. Fabrica el suyo. Envía una factura falsa desde factura.captaindns.com, un nombre que nunca creaste en tu zona. Bajo DMARC v1, ninguna política descendía a ese nivel de forma fiable para los nombres no declarados, y la suplantación pasaba desapercibida. El tag np cubre precisamente ese agujero. Para todo el contexto del estándar, consulta nuestra guía DMARCbis.

DMARCbis distingue por tanto tres ámbitos, con una cadena de repliegue estricta:

Tag	Se aplica a	Valores	Repliegue si ausente
`p`	El propio dominio organizacional	`none` / `quarantine` / `reject`	Ninguno (obligatorio)
`sp`	Los subdominios que existen en el DNS	`none` / `quarantine` / `reject`	Recae en `p`
`np`	Los subdominios inexistentes (NXDOMAIN)	`none` / `quarantine` / `reject`	Recae en `sp`, luego `p`

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

La configuración más habitual en las organizaciones que despliegan np se parece a esto:

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

La lógica del administrador es razonable. El dominio raíz está en observación (p=none), porque hay que vigilar el tráfico legítimo antes de endurecer. Los subdominios reales también (sp=none), mientras se cartografían los servicios que envían. Pero los subdominios que no existen, nadie tiene una razón legítima para usarlos: mejor rechazarlos de inmediato (np=reject). Es el reflejo correcto. El problema no es la lógica. El problema es que, en una zona DNSSEC moderna, ese np=reject quizá no se active nunca.

Recuerda la mecánica del repliegue: np solo se consulta si el receptor ha establecido que el subdominio no existe. De lo contrario, aplica sp. Toda la falla reside en ese «ha establecido que el subdominio no existe».

¿Cómo decide DMARCbis que un subdominio no existe?

DMARCbis considera que un subdominio no existe únicamente cuando el DNS devuelve el código NXDOMAIN. Es un criterio estricto, heredado de un principio DNS formalizado por la RFC 8020: «nada por debajo». Si un nombre devuelve NXDOMAIN, entonces ese nombre y todo lo que pudiera existir por debajo de él no existen. El receptor DMARC se apoya en esa garantía para elegir entre sp y np.

La palabra «NXDOMAIN» aquí es cualquier cosa menos trivial. No significa «no encontré nada». Significa exactamente «este nombre no existe en la zona». Y el DNS distingue dos situaciones de ausencia que a menudo se confunden.

La diferencia entre `NXDOMAIN` y `NODATA`

Dos respuestas DNS significan «ausencia», pero no dicen lo mismo. El receptor DMARC solo reacciona ante la primera.

NXDOMAIN (código de estado NXDOMAIN): el nombre en sí no existe. Ningún registro, de ningún tipo, en ese nombre. Es lo que DMARCbis espera para activar np.
NODATA (código de estado NOERROR, sección de respuesta vacía): el nombre existe, pero no para el tipo consultado. Por ejemplo, blog.captaindns.com tiene un registro AAAA pero no un MX. La consulta MX devuelve NOERROR sin datos. El nombre existe. np no se aplica.

La distinción es perfectamente lógica en un DNS clásico. Un atacante que envía desde un subdominio fabricado provoca un NXDOMAIN, porque el nombre nunca se creó. np muerde. Todo va bien. El desvío se produce cuando la zona está firmada con DNSSEC y decide no volver a devolver NXDOMAIN jamás.

El endurecimiento que introduce DMARCbis

Un detalle histórico explica por qué la falla es más amplia de lo que se piensa. La extensión experimental anterior, la RFC 9091 (PSD DMARC), era más tolerante: para juzgar la existencia de un subdominio, también aceptaba una ausencia de datos en los tipos A, AAAA y MX, no solo un NXDOMAIN puro. Dicho de otro modo, un NODATA en esos tipos contaba como «este subdominio no recibe correo».

DMARCbis endureció esta prueba. La RFC 9989 se apoya únicamente en NXDOMAIN como señal de inexistencia. Esta elección hace el estándar más limpio sobre el papel: un criterio único, sin ambigüedad de tipo. Pero elimina la red que, bajo la RFC 9091, habría atrapado una parte de las zonas DNSSEC que responden NOERROR. El endurecimiento, pensado para el rigor, es precisamente lo que abre el punto ciego frente al compact denial.

¿Qué es el compact denial of existence?

El compact denial of existence es una técnica DNSSEC que prueba la inexistencia de un nombre devolviendo NOERROR con un único registro NSEC sintetizado al vuelo, en lugar del NXDOMAIN clásico. Muchos grandes proveedores de DNS firmado la han adoptado por una razón simple: el coste.

Probar una ausencia en DNSSEC sale caro. El método tradicional (NSEC o NSEC3) exige devolver registros que encuadran el nombre consultado en el orden canónico de la zona, cada uno acompañado de su firma RRSIG. Para un servicio que firma millones de zonas y ve pasar torrentes de consultas a nombres inexistentes (escaneos, erratas, sondeos), eso supone firmas que calcular, almacenar y transmitir de forma permanente. El compact denial esquiva el problema: en lugar de localizar los vecinos reales, el servidor fabrica al vuelo un intervalo NSEC mínimo alrededor del nombre consultado, lo firma una sola vez y responde NOERROR. Menos cálculo, menos bytes en la red, una única firma.

Para señalar que la ausencia es real y no un simple NODATA, la técnica marca la respuesta con un pseudotipo bautizado NXNAME (tipo 128). Un resolvedor que entiende este marcador sabe que «el nombre no existe» se esconde detrás de ese NOERROR. El problema: esa traducción se queda en el resolvedor, no llega hasta el evaluador DMARC en forma de NXDOMAIN.

El indicador CO que podría cambiarlo todo

La especificación prevé un salvavidas, en teoría. Un indicador opcional del lado del resolvedor, «CO» (Compact Answers OK), permite al resolvedor anunciar que gestiona el compact denial y, a cambio, reconstruir un NXDOMAIN real para su cliente cuando la respuesta lleva el marcador NXNAME. Sobre el papel, este mecanismo cierra el punto ciego.

En la práctica, nadie lo activa. Los grandes resolvedores públicos no fijan este indicador por defecto, y el evaluador DMARC que se ejecuta tras ellos recibe el NOERROR en bruto. La corrección existe en el texto, no en el tráfico real.

Para profundizar. NSEC y NSEC3 son los dos mecanismos históricos de prueba de ausencia en DNSSEC; NSEC3 aplica hash a los nombres para dificultar la enumeración de zona, NSEC los expone en claro. La caché agresiva de los resolvedores (RFC 8198) permite reutilizar una prueba NSEC para responder a otros nombres inexistentes sin consulta, pero tampoco restaura el código NXDOMAIN cuando la prueba es un NSEC sintético en NOERROR. La caché acelera, no corrige nada para np.

El escenario paso a paso: cuando NOERROR hace que np recaiga en sp

Este es el desarrollo completo, del envío fraudulento a la entrega. La zona captaindns.com está firmada con compact denial y publica p=none; sp=none; np=reject. Un atacante envía una factura falsa desde factura.captaindns.com, un subdominio que no existe en la zona.

El correo llega al receptor con From: contabilidad@factura.captaindns.com. La autenticación SPF y DKIM falla, lo cual es esperable: el atacante no controla el dominio.
El receptor lanza el tree walk DMARCbis y asciende por las etiquetas hasta encontrar la política. La descubre en _dmarc.captaindns.com: p=none; sp=none; np=reject.
Ahora debe decidir: ¿este subdominio factura.captaindns.com existe o no? De su respuesta depende la elección entre sp (existente) y np (inexistente).
Consulta el DNS para factura.captaindns.com. La zona está firmada con compact denial.
La respuesta vuelve como NOERROR, con un NSEC sintetizado que lleva el marcador NXNAME. El código de estado, el que lee el evaluador DMARC, es NOERROR, no NXDOMAIN.
El receptor concluye que el subdominio existe. Para él, NOERROR significa presencia. Descarta np y selecciona sp.
Aplica sp=none. La factura falsa se entrega. El np=reject publicado nunca se consultó.

Siete pasos, ningún error, ningún log de anomalía. El administrador publicó np=reject de buena fe y cree protegidos sus subdominios inexistentes. No lo están.

La observación es reproducible. Esto es lo que devuelve una consulta directa a un nombre inexistente en una zona firmada por 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

El estado es NOERROR. El NSEC cubre un intervalo mínimo (\000.randomabc123...) y la presencia del tipo 128 (NXNAME) confirma el compact denial. Un evaluador DMARC situado tras un resolvedor clásico verá ese NOERROR tal cual.

En una zona con compact denial, la respuesta NOERROR hace que DMARC recaiga de np=reject a sp=none y el correo suplantado pasa

Para el contraste, una zona firmada que responde correctamente:

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

Estado NXDOMAIN, prueba de ausencia en NSEC3. Aquí, np se activa con normalidad. Misma familia de protocolo, comportamiento opuesto. El proveedor DNS marca toda la diferencia.

¿A quién afecta realmente este punto ciego?

Deben cumplirse tres condiciones a la vez para que la falla muerda. Si falta una, tu np se sigue respetando. Es lo que muchos artículos pasan por alto: el problema no es ni universal ni inevitable.

Deben cumplirse tres condiciones

Tu política publica un np más estricto que el repliegue sp. Si np y sp son idénticos, no hay nada que perder: aplique el receptor uno u otro, el resultado es el mismo.
Tu zona está firmada con DNSSEC y practica el compact denial o las «black lies». Una zona sin firmar, o firmada pero que devuelve un NXDOMAIN real, no plantea este problema.
El evaluador DMARC del receptor se fía del código de respuesta. Es el comportamiento por defecto de casi todas las implementaciones: leen NOERROR frente a NXDOMAIN, no el pseudotipo NXNAME.

El matiz que todos pasan por alto: np frente a sp

El punto decisivo: np solo queda anulado si es más estricto que sp. Mientras el receptor recaiga en sp, es el valor de sp el que decide la suerte del correo suplantado.

Política publicada	Lo que `np` promete	Aplicado en zona con compact denial	¿Expuesto?
`sp=none; np=reject`	Rechazar los subdominios falsos	`sp=none`: el correo pasa	Sí, falla abierta
`sp=quarantine; np=reject`	Rechazar	`sp=quarantine`: spam en lugar de rechazo	Parcial
`sp=reject; np=reject`	Rechazar	`sp=reject`: rechazo igualmente	No
`sp` ausente, `p=reject`, `np=reject`	Rechazar	Repliegue en `p=reject`	No

La última fila es tu vía de salida. Si sp (o su repliegue) ya es tan estricto como np, el punto ciego no tiene ningún efecto. Es la base de la corrección.

La trampa de los wildcards

El compact denial no es la única forma de neutralizar np. Un wildcard DNS también lo hace, y sin DNSSEC alguno. Si tu zona contiene *.captaindns.com, entonces cualquier nombre bajo captaindns.com devuelve una respuesta positiva: el wildcard fabrica una existencia para todo el mundo. Un subdominio que nunca declaraste «existe» ahora desde el punto de vista del DNS, así que np no se aplica nunca y el receptor recae en sp. Un wildcard A o AAAA amplio anula tu np de forma tan segura como una zona con compact denial.

En cuanto a los proveedores, nuestras propias pruebas con dig, que puedes reproducir, dan la siguiente tabla. Varios de los mayores servicios de DNS gestionado responden NOERROR en lugar de NXDOMAIN en las zonas que firman:

Proveedor DNS	Dominio firmado probado	Respuesta al nombre inexistente	¿`np` respetado?
Cloudflare	cloudflare.com	NOERROR + NSEC con NXNAME (tipo 128)	No
NS1 (IBM)	ns1.com	NOERROR + NSEC con NXNAME	No
AWS Route 53	login.gov	NOERROR + NSEC mínimo, sin NXNAME	No
Azure DNS	office.com, hhs.gov	NOERROR + NSEC mínimo, sin NXNAME	No
Google Cloud DNS	fbi.gov	NXDOMAIN (NSEC3)	Sí

Dos lecciones. Primero, dos variantes distintas rompen np. El compact denial estricto con marcador NXNAME (Cloudflare, NS1) y las «black lies» más antiguas, un NOERROR desnudo sin NXNAME (Route 53, Azure). No importa la variante: el denominador común es el código, NOERROR en lugar de NXDOMAIN. Eso amplía claramente el alcance. Segundo, no es inevitable: Google Cloud DNS devuelve un NXDOMAIN clásico y deja que np funcione. El proveedor cuenta.

Una nota de honestidad sobre el alcance. No damos ningún porcentaje: medir la prevalencia exacta de las zonas con compact denial exigiría un barrido global que no hemos realizado. Pero Cloudflare figura entre los mayores proveedores de DNS del mundo, y tanto Route 53 como Azure DNS pesan mucho en la infraestructura empresarial. Cuando cuatro actores de este calibre devuelven NOERROR en sus zonas firmadas, una gran parte de las zonas DNSSEC realmente desplegadas queda afectada. Para Oracle Cloud DNS y Dyn no hemos observado ninguna zona firmada explotable: no los clasificamos en ninguno de los dos bandos.

Árbol de decisión: ¿me afecta el punto ciego de np en DNSSEC según mi proveedor y mi política sp?

¿Cómo verificar si tu np se respeta?

Tres comprobaciones bastan para saber si tu np se aplica realmente. Cada una responde a una de las tres condiciones de la falla. Cuenta con cinco minutos.

Paso 1: ¿tu zona está firmada con DNSSEC?

Empieza por lo más simple. Si tu zona no está firmada, el punto ciego del compact denial no te afecta (ojo de todos modos con la trampa del wildcard vista más arriba). Verifica la presencia de registros DNSKEY y DS con el verificador DNSSEC de CaptainDNS, o en línea de comandos:

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

Una zona firmada devuelve al menos una clave DNSKEY y, del lado del padre, un registro DS. Zona firmada: pasa al paso 2. Zona sin firmar: el paso 3 sigue siendo útil para el caso del wildcard.

Paso 2: ¿un subdominio inventado devuelve `NXDOMAIN` o `NOERROR`?

Es la prueba central. Consulta un nombre que nunca creaste y lee el código de estado, no los datos:

dig +dnssec un-nombre-que-no-existe-9x7q.captaindns.com A

Localiza la línea ;; ->>HEADER<<-. Dos resultados posibles:

status: NXDOMAIN: perfecto, tu np se activa con normalidad. Estás en el caso de Google Cloud DNS.
status: NOERROR: tu zona oculta la inexistencia tras un NOERROR. Tu np recae en sp. Pasa al paso 3 para medir la exposición real.

De paso, prueba desde un resolvedor público, porque es lo que ven los receptores de correo. Nuestros ensayos confirman que 8.8.8.8, 1.1.1.1 y 9.9.9.9 retransmiten el NOERROR sin reconstruir NXDOMAIN. Al no estar activado el indicador CO, el evaluador DMARC aguas abajo recibe efectivamente un NOERROR.

Paso 3: ¿np es más estricto que sp?

Última pregunta, la más decisiva. Recupera tu registro y compara np con sp (y con el repliegue p si sp está ausente):

dig TXT _dmarc.captaindns.com +short

Contrasta los valores con la tabla de la sección anterior. Si np es más estricto que el repliegue sp, y el paso 2 dio NOERROR, tu protección de los subdominios inexistentes está neutralizada. Para leer la sintaxis completa y detectar un tag mal formado, pasa el registro por el verificador de registro DMARC. Si np y el repliegue ya están al mismo nivel, respira: el punto ciego no tiene ningún efecto sobre ti.

¿Cómo proteger tus subdominios desde ahora?

La corrección no depende de un parche futuro del DNS ni del IETF. La despliegas hoy, del lado de la configuración, haciendo tu política insensible al hecho de que np pueda ser ignorado. El principio: nunca dejar que np cargue solo con una protección que sp no garantiza.

La receta con cinturón y tirantes

Alinea sp con np. Si quieres rechazar los subdominios inexistentes, rechaza también los subdominios existentes no legítimos, y conviértelo en tu repliegue:

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

Con sp=reject, da igual que el receptor crea que el subdominio existe o no: en ambos casos rechaza. El compact denial deja de tener efecto. Es la única configuración que cierra el punto ciego sea cual sea el comportamiento de tu zona DNSSEC. Si tu dominio raíz no está listo para p=reject, puedes mantener un p más flexible, pero mantén sp y np al mismo nivel estricto.

Publicar registros en los subdominios emisores

sp=reject bloquea todo lo que no está explícitamente autorizado. Tus subdominios que envían de forma legítima (newsletter.captaindns.com, notifications.captaindns.com) deben, por tanto, llevar su propia configuración de autenticación y, en el mejor de los casos, su propio registro DMARC. Cartografía primero tus emisores con los informes agregados rua, y publica luego para cada uno un registro dedicado antes de endurecer sp. Ese inventario es también lo que te evita rechazar por error un servicio interno.

Un registro limpio, con p, sp y np coherentes, se genera y se valida sin esfuerzo. La herramienta de migración DMARCbis toma tu registro existente y lo adapta al estándar sin romper la retrocompatibilidad v=DMARC1.

La elección del proveedor DNS importa

El comportamiento de prueba de ausencia no es configurable en la mayoría de los proveedores gestionados: lo impone el servicio. Si exiges que np funcione del lado del receptor sin depender de sp, el comportamiento NXDOMAIN de tu proveedor se convierte en un criterio de selección de pleno derecho, al mismo nivel que la latencia o el precio. No es una razón para huir de Cloudflare o Route 53, cuyas ventajas siguen siendo reales. Es una razón para conocer su respuesta a un nombre inexistente, y configurar tu sp en consecuencia. Mientras sp esté alineado con np, el proveedor deja de ser un problema.

¿En qué punto está el IETF sobre este tema?

A día de hoy, no hay ninguna solución cerrada. La tensión entre el tag np y el compact denial of existence se ha planteado en el grupo de trabajo dmarc del IETF, pero aún no ha desembocado en una corrección normativa, y la RFC 9989 no aborda la cuestión. Es una razón más para protegerse del lado de la configuración, sin esperar.

Circulan tres vías, ninguna está decidida:

Leer el pseudotipo NXNAME. Las bibliotecas DMARC podrían aprender a interpretar el marcador NXNAME (tipo 128) como un NXDOMAIN, lo que restablecería np para las zonas con compact denial estricto. Eso dejaría fuera las «black lies» sin NXNAME, como las de Route 53 o Azure.
Desplegar el indicador CO. El ecosistema podría generalizar la activación del indicador Compact Answers OK del lado de los resolvedores, para reconstruir NXDOMAIN antes del evaluador DMARC. Eso supone una coordinación amplia que nada anuncia a corto plazo.
Reintegrar NODATA. Una futura revisión del estándar podría restablecer la tolerancia de la RFC 9091, aceptando de nuevo un NODATA en A, AAAA y MX como señal de inexistencia.

Ninguna de estas vías tiene calendario. No cuentes con una corrección rápida. La buena noticia: no la necesitas. Alinear sp con np neutraliza el punto ciego desde hoy, con independencia de lo que decida el IETF.

🎯 Plan de acción: proteger np en una zona DNSSEC

Prueba tu zona. Consulta un nombre inexistente: dig +dnssec inventado-9x7q.captaindns.com A. Un status: NOERROR señala el punto ciego.
Compara np y sp. Recupera tu registro _dmarc y comprueba si np es más estricto que el repliegue sp. Si es así, y el paso 1 dio NOERROR, estás expuesto.
Alinea sp con np. Publica sp=reject; np=reject (o el nivel estricto que busques) para hacer la protección independiente del código de respuesta DNS.
Inventaría tus emisores. Cartografía los subdominios que realmente envían mediante los informes rua, antes de endurecer sp, para no rechazar nada legítimo.
Publica registros dedicados en cada subdominio emisor legítimo.
Elimina los wildcards amplios (*.captaindns.com en A/AAAA) que hacen «existir» cualquier nombre y anulan np, con DNSSEC o sin él.
Integra el comportamiento NXDOMAIN de tu proveedor DNS en tus criterios, sin convertirlo en un motivo de migración precipitada.

FAQ

¿El tag np protege realmente mis subdominios inexistentes?

Sí, pero con una condición que no siempre se cumple: el DNS debe devolver un NXDOMAIN real para los nombres inexistentes. Si tu zona está firmada con DNSSEC y practica el compact denial of existence, devuelve NOERROR en su lugar. El evaluador DMARC cree entonces que el subdominio existe, descarta np y aplica sp. Si sp es más permisivo que np, la protección queda neutralizada sin ninguna señal.

¿Cómo saber si mi zona DNSSEC responde NOERROR o NXDOMAIN?

Consulta un nombre que nunca creaste y lee el código de estado: dig +dnssec un-nombre-inventado-9x7q.captaindns.com A. Localiza la línea ;; ->>HEADER<<-. Un status: NXDOMAIN significa que np funciona. Un status: NOERROR señala que tu zona oculta la inexistencia, y que np recae en sp.

¿El compact denial of existence rompe también SPF o DKIM?

No. SPF y DKIM no dependen de la detección de inexistencia de un subdominio. El compact denial afecta únicamente a la lógica DMARCbis que elige entre sp y np según el nombre exista o no. Tus verificaciones SPF y DKIM, así como la política p de tu dominio raíz, no se ven afectadas.

¿Me afecta si no uso DNSSEC?

En general no: una zona sin firmar devuelve un NXDOMAIN clásico para los nombres inexistentes, y np se activa con normalidad. Una excepción: los wildcards. Un registro *.captaindns.com en A o AAAA hace «existir» cualquier nombre desde el punto de vista del DNS, lo que anula np incluso sin DNSSEC. Comprueba que no tengas un wildcard amplio.

¿Hay que desactivar DNSSEC para que np funcione?

No, en absoluto. DNSSEC protege la integridad de tus respuestas DNS y desactivarlo abriría riesgos mucho más graves que el punto ciego de np. La solución correcta no es tocar DNSSEC, sino alinear sp con np en tu registro DMARC, para que la protección deje de depender del código de respuesta.

¿Qué política publicar para estar protegido pese al punto ciego?

Haz que sp sea tan estricto como np. Por ejemplo v=DMARC1; p=reject; sp=reject; np=reject. Con sp=reject, da igual que el receptor crea que el subdominio existe o no: en ambos casos rechaza. Es la única configuración que cierra el punto ciego sea cual sea el comportamiento DNSSEC de tu zona. Publica primero registros dedicados en tus subdominios emisores legítimos.

¿Los resolvedores públicos como 8.8.8.8 corrigen el problema?

No. Nuestras pruebas confirman que 8.8.8.8, 1.1.1.1 y 9.9.9.9 retransmiten el NOERROR de una zona con compact denial sin reconstruir NXDOMAIN. El indicador opcional CO (Compact Answers OK), que permitiría esa reconstrucción, no está activado por defecto. El evaluador DMARC situado tras esos resolvedores recibe, por tanto, un NOERROR.

¿Google Cloud DNS se libra realmente?

Sí, según nuestras pruebas. Una consulta a un nombre inexistente en una zona firmada por Google Cloud DNS devuelve un status: NXDOMAIN clásico, con prueba de ausencia en NSEC3. El tag np se activa, por tanto, con normalidad. Es el contraejemplo que muestra que el problema no es inherente a DNSSEC, sino a la elección de compact denial que hacen algunos proveedores.

¿El IETF va a corregir este comportamiento?

La cuestión se ha planteado en el grupo de trabajo dmarc del IETF, pero no hay ninguna solución cerrada a día de hoy y la RFC 9989 no la aborda. Existen tres vías (leer el pseudotipo NXNAME, generalizar el indicador CO, reintegrar NODATA), ninguna tiene calendario. No cuentes con una corrección rápida: protégete del lado de la configuración ahora.

¿El tag np sustituye a sp?

No, son complementarios. El tag sp se aplica a los subdominios que existen en tu DNS, np a los que no existen. La cadena de repliegue va de np a sp y a p. Es precisamente porque el receptor recae en sp cuando no puede confirmar la inexistencia por lo que la diferencia entre ambos valores crea el punto ciego.

Glosario

NXDOMAIN: código de respuesta DNS que significa que el nombre consultado no existe en la zona. Es la única señal que DMARCbis acepta para activar np.
NODATA: respuesta en NOERROR con sección de datos vacía. El nombre existe, pero no para el tipo consultado. No activa np.
NOERROR: código de estado DNS que indica la ausencia de error. Se usa tanto para una respuesta positiva como, en compact denial, para probar una inexistencia, lo que engaña al evaluador DMARC.
Compact denial of existence: técnica DNSSEC que prueba la inexistencia de un nombre mediante un único NSEC sintetizado y una respuesta NOERROR, para ahorrar firmas y ancho de banda.
NXNAME (tipo 128): pseudotipo que marca, en una respuesta con compact denial, que la ausencia es real (el nombre no existe), y no un simple NODATA.
Black lies: variante más antigua del mismo principio, un NOERROR con NSEC mínimo pero sin marcador NXNAME, utilizada en especial por AWS Route 53 y Azure DNS.
Indicador CO (Compact Answers OK): opción del lado del resolvedor que permite reconstruir un NXDOMAIN a partir de una respuesta con compact denial. Rara vez activada en la práctica.
Tag np: política DMARCbis aplicada a los subdominios inexistentes. Repliegue: sp, luego p.

Genera un registro limpio en un minuto: produce una política DMARC con p, sp y np coherentes gracias al generador DMARC, y valida el resultado antes de publicarlo.