Trate el control DNS como parte de la confianza del correo electrónico
El secuestro DNS es un cambio no autorizado en la información o la ruta de resolución en la que confía un cliente. Para un equipo de correo electrónico, la pregunta importante no es simplemente si el sitio web de un dominio se movió. Determine qué autoridad, cuenta o resolución se vio afectada, qué nombres relacionados con el correo cambiaron y qué receptores podrían haber observado durante el intervalo afectado. Una respuesta clara ahora no establece que las decisiones de entrega anteriores utilizaron los mismos datos.
Mantenga la toma de control autorizada separada del envenenamiento de la caché y la redirección del solucionador local. Pueden producir síntomas similares pero requieren propietarios de recuperación diferentes. Una cuenta de registrador puede influir en la delegación; una cuenta de alojamiento autorizada puede cambiar el contenido de la zona; un punto final comprometido puede utilizar un solucionador inesperado. NIST guía de implementación DNS distingue las amenazas a los servicios autoritativos, recursivos y stub. Esa distinción es el punto de partida para un mapa de incidentes útil.
Identificar el límite de confianza que se movió
Compare la línea base de registro y delegación conocida con el servicio autorizado actual. Registre quién administra el registrador, el alojamiento DNS , la infraestructura de firma y los contactos de recuperación. Compruebe si se autorizó un cambio antes de llamarlo malicioso: las migraciones planificadas, los subdominios delegados y las vistas divididas pueden producir diferencias legítimas. Preserve la incertidumbre cuando los registros o registros de cuentas no estén disponibles.
La jerarquía autorizada es importante porque es posible que una exportación de zona de apariencia confiable del antiguo proveedor ya no describa la delegación pública. RFC 1034 sección 4.2 explica los límites de la zona y la delegación. La evidencia del incidente debe identificar el servidor y la ruta utilizada para cada observación, no simplemente reproducir el texto de la respuesta. Una captura de pantalla sin el nombre consultado, el tipo de registro y la marca de tiempo es una prueba débil de lo que cambió.
Utilice procedimientos de incidentes establecidos para proteger las cuentas afectadas, preservar los registros relevantes y coordinar la restauración. Esas acciones requieren la autorización de la organización; Este artículo no dirige cambios a un servicio en vivo. Evite destruir evidencia útil eliminando cuentas, reemplazando cada registro o limpiando cada caché antes de que el propietario del incidente haya capturado el estado afectado.
Rastree diferentes consecuencias para el correo entrante y saliente
Un cambio MX no autorizado puede redirigir los intentos de entregar correo entrante. El hecho de que un remitente en particular realice la entrega depende de la ruta elegida, de las protecciones de transporte y de la conexión resultante. No infiera que el contenido del buzón se leyó únicamente a partir de una diferencia MX . Establezca el intervalo afectado e inspeccione la evidencia de entrega antes de realizar un reclamo de exposición.
Las comprobaciones de identidad salientes tienen diferentes dependencias. SPF evalúa si la dirección de conexión está autorizada para el dominio evaluado, utilizando la política DNS en RFC 7208. Si un adversario controla esa política, un pase SPF puede reflejar una política no autorizada en lugar de una autorización comercial legítima. Reemplazo de un DKIM La clave pública puede afectar la verificación, pero la publicación de una clave no altera las firmas de mensajes antiguos ni revela la clave privada anterior. El proceso de búsqueda y verificación de claves se describe en RFC 6376 secciones 3.6 y 6.1.2.
DMARC se basa en un identificador autenticado alineado con el dominio del autor. No es un registro independiente de empleados o proveedores aprobados. El material de autenticación de un dominio secuestrado puede socavar las suposiciones detrás de un resultado aprobado. La política de dominio también informa el manejo del receptor en lugar de garantizar un resultado universal, como se explica en RFC 9989 secciones 4.4 y 5.4.
Comprender qué protecciones abordan qué riesgo
DNSSEC proporciona autenticación de origen e integridad para los datos DNS cuando la validación tiene una cadena de confianza utilizable. No certifica que un cambio realizado a través de un sistema de firma autorizado refleje la intención del propietario. Una edición maliciosa aceptada y firmada por una ruta de administración autorizada comprometida aún puede validarse. RFC 4033 sección 3 establece los servicios que proporciona DNSSEC ; Los controles de aprobación y protección de cuentas abordan una capa diferente.
Las políticas de transporte también necesitan su propio análisis. Un existente MTA-STS La política puede restringir los hosts MX permitidos y la validación TLS para implementar remitentes, pero el descubrimiento inicial y el almacenamiento en caché de políticas tienen límites. DANE SMTP depende de información autenticada por DNSSEC y de TLSA archivos. Ninguno de los mecanismos debe describirse como un antídoto universal contra la apropiación administrativa del dominio. Consultar RFC 8461 sección 10 y RFC 7672 sección 2 por sus distintos modelos de confianza.
Ejemplo ficticio trabajado de un cambio MX en disputa
En la organización ficticia Ejemplo Talleres, una alerta informa que example.com ahora tiene un destino MX diferente. El antiguo panel DNS del administrador de correo todavía muestra el valor esperado. Una investigación propuesta compararía la delegación, las respuestas autorizadas actuales y los registros de cambios de registrador antes de decidir si el panel simplemente ya no tiene autoridad.
Supongamos que el registro de incidentes establece posteriormente un cambio de delegación no autorizado. El propietario de la respuesta coordinaría el restablecimiento de la autoridad aprobada y evaluaría el período de tiempo comparándolo con los registros del remitente y la evidencia de la política de transporte. Un pase de autenticación en un mensaje saliente no relacionado no cerraría la pregunta de exposición entrante. Este escenario es inventado y no contiene ningún incidente observado, acceso a la cuenta del proveedor ni restauración probada.
Defina la recuperación más allá de restaurar una respuesta
Conserve la diferencia de registro aprobada, el mapa de dependencia y el material de restauración, luego verifique la ruta autorizada restaurada y las vistas recursivas seleccionadas. Revise las claves, credenciales o puntos finales de políticas implicados por el compromiso real sin asumir que todos los secretos quedaron expuestos. Asignar responsabilidad para monitorear la recurrencia y las preguntas de exposición no resueltas.
Cerrar el incidente solo según criterios explícitos: se controla la administración, se entregan los registros previstos, se verifican los servicios dependientes y se comprende el intervalo de evidencia. Las respuestas almacenadas en caché y el correo en cola pueden sobrevivir a la reparación visible. Faltan aquí la aprobación original y la evidencia de búsqueda posterior al cambio, por lo que esta explicación educativa no es una evaluación completa del secuestro ni una declaración de que ningún dominio es seguro.