Cubrimos RFC 9989, la actualización DMARCbis, cuando llegó a principios de este año. Una de sus correcciones estrella fue la etiqueta np=, una política específica para subdominios que no existen. Un análisis de un investigador de DNSSEC que circula esta semana muestra que la corrección tiene su propio hueco, y se abre precisamente en los dominios que dieron el paso extra de firmar su DNS.
El hueco que np= vino a cerrar
El diseño original de DMARC dejaba un vacío curioso. Un propietario de dominio podía publicar p=reject en su dominio organizacional y sp=reject para sus subdominios, y aun así no tener ninguna política definida para un subdominio que simplemente no existe. No había nada malo en la especificación, pero las implementaciones variaban en cuán estrictamente trataban un subdominio inventado, y los atacantes lo notaron. Suplantar algo como inexistente.tubanco.com y confiar en que la lógica de reserva de un receptor fuera permisiva se convirtió en una vía de evasión conocida, lo bastante silenciosa como para que la mayoría de los propietarios de dominio nunca la vieran en sus reportes agregados, porque ese tráfico no siempre aparecía como lo haría un abuso de subdominio real.
RFC 9989 cierra ese hueco directamente. La etiqueta np= permite a un propietario de dominio fijar una política explícita para correo que dice provenir de un subdominio inexistente del dominio organizacional, independiente tanto de la política raíz (p=) como de la política de subdominios existentes (sp=). Con np=reject, un mensaje que dice venir de cualquiercosa.tubanco.com, donde “cualquiercosa” nunca se aprovisionó, se rechaza directamente, sin depender del comportamiento de reserva de un receptor para salvarte.
Dónde se interpone DNSSEC
La etiqueta depende de una sola cosa que funcione correctamente: la capacidad del verificador para determinar que un subdominio realmente no existe. Esa determinación solía ser simple. Una consulta DNS para un nombre que nunca se aprovisionó devuelve NXDOMAIN, una señal inequívoca.
Las zonas firmadas con DNSSEC cada vez más no responden así. RFC 9824, Negación Compacta de Existencia en DNSSEC, define un método más eficiente para probar que un nombre no existe, usando un registro NSEC sintetizado marcado con el pseudo-tipo NXNAME en lugar de una respuesta NXDOMAIN tradicional. Es una optimización legítima y cada vez más común. Cloudflare y NS1 la operan desde antes de septiembre de 2024, y Amazon Route 53 y el módulo de firmado en línea de Knot DNS también la admiten.
El problema es que la lógica de verificación de DMARC escrita según la definición de “inexistente” de RFC 9989 se escribió en gran medida pensando en el NXDOMAIN tradicional. Un verificador que no sepa específicamente comprobar el bit NXNAME en una respuesta NSEC o NSEC3 de negación compacta puede no reconocer en absoluto que un subdominio es inexistente. Cuando eso ocurre, la etiqueta np= simplemente nunca se activa. El mensaje cae de vuelta a lo que especifique sp= o p=, que bien puede ser más permisivo, reabriendo en silencio exactamente el hueco que np= se publicó para cerrar.
Un estudio de los principales un millón de dominios de finales de 2024 encontró que, entre los dominios con DNSSEC válido, el 44% ya usaba negación compacta basada en NSEC. Eso no es una configuración marginal. Es el comportamiento predeterminado de algunas de las plataformas de DNS gestionado más grandes de internet, desplegado en una porción significativa de los dominios que son, por definición, los que se toman en serio la seguridad de DNS al punto de tener DNSSEC activado.
La ironía incómoda
Los dominios con más probabilidad de adoptar np= temprano son los concienciados en seguridad que ya operan un programa maduro de cumplimiento de DMARC, y buena parte de esos mismos dominios son los que ejecutan DNSSEC. No son dos poblaciones separadas. Se solapan mucho, lo que significa que los dominios que recurren a np= como su siguiente paso de endurecimiento tienen una probabilidad desproporcionada de estar en infraestructura donde, sin un verificador consciente de NXNAME en el extremo receptor, la etiqueta no hace lo que dice su documentación.
El soporte completo de RFC 9824 en el lado de resolución y verificación sigue siendo inconsistente. Algunos servidores autoritativos implementan la forma de respuesta compacta sin que esa conciencia se propague por completo hasta cada implementación de DMARC de los receptores de correo. Hasta que eso se ponga al día, tratar np= como un control garantizado, en lugar de uno de mejor esfuerzo, es un error que un propietario de dominio no descubrirá con una prueba fallida. Aparecerá, si es que aparece, como un mensaje suplantado desde un subdominio que se suponía que nunca debía existir.
Qué significa esto para tu programa
No trates np= como sustituto de un inventario limpio de subdominios. La etiqueta es un respaldo para los subdominios que no aprovisionaste, no un reemplazo de saber cuáles sí controlas. Sigue publicando registros DMARC explícitos, o como mínimo un sp= restrictivo, para el espacio de subdominios que realmente controlas.
Pregunta a tu proveedor de DNS si la negación compacta de existencia está activada, y pregunta a los proveedores de buzones receptores si sus verificadores de DMARC son conscientes de RFC 9824. La mayoría de los propietarios de dominio nunca han tenido motivo para hacer ninguna de las dos preguntas. Ahora sí lo tienen.
No asumas que un registro DMARC en modo monitoreo te confirma que esto funciona. Los reportes agregados muestran qué evaluaron los receptores y cómo, pero un verificador que cae en silencio más allá de np= hacia una política más permisiva no marcará esa caída como error en ningún lugar visible para ti.
Sigue vigilando tus reportes agregados en busca de resultados de autenticación ligados a subdominios que sabes que no existen. Si empiezas a ver resultados de aprobación, o resultados que omiten np= por completo, en nombres que nunca aprovisionaste, esa es la señal de que este hueco está activo en tu dominio específicamente, no solo en teoría.
La conclusión
RFC 9989 arregló un problema real. RFC 9824 arregló un problema real distinto. Ningún grupo de trabajo rompió la especificación del otro, y ninguno está equivocado. Pero los dos estándares no se diseñaron el uno contra el otro, y el resultado es una etiqueta de política que puede fallar en silencio precisamente en los dominios que hicieron todo lo demás bien. DMARC siempre ha dependido de que detalles como este encajen correctamente en toda la cadena, desde tu registro DNS hasta el verificador del receptor. Este es un recordatorio más de que “publicamos la etiqueta” y “la etiqueta se aplica” son dos afirmaciones distintas, y solo monitorear tus reportes reales te dice cuál de las dos es cierta para tu dominio.
Excello Mail ya admite RFC 9989, y rastreamos exactamente este tipo de brechas entre DMARC y la infraestructura DNS de la que depende, para que una política que crees aplicada no resulte ser solo teórica. Regístrate gratis en Excello Mail y obtén visibilidad de lo que tu política DMARC realmente está haciendo, no solo de lo que tu registro DNS dice que debería hacer.