Gobierno de DNS en 2026: controles del registrador preparados para auditoría
A las 07:42 de un lunes por la mañana, el Director de Seguridad de la Información de una scale-up fintech recibe el mensaje que nadie quiere ver. Los clientes no pueden acceder al portal de pagos, el centro de soporte está saturado, el correo electrónico falla y el Centro de Operaciones de Seguridad (SOC) no ha encontrado malware, ni indisponibilidad del cortafuegos, ni incidente del proveedor de servicios en la nube.
La causa raíz es más silenciosa y más incómoda. Se accedió a una cuenta del registrador utilizando una credencial administrativa obsoleta compartida por varios antiguos miembros del equipo de TI. El atacante cambió los servidores de nombres autoritativos, modificó los registros MX, deshabilitó DNSSEC y redirigió el tráfico el tiempo suficiente para capturar credenciales e interrumpir API de socios. El portal de pagos no fue comprometido en el sentido tradicional. Lo fue el ancla de confianza de la empresa: su dominio.
A las 09:30, la crisis operativa se ha convertido en una crisis de cumplimiento. El consejo de administración pregunta si estaba habilitado el bloqueo a nivel de registro. El área jurídica pregunta si se expusieron datos personales. El Delegado de Protección de Datos (DPD) pregunta si se trata de una brecha de datos personales conforme al RGPD de la UE. El regulador quiere saber si se vio afectada una función crítica o importante. Un auditor de un cliente solicita el ticket de cambio que aprobó la modificación de DNS.
La respuesta, en demasiadas organizaciones, es una hoja de cálculo, un buzón compartido y una consola del registrador que nadie ha revisado en seis meses.
El gobierno de DNS y de los registradores de dominios en 2026 ya no es un asunto técnico de infraestructura de nicho. Forma parte de la resiliencia frente al ransomware, la prevención del phishing, la disponibilidad de la nube, la gestión de riesgos de proveedores, la respuesta a incidentes, la continuidad del negocio y el cumplimiento basado en evidencias. Si tu dominio puede ser secuestrado, tu plataforma SaaS puede desaparecer. Si tus registros DNS pueden alterarse sin aprobación, la seguridad del correo electrónico, el SSO, los certificados TLS, los endpoints de API y la confianza de los clientes pueden quedar comprometidos en cuestión de minutos.
Por qué el gobierno de DNS y del registrador debe formar parte del SGSI
Un nombre de dominio no es solo un activo de marca. Es un activo lógico, una dependencia de autenticación, una dependencia de enrutamiento y, con frecuencia, un servicio gestionado por un proveedor. Conecta proveedores de identidad, autenticación del correo electrónico, validación de certificados TLS, endpoints en la nube, portales de clientes, API, servicios CDN, sondas de supervisión y comunicaciones de incidentes.
La Política de Gestión de Activos - pyme de Clarysec Política de Gestión de Activos - pyme lo explicita en su alcance:
Credenciales y servicios digitales: nombres de dominio, certificados digitales, claves de API, cuentas de correo electrónico, accesos a servicios en la nube
De la sección “Alcance”, cláusula 2.2.4 de la política.
La misma política exige algo más que listar el nombre de dominio:
Deben documentarse la titularidad, el propósito, los privilegios de acceso y los plazos de renovación.
De la sección “Requisitos de implementación de la política”, cláusula 6.6.2 de la política.
Para entornos empresariales, la Política de Gestión de Activos de Clarysec Política de Gestión de Activos también incluye los activos lógicos en el alcance:
Activos lógicos: nombres de dominio, licencias, cuentas de usuario, configuraciones de referencia
De la sección “Alcance”, cláusula 2.2.5 de la política.
Ese es el punto de partida del gobierno. Un inventario de DNS y del registrador debe documentar:
- Nombre de dominio, registro, registrador, proveedor de alojamiento DNS y servidores de nombres autoritativos
- Propietario de negocio, propietario técnico, propietario de seguridad y aprobador de emergencia
- Propósito, como portal de producción, API, correo electrónico, SSO, marketing, entorno de prueba o registro defensivo
- Clasificación de criticidad y mapeo de dependencias con los servicios de la organización
- Estado de DNSSEC, estado del registro DS, titularidad de claves y proceso de rotación de claves
- Estado del bloqueo a nivel de registro y del bloqueo del registrador
- Autenticación multifactor (MFA) y modelo de acceso privilegiado para cuentas del registrador y del proveedor de DNS
- Fecha de renovación, estado de renovación automática, responsable del pago y destinatarios de alertas de caducidad
- Requisitos de control de cambios para ediciones de zona y cambios de delegación
- Registro de eventos, alertas, supervisión y conservación de evidencias
Por este motivo, el gobierno de dominios debe figurar en el alcance del SGSI y en la evaluación de riesgos de ISO/IEC 27001:2022. ISO/IEC 27001:2022 exige que las organizaciones determinen el contexto, los requisitos de las partes interesadas, las obligaciones legales y contractuales, y las interfaces y dependencias con organizaciones externas. DNS depende de registradores, registros, proveedores de alojamiento DNS, proveedores de servicios en la nube, autoridades de certificación, proveedores de servicios gestionados y, a veces, agencias de marketing. Si esas interfaces quedan fuera del SGSI, la pista de auditoría estará incompleta.
El modelo de amenazas de DNS en 2026
Los fallos de DNS más dañinos suelen ser simples:
- Un dominio caduca porque la responsabilidad de la renovación no estaba clara.
- Una antigua agencia aún tiene acceso a una cuenta del registrador.
- DNSSEC está habilitado, pero los registros DS son incorrectos tras una migración de proveedor DNS.
- Un registro comodín dirige el tráfico a un servicio en la nube abandonado.
- Se modifica un registro TXT para validar un tenant SaaS o una solicitud de certificado controlados por un atacante.
- Se modifican registros MX durante una campaña de phishing o de interceptación de correo electrónico.
- Un CNAME hacia una plataforma de terceros queda expuesto a una toma de control.
- Existe bloqueo a nivel de registro para el dominio principal, pero no para dominios de código de país orientados al cliente.
- El SOC supervisa endpoints, pero nadie supervisa los cambios en el archivo de zona.
Las salvaguardas técnicas son conocidas. DNSSEC ayuda a proteger la integridad de los datos DNS y la autenticación del origen. El bloqueo a nivel de registro hace que los cambios de alto riesgo en el nivel del registro requieran una verificación adicional fuera de banda. El bloqueo del registrador reduce el riesgo de transferencia no autorizada. La MFA y las revisiones de acceso privilegiado reducen la probabilidad de compromiso de cuenta. El control de cambios evita interrupciones accidentales. La supervisión detecta cambios no autorizados o inesperados.
El reto de cumplimiento es distinto: ¿puedes demostrar que esas salvaguardas existen, tienen propietario, se revisan y funcionan durante un incidente?
Esa pregunta sobre evidencias es donde muchas organizaciones fallan.
Mapeo del gobierno de DNS con ISO/IEC 27001:2022 e ISO/IEC 27002:2022
ISO/IEC 27001:2022 proporciona la estructura del sistema de gestión para convertir los controles de DNS en procesos repetibles y auditables. El Anexo A de ISO/IEC 27001:2022 y la guía de controles de ISO/IEC 27002:2022 aportan el lenguaje de control que esperan los auditores.
| Área de gobierno de DNS | Tema de evidencia en ISO/IEC 27001:2022 Anexo A e ISO/IEC 27002:2022 | Qué esperan ver los auditores |
|---|---|---|
| Inventario de dominios | 5.9 Inventario de información y otros activos asociados | Registro de dominios con propietarios, criticidad, fechas de renovación, proveedor de DNS, registrador y dependencias |
| Acceso al registrador | 5.15 Control de acceso, 5.16 Gestión de identidades, 5.18 Derechos de acceso, 8.5 Autenticación segura | Usuarios nominales, evidencias de MFA, registros de aprobación, revisiones periódicas de derechos de acceso y proceso de acceso de emergencia |
| DNSSEC | 8.24 Uso de criptografía | Estado de DNSSEC, registros DS, custodia de claves, plan de rotación y supervisión de validación |
| Bloqueo a nivel de registro y bloqueo del registrador | 5.15 Control de acceso, 8.20 Seguridad de redes, 8.21 Seguridad de los servicios de red, 8.32 Gestión de cambios | Estado de bloqueo, procedimiento de desbloqueo, contactos autorizados y proceso de verificación fuera de banda |
| Control de cambios de zona | 8.9 Gestión de configuraciones, 8.32 Gestión de cambios | Tickets de cambio, evaluación de riesgos, aprobaciones, evidencias de implementación y plan de reversión |
| Gobierno del proveedor de DNS | 5.19 Seguridad de la información en las relaciones con proveedores, 5.20 Tratamiento de la seguridad de la información en los acuerdos con proveedores, 5.22 Supervisión, revisión y gestión de cambios de los servicios de proveedores | Cláusulas contractuales, SLA, responsabilidades de seguridad, revisiones del servicio y expectativas de notificación de incidentes |
| Registro de eventos y supervisión de DNS | 8.15 Registro de eventos, 8.16 Actividades de supervisión | Registros, alertas, ingesta en SIEM, conservación y evidencias de prueba de alertas |
| Respuesta ante indisponibilidad de DNS | 5.24 Planificación y preparación de la gestión de incidentes de seguridad de la información, 5.29 Seguridad de la información durante interrupciones, 5.30 Preparación de las TIC para la continuidad del negocio | Procedimientos operativos, lista de escalado, procedimientos de recuperación y lecciones aprendidas posteriores al incidente |
El Zenith Blueprint: hoja de ruta de 30 pasos para auditores de Clarysec Zenith Blueprint trata los servicios de red como objetos explícitos de auditoría. En la fase Controles en acción, paso 20, indica a los equipos que validen la seguridad de los servicios de red:
Enumera todos los servicios de red internos y externos (DNS, VPN, SMTP, DHCP, pasarelas de API, etc.).
✓ Para cada uno, confirma que utilizan protocolos seguros (por ejemplo, DNSSEC, TLS 1.2+, SSH en lugar de Telnet). ✓ Revisa cómo se controla el acceso a cada servicio (por ejemplo, listas blancas de IP, autenticación, certificados). ✓ Si son gestionados por terceros (por ejemplo, DNS, SD-WAN, VPN alojada), revisa las cláusulas de seguridad del SLA o del contrato con el proveedor. Actualiza tu Registro de Servicios y señala dónde residen las responsabilidades de seguridad, si son internas o externas.
De la fase Controles en acción, paso 20: controles 8.18 a 8.26.
Esto proporciona una ruta práctica de auditoría: tratar DNS como un servicio de red externo, documentar cómo se protege y registrar si la responsabilidad reside internamente, en un registrador, en un proveedor de DNS o en un proveedor de servicios gestionados.
El Zenith Controls: guía de cumplimiento cruzado de Clarysec Zenith Controls es útil porque el gobierno de DNS rara vez se asigna a un único marco. La misma decisión sobre DNSSEC o bloqueo a nivel de registro respalda evidencias para ISO/IEC 27001:2022, NIS2, DORA, el RGPD de la UE, NIST CSF 2.0 y COBIT 2019.
Para la supervisión de proveedores, Zenith Controls mapea el control 5.22 de ISO/IEC 27002:2022, Supervisión, revisión y gestión de cambios de los servicios de proveedores, como un control preventivo que respalda la confidencialidad, la integridad y la disponibilidad. Para DNS, esto significa que tu registrador y tu proveedor de DNS no son proveedores que se configuran y se olvidan. Deben revisarse su postura de seguridad, cambios de servicio, indisponibilidades, subencargados y prácticas de notificación.
Para DNSSEC y la integridad criptográfica, Zenith Controls mapea el control 8.24 de ISO/IEC 27002:2022, Uso de criptografía, como un control preventivo alineado con la configuración segura. DNSSEC no cifra el tráfico DNS, pero proporciona aseguramiento criptográfico de la integridad de los datos DNS y de la autenticación del origen.
Para las ediciones de zona DNS, Zenith Controls mapea el control 8.32 de ISO/IEC 27002:2022, Gestión de cambios, como un control preventivo que respalda la confidencialidad, la integridad y la disponibilidad. Un cambio de DNS es un cambio de configuración. Una actualización de registro DS, un cambio de registro MX, una migración CNAME, una actualización SPF o DMARC, una conmutación de CDN o un cambio de delegación de servidores de nombres debe contar con ticket, evaluación de riesgos, aprobación, resultado de prueba y plan de reversión.
DNSSEC, bloqueo a nivel de registro y gestión de claves para dominios críticos
No todos los dominios tienen el mismo riesgo. Un dominio defensivo utilizado solo para prevenir la suplantación puede necesitar supervisión y disciplina de renovación. Un dominio principal de portal de clientes requiere los controles más robustos disponibles.
Para dominios críticos, Clarysec suele recomendar esta configuración de referencia:
- DNSSEC habilitado y validado cuando lo permitan el registro, el registrador y el proveedor de DNS
- Registros DS revisados después de cualquier migración de proveedor DNS
- Proceso documentado de rotación de KSK y ZSK, cuando las claves sean gestionadas por el cliente
- Bloqueo a nivel de registro habilitado para dominios principales de producción, identidad, API, pagos y correo electrónico
- Bloqueo del registrador habilitado para todos los dominios, salvo que exista una excepción temporal documentada
- MFA exigida para todos los usuarios del registrador y del proveedor de DNS
- Usuarios privilegiados restringidos, nominales, aprobados y revisados
- Acceso de emergencia controlado documentado y probado
- Supervisión del archivo de zona con alertas sobre cambios en NS, DS, DNSKEY, MX, TXT, A, AAAA, CNAME, CAA y comodines
- Supervisión externa desde múltiples resolvedores y regiones
- Evidencias conservadas en el repositorio del SGSI
La Política de Controles Criptográficos empresarial de Clarysec Política de Controles Criptográficos proporciona el anclaje de gobierno para las claves DNSSEC:
Debe mantenerse un Registro de Gestión de Claves centralizado para registrar todas las claves criptográficas, su estado de ciclo de vida, los custodios asignados y los contextos de uso.
De la sección “Requisitos de gobernanza”, cláusula 5.2 de la política.
Si tu organización gestiona directamente las claves DNSSEC, o controla la publicación DS en el registrador, el Registro de Gestión de Claves debe documentar la custodia, el estado del ciclo de vida, las fechas de rotación y la autoridad de aprobación. Si el proveedor de DNS gestiona las claves DNSSEC, el registro del proveedor debe explicar esa responsabilidad e incluir evidencias de aseguramiento.
Gobierno del acceso al registrador: MFA, mínimo privilegio y control de emergencia
Las cuentas del registrador suelen crearse en las primeras etapas de vida de una empresa y después se olvidan a medida que la organización madura. Fundadores, agencias, desarrolladores, usuarios financieros y proveedores de servicios gestionados pueden conservar accesos históricos. Esto constituye una debilidad de control significativa.
La Política de gestión de cuentas de usuario y privilegios - pyme de Clarysec Política de gestión de cuentas de usuario y privilegios - pyme establece:
Los privilegios elevados o administrativos requieren aprobación adicional del Director General o del responsable de TI y deben estar documentados, limitados en el tiempo y sujetos a revisión periódica.
De la sección “Requisitos de implementación de la política”, cláusula 6.2.2 de la política.
Aplica esto literalmente al acceso al registrador y al proveedor de DNS:
- Sin cuentas de administrador del registrador compartidas
- MFA para cada usuario, preferiblemente resistente al phishing cuando esté disponible
- Contactos de emergencia nominales con autoridad documentada
- Separación de usuarios de facturación y administradores técnicos cuando sea posible
- Retirada inmediata de antiguos empleados, agencias y proveedores
- Revisión trimestral del acceso privilegiado para dominios críticos
- Excepciones registradas con fechas de caducidad
- Procedimientos de desbloqueo y recuperación de emergencia probados que no generen cambios inseguros en producción
Las evidencias del bloqueo a nivel de registro deben incluir capturas de pantalla o atestaciones del registrador que muestren el estado habilitado, los contactos autorizados, el proceso de desbloqueo y la fecha de la última revisión.
Control de cambios de zona: pequeñas ediciones de DNS, gran impacto en la organización
Los cambios de DNS son engañosamente pequeños. Un registro TXT puede validar la titularidad de una plataforma SaaS. Un CNAME puede redirigir clientes a un nuevo entorno. Un registro MX puede redirigir el correo. Un registro CAA puede influir en la emisión de certificados. Un registro DS incorrecto puede provocar que un dominio firmado falle la validación.
La Política de gestión de cambios - pyme de Clarysec Política de gestión de cambios - pyme establece:
Todos los cambios deben presentarse como una Solicitud de Cambio (correo electrónico, formulario o ticket de mesa de ayuda).
De la sección “Requisitos de gobernanza”, cláusula 5.1.1 de la política.
Para clientes empresariales, la Política de gestión de cambios de Clarysec Política de gestión de cambios eleva la expectativa de evidencias:
Todas las solicitudes de cambio, revisiones, aprobaciones y evidencias de soporte deben registrarse en el Sistema de Gestión de Cambios centralizado.
De la sección “Requisitos de implementación de la política”, cláusula 6.1.1 de la política.
El Zenith Blueprint refuerza esto en la fase Controles en acción, paso 21:
Selecciona 2 o 3 cambios recientes de sistemas o de configuración y comprueba si se procesaron mediante tu flujo formal de aprobación de cambios.
✓ ¿Se evaluaron los riesgos? ✓ ¿Se documentaron las aprobaciones? ✓ ¿Se incluyó un plan de reversión?
Valida que los cambios se implementaron según lo previsto y que se registraron los incidentes o impactos inesperados. Revisa registros, diferencias de control de versiones o pistas de auditoría de herramientas como ServiceNow, Jira o Git. Captura este proceso en un registro resumen de cambios como referencia de auditoría.
De la fase Controles en acción, paso 21: controles 8.27 a 8.34.
Un ticket de cambio específico de DNS debe incluir el dominio y la zona afectados, el tipo de registro, los valores antes y después, la justificación de negocio, la evaluación de riesgos, la ventana de implementación, el aprobador, el implementador, el verificador, las comprobaciones de propagación DNS, la validación DNSSEC, el plan de reversión, la supervisión posterior al cambio y las evidencias exportadas.
El principio de auditoría es sencillo: los cambios de DNS deben ser trazables desde la solicitud hasta la aprobación, la implementación y la verificación.
Supervisión y registro de eventos: detecta el cambio de DNS antes que los clientes
Un programa sólido de gobierno de DNS asume que la prevención puede fallar. La supervisión debe detectar los cambios inesperados con la rapidez suficiente para respaldar la respuesta a incidentes.
La Política de Seguridad de Redes - pyme de Clarysec Política de Seguridad de Redes - pyme es explícita:
El registro de eventos DNS debe estar habilitado para respaldar la búsqueda proactiva de amenazas y la respuesta a incidentes
De la sección “Requisitos de implementación de la política”, cláusula 6.6.3 de la política.
La Política de registro y supervisión empresarial Política de registro y supervisión parte de la misma expectativa operativa:
Todos los sistemas cubiertos deben generar registros que capturen:
De la sección “Requisitos de implementación de la política”, cláusula 6.1.1 de la política.
Para el gobierno de DNS y del registrador, los sistemas cubiertos deben incluir portales de registrador, consolas de alojamiento DNS, gestión de DNS basada en API, canalizaciones de CI/CD que despliegan DNS como código, alertas SIEM y herramientas externas de supervisión.
| Evento | Por qué importa | Evidencia mínima |
|---|---|---|
| Cambio de registro NS | Puede redirigir todo el dominio a DNS controlado por un atacante | Alerta, ticket, aprobador y valores antes/después |
| Cambio de DS o DNSKEY | Puede romper la validación DNSSEC o habilitar ataques contra la integridad | Informe de validación DNSSEC y registro de cambio |
| Cambio de MX | Puede redirigir el correo y facilitar phishing o interceptación de datos | Alerta, prueba de flujo de correo y aprobación |
| Cambio de TXT | Puede validar titularidad SaaS, autenticación de correo electrónico o emisión de certificados | Ticket de cambio, solicitante y justificación de negocio |
| Cambio de CAA | Puede influir en los controles de emisión de certificados | Revisión de gobierno de certificados |
| Adición de registro comodín | Puede crear riesgo amplio de enrutamiento o de toma de control | Evaluación de riesgos y aprobación |
| Inicio de sesión del registrador desde una ubicación inusual | Indica riesgo de compromiso de cuenta | Alerta SIEM y nota de investigación |
| Solicitud de desbloqueo del bloqueo a nivel de registro | Cambio de alto riesgo que requiere escalado | Aprobación de emergencia y revisión posterior a la acción |
La supervisión debe integrarse en la respuesta a incidentes. Una alerta DNS sin propietario, clasificación de severidad o procedimiento operativo es solo ruido.
NIS2, DORA y RGPD de la UE: el gobierno de DNS como evidencia regulatoria
NIS2 Article 21 exige medidas técnicas, operativas y organizativas adecuadas y proporcionadas para gestionar los riesgos de los sistemas de redes y de información y minimizar el impacto de los incidentes. El gobierno de DNS se mapea de forma natural con la gestión de activos, el control de acceso, la criptografía, la seguridad de la cadena de suministro, la gestión de incidentes, la continuidad del negocio y la evaluación de eficacia.
NIS2 Article 20 también convierte la ciberseguridad en una responsabilidad del órgano de dirección. Los consejos de administración no necesitan aprobar cada registro TXT, pero deben entender si los dominios críticos están protegidos con DNSSEC, bloqueo a nivel de registro, MFA, supervisión y recuperación probada. Para incidentes significativos, NIS2 Article 23 introduce una notificación por fases, incluida una alerta temprana en 24 horas, una notificación de incidente en 72 horas y un informe final no más tarde de un mes tras la notificación del incidente.
Para entidades financieras reguladas, DORA se aplica desde el 17 de enero de 2025 y opera como el marco sectorial específico de resiliencia de las TIC cuando se solapa con NIS2. DNS suele respaldar funciones críticas o importantes como aplicaciones de pago, banca móvil, portales de negociación, identidad de clientes, sistemas antifraude, pasarelas de API e integraciones con terceros. Las evidencias de DORA deben mostrar mapeo de dependencias de activos TIC, clasificación de incidentes, pruebas de resiliencia, gestión de riesgos de terceros y planificación de recuperación para escenarios de fallo de DNS y del registrador.
Un incidente DNS no es automáticamente una brecha de datos personales conforme al RGPD de la UE. Puede convertirse en una si los usuarios son redirigidos a un sitio de phishing, se capturan credenciales, se redirige correo electrónico que contiene datos personales, se intercepta tráfico hacia sistemas de tratamiento de datos personales o la disponibilidad de datos personales se ve materialmente afectada. El RGPD de la UE Article 5 exige integridad, confidencialidad y responsabilidad proactiva. Article 32 exige medidas de seguridad adecuadas para el tratamiento. El gobierno de DNS proporciona evidencias de que el enrutamiento de dominios y los servicios dependientes de DNS están protegidos con medidas técnicas y organizativas proporcionadas.
| Medida de control | ISO/IEC 27001:2022 Anexo A e ISO/IEC 27002:2022 | NIS2 | DORA | RGPD de la UE |
|---|---|---|---|---|
| Inventario de activos de dominio | 5.9 Inventario de información y otros activos asociados | Article 21(2)(i) | Article 8 | Articles 5 and 32 |
| Registrador como proveedor | 5.19, 5.20, 5.22 | Article 21(2)(d) | Chapter V | Article 28 and Article 32 |
| Control de acceso al registrador y MFA | 5.15, 5.16, 5.18, 8.5 | Article 21(2)(i) and 21(2)(j) | Article 9 | Article 32 |
| Bloqueo a nivel de registro y bloqueo del registrador | 5.15, 8.20, 8.21, 8.32 | Article 21(2)(a) and 21(2)(e) | Articles 9, 10 and 11 | Article 32 |
| Control de cambios de zona DNS | 8.9, 8.32 | Article 21(2)(a) and 21(2)(e) | Articles 9, 10 and 11 | Articles 5 and 32 |
| Implementación de DNSSEC | 8.24 Uso de criptografía | Article 21(2)(h) | Articles 9 and 10 | Article 32 |
| Registro de eventos y supervisión de DNS | 8.15 Registro de eventos, 8.16 Actividades de supervisión | Article 21(2)(a), 21(2)(b) and 21(2)(f) | Articles 10 and 17 | Articles 5, 32 and 33 |
Construir un paquete de evidencias DNS en una semana
Un plan práctico de remediación del gobierno de DNS puede completarse rápidamente si se orienta a evidencias.
Día 1: Crear el registro de dominios y servicios DNS
Parte del requisito de la Política de Gestión de Activos - pyme de documentar titularidad, propósito, privilegios de acceso y plazos de renovación.
| Campo | Ejemplo |
|---|---|
| Dominio | example.com |
| Propósito de negocio | Portal de clientes, API, correo electrónico |
| Criticidad | Crítico |
| Registrador | Registrador A |
| Bloqueo a nivel de registro | Habilitado |
| Bloqueo del registrador | Habilitado |
| Proveedor de DNS | Proveedor B de DNS gestionado |
| DNSSEC | Habilitado, DS publicado |
| Propietario | Responsable de Plataforma |
| Propietario de seguridad | CISO |
| Fecha de renovación | 2027-04-12 |
| Supervisión | Alerta SIEM más monitor DNS externo |
| Flujo de cambio | Tipo de cambio DNS en Jira |
| Fecha de revisión del proveedor | 2026-03-15 |
Día 2: Revisar acceso y privilegios
Exporta los usuarios del registrador y del proveedor de DNS. Elimina cuentas obsoletas. Exige MFA. Identifica administradores. Registra evidencias de aprobación para usuarios privilegiados y documenta el acceso de emergencia.
Día 3: Validar DNSSEC y bloqueos
Para cada dominio crítico, verifica la validación de la cadena DNSSEC, la exactitud del registro DS, la visibilidad de DNSKEY, el bloqueo del registrador y el bloqueo a nivel de registro. Si DNSSEC es gestionado por el proveedor, documenta la responsabilidad del proveedor. Si es gestionado por el cliente, añade las claves DNSSEC y sus custodios al Registro de Gestión de Claves.
Día 4: Convertir los cambios DNS en registros formales de cambio
Selecciona los tres últimos cambios DNS y contrástalos con los criterios del paso 21 de Zenith Blueprint: riesgo evaluado, aprobación documentada, plan de reversión incluido, implementación según lo previsto e impacto inesperado registrado. Crea un registro resumen de cambios.
Día 5: Conectar la supervisión con la respuesta a incidentes
Confirma registros y alertas para inicio de sesión del registrador, cambios de zona, cambios DNSSEC, cambios NS, cambios MX, cambios TXT, cambios CAA y notificaciones del proveedor. Envía alertas de prueba al SOC o al propietario de TI. Adjunta evidencias al repositorio del SGSI.
Día 6: Revisar las obligaciones de proveedores
Utiliza la guía del paso 23 de Zenith Blueprint para procedimientos de cambio y supervisión de proveedores:
Establece un procedimiento sencillo y escalable para evaluar cambios en los servicios de proveedores (5.21), como migración a la nube, nuevos subencargados o rediseño de infraestructura. Define desencadenantes que requieran una reevaluación de seguridad. Después, implementa una cadencia recurrente de supervisión de proveedores (5.22), asignando propietarios a proveedores críticos y asegurando que el desempeño, el cumplimiento y los riesgos se revisen al menos anualmente.
De la fase Controles en acción, paso 23: controles organizativos 5.19 a 5.37.
La Política de Seguridad de Terceros y Proveedores empresarial de Clarysec Política de Seguridad de Terceros y Proveedores proporciona el anclaje contractual:
Los contratos con proveedores deben incluir:
De la sección “Requisitos de gobernanza”, cláusula 5.3 de la política.
| Tema contractual | Requisito específico de DNS |
|---|---|
| Responsabilidades de seguridad | Quién gestiona DNSSEC, bloqueos, registros, acceso, copias de seguridad y aprobaciones de cambios |
| Notificación de incidentes | Plazos y canales para compromiso del registrador, indisponibilidad de DNS o cambio no autorizado |
| Escalado de soporte | Vía de emergencia 24/7 para dominios críticos |
| Notificación de cambios | Aviso previo para migraciones de plataforma, cambios de API y cambios de subencargados |
| Evidencias | Registros de acceso, historial de cambios, estado de bloqueo, estado DNSSEC e informes de tiempo de actividad |
| Salida | Transferencia de dominio, exportación de zona, migración DNSSEC y procedimiento de retirada de bloqueo |
Día 7: Ejecutar un ejercicio de mesa
Simula un cambio no autorizado de registro NS. El equipo debe detectarlo, clasificarlo, escalarlo, contactar con el registrador, invocar procedimientos de bloqueo a nivel de registro si es necesario, restaurar la delegación correcta, validar DNSSEC, notificar a las partes interesadas, evaluar el impacto conforme al RGPD de la UE y decidir si se cumplen los umbrales de notificación de NIS2 o DORA. Registra las lecciones aprendidas y actualiza los procedimientos.
Preguntas de auditoría, hallazgos comunes y métricas para el consejo de administración
Una auditoría de gobierno de DNS rara vez se realiza desde una única perspectiva.
| Perspectiva del auditor | Pregunta probable de auditoría | Evidencia sólida |
|---|---|---|
| Auditor ISO/IEC 27001:2022 | ¿Los dominios están dentro del alcance, evaluados en términos de riesgo, asignados a propietarios, controlados, supervisados e incluidos en la gobernanza de proveedores? | Alcance del SGSI, Registro de Riesgos, Registro de Activos, Declaración de Aplicabilidad, tickets de cambio, revisiones de proveedores y registros |
| Evaluador NIST CSF 2.0 | ¿Los riesgos DNS se gobiernan, identifican, protegen, detectan, responden y recuperan? | Perfil actual y objetivo, plan de brechas, Inventario de Activos, controles de acceso, alertas de supervisión y registros de recuperación |
| Revisor DORA | ¿DNS respalda funciones críticas o importantes, y la dependencia está gobernada, probada y es recuperable? | Mapa de dependencias de activos TIC, plan de pruebas de resiliencia, proceso de clasificación de incidentes, registro de terceros y evidencias de recuperación |
| Revisor RGPD de la UE | ¿Un incidente DNS podría afectar a datos personales, y puede la organización demostrar seguridad adecuada? | Evidencias de Article 32, evaluación de incidente, supervisión de encargados, control de acceso, registros de cambios y supervisión |
| Auditor COBIT 2019 o ISACA | ¿Los objetivos de gobierno relacionados con dominios se traducen en procesos gestionados con titularidad, métricas y aseguramiento? | RACI, objetivos de proceso, KPI, KRI, revisiones del desempeño de proveedores, informes a la dirección y seguimiento de remediación |
Los hallazgos más comunes son previsibles.
| Hallazgo | Riesgo | Corrección de Clarysec |
|---|---|---|
| Dominios ausentes del Registro de Activos | Caducidad, confusión sobre la titularidad y evaluación de riesgos incompleta | Añadir dominios al Registro de Activos con propietario, propósito, criticidad, renovación y dependencias |
| Cuenta administrativa compartida del registrador | Sin responsabilidad proactiva y análisis forense de incidentes débil | Migrar a usuarios nominales, MFA, mínimo privilegio y revisiones trimestrales |
| Sin bloqueo a nivel de registro en dominio crítico | Delegación o transferencia no autorizada de alto impacto | Habilitar el bloqueo a nivel de registro y documentar el procedimiento de desbloqueo de emergencia |
| DNSSEC parcialmente habilitado | Fallos de validación o falsa sensación de aseguramiento | Validar cadena, registros DS, titularidad de claves y plan de rotación |
| Cambios DNS realizados fuera de tickets | Indisponibilidad, enrutamiento erróneo y fallo de auditoría | Exigir un tipo formal de cambio DNS con aprobación y reversión |
| Sin alertas sobre cambios NS o MX | Detección lenta de secuestro o redirección de correo | Integrar la supervisión DNS con SIEM y procedimiento operativo de escalado |
| Registrador no revisado como proveedor | Brechas contractuales y de respuesta a incidentes | Añadir registrador y proveedor de DNS a la cadencia de supervisión de proveedores |
| Sin playbook de incidentes | Recuperación retrasada e incertidumbre de notificación | Crear procedimientos operativos de secuestro de DNS e indisponibilidad de DNS, y después probarlos mediante un ejercicio de mesa |
Los consejos de administración y los equipos directivos necesitan métricas de DNS expresadas en lenguaje de resiliencia. Entre las medidas útiles se incluyen el porcentaje de dominios críticos con DNSSEC habilitado y validado, el porcentaje con bloqueo a nivel de registro, el número de administradores del registrador, el porcentaje de usuarios privilegiados revisados en el último trimestre, el número de cambios DNS implementados sin tickets formales, el tiempo medio de detección de un cambio DNS no autorizado, el tiempo medio de restauración de la configuración DNS correcta, los dominios que caducan en los próximos 90 días, las revisiones de proveedores completadas y las alertas de supervisión DNS no resueltas.
Convertir DNS de riesgo oculto en evidencias preparadas para auditoría
Si tu organización no ha revisado el gobierno de dominios y DNS en los últimos seis meses, asume que existe deriva. Empieza por los dominios críticos de producción y después amplía a dominios regionales, dominios defensivos, dominios de prueba, dominios de adquisiciones y dominios gestionados por agencias o filiales.
Clarysec puede ayudarte a pasar de capturas de pantalla dispersas del registrador a un paquete estructurado de evidencias utilizando:
- Zenith Blueprint: hoja de ruta de 30 pasos para auditores Zenith Blueprint para la validación paso a paso de servicios de red, gestión de cambios, registro de eventos, supervisión y controles de proveedores
- Zenith Controls: guía de cumplimiento cruzado Zenith Controls para mapear DNSSEC, bloqueo a nivel de registro, supervisión de proveedores y gobierno de cambios de zona a través de las perspectivas de ISO/IEC 27001:2022, NIS2, DORA, el RGPD de la UE, NIST y COBIT 2019
- Plantillas de políticas de Clarysec, incluidas Política de Gestión de Activos - pyme, Política de gestión de cambios - pyme, Política de gestión de cuentas de usuario y privilegios - pyme, Política de Seguridad de Redes - pyme, Política de Gestión de Activos, Política de gestión de cambios, Política de registro y supervisión, Política de Controles Criptográficos y Política de Seguridad de Terceros y Proveedores
Tu dominio es la puerta de entrada a tu negocio digital. En 2026, auditores, reguladores, clientes y consejos de administración esperarán que demuestres que esa puerta está cerrada, supervisada, es recuperable y está gobernada.
Descarga el toolkit de Clarysec, ejecuta el ejercicio de paquete de evidencias DNS de una semana o reserva una evaluación de Clarysec para convertir el gobierno de DNS y del registrador en pruebas preparadas para auditoría antes de tu propia crisis de lunes por la mañana.
Frequently Asked Questions
About the Author
Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council
