NIST SP 800-81r3: qué cambia la nueva guía de seguridad DNS
Por CaptainDNS
Publicado el 21 de marzo de 2026
- El NIST publicó el SP 800-81r3 el 19 de marzo de 2026, primera actualización de la guía de seguridad DNS en 13 años
- Cinco incorporaciones principales: Protective DNS, DNS cifrado (DoT/DoH/DoQ), Zero Trust, OT/IoT y logging forense
- Obligatorio para las agencias federales estadounidenses (Executive Order Biden), documento de referencia para la conformidad NIS2 en Europa
- DNSSEC reforzado con QNAME minimization, Compact Denial-of-Existence y migración a ECDSA
- Impacto directo en la seguridad del email: SPF, DKIM y DMARC dependen de la integridad del DNS
- Plan de acción en 6 pasos para alcanzar la conformidad
El 19 de marzo de 2026, el National Institute of Standards and Technology publicó la revisión 3 del Special Publication 800-81, la guía federal de referencia para la protección del DNS. La última actualización databa de 2013: trece años durante los cuales el panorama DNS se transformó por completo. Explosión del cloud, arquitecturas Zero Trust, ransomware industrializado, DNS cifrado (DoT, DoH, DoQ), despliegue masivo del IoT. El documento de 2013 no cubría ninguno de estos temas.
La urgencia de esta revisión se refleja en las cifras. Según los informes de IDC e Infoblox, el 92 % de los malwares utilizan el DNS como canal de comunicación con sus servidores de comando (C2). Entre el 88 y el 90 % de las organizaciones sufrieron al menos un ataque dirigido a su infraestructura DNS. El coste medio por incidente supera los 1,1 millones de dólares. En 2024, la investigación Infoblox « Sitting Ducks » reveló más de 800 000 dominios vulnerables al secuestro, de los cuales 70 000 ya estaban comprometidos. Ese mismo año, la vulnerabilidad KeyTrap (CVE-2023-50387), un fallo en DNSSEC latente durante 24 años, demostró que los propios cimientos necesitaban un refuerzo.
El SP 800-81r3 abarca 52 páginas y reestructura completamente la doctrina en torno a los roles operativos DNS (resolvedor, servidor autoritativo, administrador de zona) en lugar de las familias de controles SP 800-53. Los autores: Scott Rose (NIST), Cricket Liu y Ross Gibson (Infoblox). Más allá del perímetro federal estadounidense, esta guía se convierte en una referencia internacional. La ENISA ya lo cita como documento de implementación para la directiva europea NIS2.
¿Tu dominio cumple las recomendaciones del NIST?
13 años de retraso: por qué esta revisión era urgente
El SP 800-81-2, publicado en septiembre de 2013, reflejaba un DNS todavía mayoritariamente en texto plano. DNSSEC existía pero seguía en fase incipiente. El concepto de DNS cifrado aún no tenía RFC. El Zero Trust era solo una idea académica. El IoT industrial no existía a la escala que conocemos hoy.
Desde 2013, el panorama cambió de forma radical. En 2016, el RFC 7858 estandarizó DNS over TLS (DoT). En 2018, el RFC 8484 introdujo DNS over HTTPS (DoH). En 2022, el RFC 9250 añadió DNS over QUIC (DoQ). En 2020, el propio NIST publicó el SP 800-207, la referencia de Zero Trust Architecture, sin actualizar nunca la guía DNS para integrar esa doctrina.
La evolución de los ataques hizo insostenible la obsolescencia. El ataque « Sitting Ducks », documentado por Infoblox en 2024, explota delegaciones DNS huérfanas para secuestrar dominios sin comprometer al registrar. De los 800 000 dominios identificados como vulnerables, 70 000 ya habían sido secuestrados por grupos cibercriminales (Vacant Viper, Horrid Hawk, Vextrio). Ese mismo año, la vulnerabilidad KeyTrap (CVE-2023-50387) demostró que un solo paquete DNS especialmente diseñado podía paralizar un resolvedor DNSSEC durante varias horas, un fallo presente en el protocolo desde 1999.
En cuanto a la adopción de DNSSEC, las cifras se estancan. Aproximadamente el 35 % de los dominios a nivel mundial están firmados. En Estados Unidos, solo el 37 % de los dominios .gov disponen de una validación DNSSEC completa. El SP 800-81-2 ya recomendaba DNSSEC, pero sin proporcionar una guía operativa suficiente para lograr un despliegue masivo.
Otro cambio estructural: la revisión 3 abandona la alineación con las familias de controles SP 800-53 (AC, SC, AU) para organizar el documento en torno a los roles operativos DNS. Esta decisión refleja la experiencia de los equipos de infraestructura: un administrador de zona no razona en términos de controles NIST, sino en términos de tareas diarias (firma de zona, rotación de claves, configuración de resolvedor).
Los 5 pilares del NIST SP 800-81r3
Protective DNS: el DNS como arma defensiva
El Protective DNS (PDNS) es la novedad más estructurante del SP 800-81r3. El concepto: transformar el resolvedor DNS en un punto de filtrado activo, alimentado por flujos de threat intelligence, para bloquear las resoluciones hacia dominios maliciosos en tiempo real.
El funcionamiento se basa en la integración de Response Policy Zones (RPZ), listas de bloqueo mantenidas por equipos de seguridad y bases de threat intelligence. Cuando un equipo de trabajo o un servidor intenta resolver un dominio identificado como malicioso (phishing, C2, exfiltración), el resolvedor PDNS intercepta la solicitud y devuelve una respuesta de bloqueo o redirige hacia una página de advertencia.
El SP 800-81r3 convierte el Protective DNS en una recomendación formal, y no simplemente una buena práctica. Este cambio de estatus tiene consecuencias directas para las agencias federales, que deberán justificar cualquier infraestructura DNS carente de capacidades PDNS.
Lo que está en juego es considerable: si el 92 % de los malwares se comunican con su infraestructura de comando mediante DNS, el PDNS corta ese canal antes incluso de que el malware pueda operar. El programa CISA Protective DNS ya está desplegado en varias agencias. Resolvedores públicos como Quad9 (9.9.9.9) integran capacidades PDNS de forma nativa. Las soluciones comerciales (Infoblox BloxOne Threat Defense, Cisco Umbrella, Akamai Enterprise Threat Protector) añaden capas de análisis comportamental y machine learning.
El SP 800-81r3 no prescribe una implementación específica. Exige que los resolvedores DNS de las organizaciones dispongan de una capacidad de filtrado basada en la reputación de dominios, con actualizaciones regulares de las fuentes de threat intelligence.
El cifrado de las consultas entra en la norma
El SP 800-81r3 oficializa la recomendación de utilizar protocolos DNS cifrados para el tráfico entre el stub resolver (cliente) y el resolvedor recursivo. Es un giro respecto a la revisión 2, que no cubría este tema en absoluto.
La Executive Order de enero de 2025 sobre el refuerzo de la ciberseguridad aceleró la formalización. Obliga a las agencias federales a desplegar DNS cifrado en un plazo de 180 días. El SP 800-81r3 proporciona el marco técnico para esta obligación.
Se cubren tres protocolos. DNS over TLS (DoT), definido por el RFC 7858, utiliza el puerto dedicado 853 y un canal TCP/TLS. Es el protocolo más maduro en el ámbito de la infraestructura. DNS over HTTPS (DoH), definido por el RFC 8484, transita por el puerto 443, mezclado con el tráfico HTTPS habitual. Está ampliamente desplegado en los navegadores (Firefox, Chrome, Edge). DNS over QUIC (DoQ), definido por el RFC 9250, combina las ventajas de TLS con el transporte QUIC: sin bloqueo de cabeza de fila (head-of-line blocking), reanudación 0-RTT, mejor gestión de la movilidad.
El SP 800-81r3 también aborda la tensión entre cifrado y visibilidad de red. El DNS cifrado impide la inspección del tráfico DNS por parte de los equipos de red tradicionales (firewall, IDS/IPS). El documento recomienda combinar DNS cifrado y Protective DNS: el cifrado protege la confidencialidad de las consultas en la red, mientras que el resolvedor PDNS conserva la visibilidad necesaria para el filtrado.
DNSSEC reforzado, no reemplazado
El SP 800-81r3 confirma que DNSSEC sigue siendo la base de la integridad DNS. El DNS cifrado protege la confidencialidad del transporte, pero solo DNSSEC garantiza la autenticidad e integridad de las respuestas. Ambas tecnologías son complementarias, no intercambiables. Cifrar una mentira no la convierte en verdad: sin DNSSEC, un resolver no puede distinguir una respuesta auténtica de una falsificada, ni siquiera a través de un canal cifrado.
La revisión 3 introduce tres avances para DNSSEC. El primero es la QNAME minimization (RFC 9156): en lugar de enviar el nombre de dominio completo a cada servidor autoritativo en la cadena de resolución, el resolvedor envía solo la parte necesaria para avanzar. Esto reduce las fugas de información hacia los servidores intermedios.
El segundo es el Compact Denial-of-Existence, una alternativa a NSEC3 para probar la inexistencia de un dominio. NSEC3 utiliza hashes para evitar la enumeración de zona, pero sigue siendo costoso en cálculo y ancho de banda. El Compact Denial-of-Existence simplifica el mecanismo conservando la protección contra la enumeración.
El tercero es la migración algorítmica. El SP 800-81r3 recomienda la transición hacia ECDSA P-256 (algoritmo 13) para las nuevas zonas y fomenta la depreciación progresiva de RSA. Las firmas ECDSA son más cortas (64 bytes frente a 256 para RSA-2048), lo que reduce el tamaño de las respuestas DNS y mitiga los riesgos de amplificación.
Las lecciones de KeyTrap están integradas. El documento subraya la importancia de las actualizaciones regulares de los resolvedores y de la vigilancia de los avisos de seguridad relacionados con DNSSEC. Para comprender en detalle el funcionamiento de la validación DNSSEC, consulta nuestra guía sobre la cadena de confianza DNSSEC.
Zero Trust: el DNS como punto de control
El SP 800-207 (Zero Trust Architecture), publicado en 2020, define los principios de « nunca confiar, siempre verificar ». El SP 800-81r3 integra el DNS en esta arquitectura posicionando el resolvedor como un Policy Enforcement Point (PEP).
En una arquitectura Zero Trust, cada solicitud de acceso se evalúa en función del contexto: identidad del usuario, estado del terminal, ubicación en la red, hora. El DNS interviene en la primera fase de la comunicación de red. Antes de que un terminal establezca una conexión TCP o TLS, resuelve un nombre de dominio. El resolvedor se convierte entonces en el primer punto donde se puede aplicar una política de acceso.
El SP 800-81r3 detalla cómo segmentar los resolvedores DNS por zonas de confianza. Los terminales de la red interna utilizan un resolvedor PDNS con políticas estrictas. Los terminales invitados o BYOD pasan por un resolvedor distinto, con restricciones adicionales. Los sistemas críticos (OT, SCADA) disponen de resolvedores dedicados, aislados de la red corporativa.
Las señales DNS también se explotan para alimentar los sistemas SIEM y SOAR. Un pico de resoluciones hacia dominios recién registrados (NRD), consultas DNS inusuales (tunneling, exfiltración vía registros TXT) o un cambio repentino en el patrón de resolución pueden activar alertas automatizadas.
OT/IoT: seguridad DNS en los límites de la red
Por primera vez, un documento SP 800-81 dedica una sección a los entornos de tecnología operativa (OT) y al Internet de las Cosas. El SP 800-81r3 es inequívoco: los equipos industriales y los dispositivos conectados son puntos ciegos DNS en la mayoría de las organizaciones.
Las limitaciones son reales. Muchos dispositivos IoT utilizan stub resolvers mínimos, incapaces de validar DNSSEC o negociar una conexión TLS. Los controladores industriales (SCADA, PLC) operan en redes segmentadas con ancho de banda limitado y actualizaciones de software poco frecuentes. Algunos equipos solo soportan DNS en texto plano sobre el puerto UDP 53.
El SP 800-81r3 recomienda un enfoque por capas. Dado que los propios dispositivos no pueden cifrar ni validar, la seguridad se traslada a la infraestructura: resolvedores PDNS dedicados para los segmentos OT/IoT, pasarelas DNS que realizan la validación DNSSEC en nombre de los clientes, y registro centralizado del tráfico DNS de estos segmentos para detectar comportamientos anómalos. El documento insiste en el aislamiento: un resolvedor OT nunca debe compartirse con la red corporativa.
Este pilar reconoce una realidad que las guías anteriores ignoraban: en un mundo donde un sensor de temperatura comprometido puede convertirse en el punto de entrada de un ransomware industrial, el DNS suele ser la única señal observable.
Logging y análisis forense DNS
Es la primera vez que un documento NIST de la serie SP 800-81 detalla los requisitos de registro de actividad DNS. La revisión 2 mencionaba el tema brevemente. La revisión 3 lo convierte en un pilar completo.
El SP 800-81r3 especifica lo que debe registrarse a nivel del resolvedor: cada consulta y cada respuesta, con los metadatos asociados. Como mínimo: marca temporal, dirección IP de origen, QNAME (nombre de dominio consultado), QTYPE (tipo de consulta: A, AAAA, MX, TXT), RCODE (código de respuesta: NOERROR, NXDOMAIN, SERVFAIL) e indicadores DNSSEC (AD flag, validation status).
El documento recomienda la integración directa de los logs DNS en un SIEM. Los casos de uso forenses son explícitos: rastrear la cadena de ataque a través de las resoluciones DNS (un ransomware siempre resuelve el dominio del C2 antes de descargar su payload), detectar la exfiltración de datos vía subdominios DNS (el DNS tunneling codifica datos en las consultas), identificar los dominios de staging utilizados antes de un ataque.
La retención de logs se aborda sin prescribir una duración fija. El SP 800-81r3 recomienda alinear la retención con la política de la organización y con los requisitos regulatorios aplicables (FISMA, NIS2, PCI DSS).
También se cubre el Passive DNS (pDNS). Consiste en recopilar las respuestas DNS observadas para construir un historial de resolución. Este historial permite detectar cambios sospechosos (un dominio legítimo que apunta de repente a una IP en un hosting bulletproof) y correlacionar indicadores de compromiso. Para implementar una vigilancia continua de tus registros DNS, consulta nuestra guía de monitorización DNS resiliente.
Qué ha cambiado respecto a la revisión 2
La siguiente tabla resume las diferencias entre el SP 800-81-2 (2013) y el SP 800-81r3 (2026).
| Tema | SP 800-81-2 (2013) | SP 800-81r3 (2026) |
|---|---|---|
| DNS cifrado | No cubierto | DoT, DoH, DoQ recomendados |
| Protective DNS | No cubierto | Recomendación formal |
| Zero Trust | Anterior al concepto | Integración SP 800-207 |
| DNSSEC | Guía básica | QNAME min., Compact DoE, migración algo |
| OT/IoT | No cubierto | Sección dedicada |
| Logging | Mención breve | Requisitos detallados, SIEM |
| Estructura | Alineado con SP 800-53 | Por roles operativos |
| Autores | Solo NIST | NIST + Infoblox |
Tres puntos merecen ser destacados. La coautoría con Infoblox es inédita para un SP 800-81: refleja la voluntad del NIST de anclar el documento en la realidad operativa en lugar de la teoría. La sección OT/IoT reconoce que los entornos industriales tienen restricciones específicas (resolvedores embebidos, ancho de banda limitado, imposibilidad de desplegar DNSSEC en ciertos equipos). La reestructuración por roles operativos facilita la lectura a los equipos de infraestructura, que pueden centrarse en las secciones que les conciernen directamente.
Impacto regulatorio: ¿a quién afecta?
Agencias federales estadounidenses
Para las agencias federales, el SP 800-81r3 es directamente aplicable en el marco del Federal Information Security Modernization Act (FISMA). Cada agencia debe alinear su postura DNS con las recomendaciones del documento en su próximo ciclo de evaluación.
La Executive Order de enero de 2025 refuerza esta obligación. Impone el despliegue del DNS cifrado en un plazo de 180 días para todas las agencias del poder ejecutivo. El SP 800-81r3 proporciona el marco técnico de referencia para cumplir con esta exigencia.
El impacto se extiende a los proveedores de cloud a través de FedRAMP. Todo proveedor de servicios cloud que busque una autorización FedRAMP deberá demostrar que su infraestructura DNS cumple las recomendaciones del SP 800-81r3. Esto afecta a AWS GovCloud, Azure Government, Google Cloud for Government y todos los proveedores SaaS que tratan datos federales.
La cadena de suministro también está en el punto de mira. Los subcontratistas y proveedores de las agencias federales deberán alinear su postura DNS para conservar sus contratos gubernamentales. El SP 800-81r3 se convertirá en un criterio de evaluación en las licitaciones federales.
Impacto de la directiva europea NIS2
La directiva NIS2, en vigor desde octubre de 2024, obliga a las entidades esenciales e importantes a implementar medidas de seguridad de red proporcionadas a los riesgos. El DNS está explícitamente cubierto por el perímetro de la directiva.
La ENISA (Agencia de la Unión Europea para la Ciberseguridad) cita el SP 800-81 como documento de implementación de referencia en sus guías técnicas. La publicación del SP 800-81r3 actualiza esa referencia. Las organizaciones sujetas a NIS2 podrán apoyarse en el SP 800-81r3 para documentar su postura DNS ante las autoridades nacionales.
Los sectores cubiertos por NIS2 son amplios: energía, transporte, sanidad, agua, infraestructura digital, servicios financieros, administración pública, espacio, alimentación, química, investigación. Cualquier organización de estos sectores que emplee más de 50 personas o facture más de 10 millones de euros está potencialmente dentro del perímetro.
Las sanciones NIS2 son disuasorias: hasta 10 millones de euros o el 2 % de la facturación mundial para las entidades esenciales, 7 millones de euros o el 1,4 % para las entidades importantes.
Organizaciones privadas
Las empresas fuera del perímetro federal o NIS2 no están directamente sujetas al SP 800-81r3. Pero el documento se impone como estándar de facto a través de varios mecanismos indirectos.
Las aseguradoras cibernéticas integran cada vez más la postura DNS en sus cuestionarios de suscripción. Una organización incapaz de demostrar capacidades PDNS, un despliegue DNSSEC o un registro de actividad DNS podría verse rechazada en la cobertura o enfrentar primas más elevadas.
La presión de la cadena de suministro también actúa. Si tus clientes son agencias federales o entidades NIS2, exigirán a sus proveedores una postura DNS alineada con el SP 800-81r3. Esta exigencia se propaga en cascada por toda la cadena de subcontratación.
La seguridad del email depende del DNS
SPF, DKIM y DMARC son registros DNS. Un resolvedor que valida la dirección IP de un remitente contra un registro SPF se apoya en la integridad de la respuesta DNS. Si un atacante envenena la caché del resolvedor y sustituye un registro SPF falsificado, toda la cadena de autenticación del email se derrumba.
DNSSEC protege contra este escenario. Al firmar los registros MX, SPF (TXT), DKIM (TXT) y DMARC (TXT), DNSSEC garantiza que el resolvedor valida datos auténticos. Sin DNSSEC, un atacante capaz de realizar un cache poisoning puede usurpar la identidad de email de un dominio, eludir las políticas DMARC y enviar correos fraudulentos en nombre de la organización objetivo.
El SP 800-81r3 subraya esta dependencia. Recomienda considerar la seguridad del email y la seguridad DNS como un conjunto inseparable. Desplegar DMARC con una política p=reject sin activar DNSSEC equivale a cerrar con llave la puerta principal dejando la ventana abierta.
DANE (DNS-based Authentication of Named Entities) va más allá. A través de registros TLSA protegidos por DNSSEC, DANE permite autenticar el certificado TLS del servidor de correo destinatario. Esto elimina la dependencia de autoridades de certificación externas y garantiza el cifrado de extremo a extremo del transporte SMTP.
MTA-STS constituye una alternativa cuando DNSSEC aún no está desplegado en el dominio. Utiliza HTTPS para publicar una política de transporte seguro. El SP 800-81r3 recomienda ambos enfoques, con preferencia por DANE cuando DNSSEC está disponible.
Verifica ahora mismo que tus registros de autenticación de email están correctamente configurados con nuestro DMARC Checker.
Plan de acción: 6 pasos para cumplir
1. Auditar la infraestructura DNS existente. Empieza con un inventario completo de tus zonas DNS, servidores autoritativos y resolvedores. Identifica las zonas sin firmar, los resolvedores sin capacidad de validación DNSSEC y los flujos DNS en texto plano. CaptainDNS puede automatizar esta verificación.
2. Desplegar DNSSEC en todas las zonas. Firma cada zona con DNSSEC dando prioridad al algoritmo ECDSA P-256 (algoritmo 13). Verifica que los DS records se propagan correctamente al TLD. Planifica una rotación regular de claves (ZSK cada 3 meses, KSK cada 12 a 24 meses). Consulta nuestra guía paso a paso para activar DNSSEC para un despliegue sin interrupción de servicio.
3. Activar el DNS cifrado. Despliega DoT en tus resolvedores internos para proteger el tráfico de los equipos de trabajo. Para los trabajadores remotos, configura DoH para que las consultas DNS transiten por el puerto 443, compatible con la mayoría de redes públicas. Prueba DoQ si tu resolvedor lo soporta, especialmente para entornos de alta latencia.
4. Implementar el Protective DNS. Evalúa las soluciones PDNS adecuadas a tu tamaño: Quad9 como resolvedor público con filtrado, RPZ en un resolvedor interno (BIND, Unbound, PowerDNS Recursor) o una solución comercial para organizaciones más grandes. Configura flujos de threat intelligence y define una política de bloqueo (NXDOMAIN, redirección a página informativa o solo registro en modo observación).
5. Centralizar los logs DNS. Configura el registro de actividad en cada resolvedor y servidor autoritativo. Exporta los logs hacia tu SIEM (Splunk, Elastic, Microsoft Sentinel) con los campos mínimos recomendados por el SP 800-81r3: marca temporal, IP de origen, QNAME, QTYPE, RCODE, indicadores DNSSEC. Define reglas de correlación para detectar DNS tunneling, resoluciones hacia dominios NRD y picos de errores SERVFAIL.
6. Asegurar la cadena de email. Valida que tus registros SPF, DKIM y DMARC estén correctamente publicados y protegidos por DNSSEC. Despliega DANE (TLSA) en tus servidores de correo si tu proveedor DNS soporta DNSSEC. Configura MTA-STS como medida complementaria. Activa TLS-RPT para recibir informes sobre fallos de negociación TLS.
FAQ
¿Qué es el NIST SP 800-81r3?
El NIST SP 800-81r3 es la tercera revisión de la guía federal estadounidense « Secure Domain Name System (DNS) Deployment Guide ». Publicado el 19 de marzo de 2026 por el National Institute of Standards and Technology, reemplaza la revisión 2 de 2013. El documento cubre la protección del DNS en todos sus aspectos: DNSSEC, DNS cifrado (DoT, DoH, DoQ), Protective DNS, integración Zero Trust, registro de actividad y entornos OT/IoT.
¿Es obligatorio el SP 800-81r3?
Es obligatorio para las agencias federales estadounidenses en el marco de FISMA y la Executive Order de enero de 2025 sobre ciberseguridad. Para las organizaciones europeas, sirve como referencia de implementación en el contexto de la directiva NIS2. Para las empresas privadas, constituye un estándar de facto, cada vez más exigido por las aseguradoras cibernéticas y los contratantes sujetos a obligaciones regulatorias.
¿Qué es el Protective DNS?
El Protective DNS (PDNS) es un resolvedor DNS enriquecido con capacidades de filtrado basadas en threat intelligence. Bloquea en tiempo real las resoluciones hacia dominios identificados como maliciosos (phishing, comando y control de malware, exfiltración de datos). El mecanismo se apoya en Response Policy Zones (RPZ) y flujos de inteligencia de amenazas actualizados de forma continua.
¿Cuál es la diferencia entre DoT, DoH y DoQ?
DNS over TLS (DoT) utiliza un canal TCP/TLS dedicado en el puerto 853. DNS over HTTPS (DoH) encapsula las consultas DNS en tráfico HTTPS en el puerto 443. DNS over QUIC (DoQ) utiliza el protocolo QUIC directamente, combinando cifrado TLS y transporte sin bloqueo de cabeza de fila. DoT es el más maduro en infraestructura, DoH el más extendido en navegadores, DoQ el más eficiente en entornos de latencia variable.
¿Sigue recomendándose DNSSEC en 2026?
Sí. El SP 800-81r3 reafirma DNSSEC como la única tecnología que garantiza la autenticidad e integridad de las respuestas DNS. El DNS cifrado (DoT, DoH, DoQ) protege la confidencialidad del transporte, pero no verifica que la respuesta provenga del servidor autoritativo legítimo. Ambas tecnologías son complementarias. El SP 800-81r3 añade recomendaciones sobre QNAME minimization, Compact Denial-of-Existence y la migración al algoritmo ECDSA P-256.
¿Cuál es la relación entre DNS y seguridad del email?
SPF, DKIM y DMARC son registros DNS. La validación de un email se basa en la consulta de estos registros por parte del servidor destinatario. Sin DNSSEC, un atacante puede envenenar la caché DNS y sustituir registros falsificados, eludiendo así toda la cadena de autenticación del email. El SP 800-81r3 recomienda tratar la seguridad DNS y la seguridad del email como un conjunto inseparable.
¿Cuánto tiempo se necesita para cumplir?
La duración depende de la madurez existente. Una organización que ya dispone de DNSSEC y un resolvedor centralizado puede cumplir en 3 a 6 meses. Una organización que parte de cero necesitará de 6 a 12 meses para un despliegue completo que cubra DNSSEC, DNS cifrado, Protective DNS y registro de actividad. La Executive Order de enero de 2025 impone un plazo de 180 días para el DNS cifrado en las agencias federales.
¿Se aplica el SP 800-81r3 a las pymes?
El SP 800-81r3 se dirige a las agencias federales estadounidenses, pero sus recomendaciones son pertinentes para cualquier organización. Las pymes europeas sujetas a NIS2 (más de 50 empleados o 10 millones de euros de facturación en los sectores cubiertos) deben documentar su postura DNS. Las pymes fuera del perímetro regulatorio se benefician igualmente de un marco estructurado para priorizar sus inversiones en seguridad DNS.
Glosario
- NIST: National Institute of Standards and Technology. Agencia federal estadounidense que publica los estándares y guías de seguridad informática de referencia para el gobierno federal.
- SP 800-81: Special Publication 800-81, guía del NIST dedicada al despliegue seguro del DNS. La revisión 3 (r3) es la versión publicada el 19 de marzo de 2026.
- DNSSEC: Domain Name System Security Extensions. Conjunto de extensiones que añaden firmas criptográficas a las respuestas DNS para garantizar su autenticidad e integridad.
- DoT (DNS over TLS): protocolo de cifrado DNS definido por el RFC 7858. Utiliza un canal TLS dedicado en el puerto TCP 853 entre el cliente y el resolvedor.
- DoH (DNS over HTTPS): protocolo de cifrado DNS definido por el RFC 8484. Encapsula las consultas DNS en tráfico HTTPS en el puerto 443.
- DoQ (DNS over QUIC): protocolo de cifrado DNS definido por el RFC 9250. Utiliza el transporte QUIC para combinar cifrado y rendimiento (sin head-of-line blocking, reanudación 0-RTT).
- Protective DNS (PDNS): resolvedor DNS enriquecido con capacidades de filtrado en tiempo real. Bloquea las resoluciones hacia dominios maliciosos apoyándose en flujos de threat intelligence.
- RPZ (Response Policy Zone): mecanismo DNS que permite definir políticas de respuesta personalizadas. Utilizado por los resolvedores PDNS para bloquear o redirigir consultas hacia dominios maliciosos.
- QNAME minimization: técnica (RFC 9156) que reduce la cantidad de información transmitida a los servidores autoritativos intermedios durante la resolución. Solo se envía la parte del nombre necesaria para avanzar en la resolución.
- Zero Trust: modelo de seguridad basado en el principio « nunca confiar, siempre verificar ». El SP 800-207 del NIST define la arquitectura de referencia.
- NIS2: directiva europea (2022/2555) sobre la seguridad de las redes y la información. En vigor desde octubre de 2024, impone obligaciones de ciberseguridad a las entidades esenciales e importantes.
- FISMA: Federal Information Security Modernization Act. Ley estadounidense que obliga a las agencias federales a implementar programas de seguridad conformes a los estándares NIST.
