La silenciosa falla de DNS que hizo posibles los sitios web falsos
Cuando visitas un sitio web, tu computadora no se conecta a un nombre como "example.com". En cambio, necesita una IP address. Tu computadora envía una solicitud a un resolver, generalmente tu router o ISP, que luego consulta varios servidores DNS para encontrar la IP address correcta.
Las primeras respuestas de DNS eran vulnerables porque dependían de un simple ID de transacción de 16 bits para hacer coincidir las respuestas con las solicitudes. Aunque este ID ayudaba a organizar las consultas, no ofrecía ninguna prueba criptográfica de la identidad del remitente. Los atacantes podían inundar un resolver con respuestas falsificadas, adivinando uno de los 65,536 IDs posibles, y si una respuesta falsa llegaba antes que la legítima, el resolver la aceptaba y almacenaba en caché los datos maliciosos.
Esta falla fundamental se hizo evidente en 2008 con el descubrimiento del Kaminsky attack. Dan Kaminsky demostró cómo explotar esta debilidad apuntando a subdominios arbitrarios inexistentes, permitiendo a los atacantes envenenar rápidamente el registro del servidor de nombres autoritativo de un dominio. Esto expuso el riesgo generalizado del envenenamiento de caché DNS y subrayó la necesidad urgente de una arquitectura DNS más segura.
La solución a largo plazo, DNSSEC, ya se había formulado en 2005. Introdujo la autenticación criptográfica, asegurando que cada paso en la cadena de búsqueda de DNS (desde los servidores raíz hasta los servidores de dominio individuales) pueda verificar la autenticidad del siguiente. Este sistema estableció una cadena de confianza, evitando que los atacantes inyectaran información fraudulenta y redirigieran a los usuarios a sitios maliciosos.
La cadena de confianza termina en una clave raíz
DNSSEC, la solución a largo plazo para las vulnerabilidades de DNS, utiliza criptografía de clave pública para asegurar las búsquedas. Cada firmante tiene una private key para generar firmas digitales para los datos DNS y una public key correspondiente para la verificación. Los resolvers utilizan estas public keys para confirmar que los datos DNS no han sido alterados en tránsito, asegurando su autenticidad.
Una cadena de confianza se extiende desde la raíz de DNS hasta los dominios individuales. Cuando un resolver busca example.com, primero consulta los servidores raíz, que avalan los servidores de dominio de nivel superior (TLD) .com. Los servidores .com luego avalan el propio servidor DNS de example.com. Cada zona padre firma criptográficamente las public keys de sus zonas hijas, creando una ruta de validación ininterrumpida.
La Root Zone Key Signing Key (KSK) es única; no existe una autoridad DNS superior para autenticarla. Por lo tanto, su public key debe estar preconfigurada como un trust anchor en todos los resolvers que validan DNSSEC. Quien controle la mitad privada de la KSK podría firmar datos raíz falsos, socavando toda la cadena de confianza de DNS. Esta private key crítica se mantiene en un Hardware Security Module altamente seguro, aislado de Internet (air-gapped), y solo se accede a ella durante ceremonias de claves estrictamente controladas y con múltiples partes.
Dentro de la ceremonia creada para mantener una clave en secreto
Mantener el secreto de la clave raíz requiere un protocolo de seguridad elaborado y de múltiples capas, ejecutado en una instalación segura en Culpeper, Virginia. Este sitio, operado por ICANN y Public Technical Identifiers (PTI), salvaguarda los Hardware Security Modules (HSMs) que generan y almacenan la private key. El acceso a la sala de ceremonias implica múltiples puntos de control de seguridad, seguidos de una jaula cerrada y, finalmente, cajas fuertes que contienen los propios HSMs.
El proceso de firma es una salvaguarda de varias personas. Siete Crypto Officers designados, provenientes de la comunidad global de internet e independientes de ICANN, poseen cada uno una llave de seguridad para su caja de seguridad individual. Para activar el HSM y realizar una operación protegida, un mínimo de tres Crypto Officers deben estar físicamente presentes e insertar sus llaves de seguridad únicas.
Las ceremonias son públicamente observables y documentadas, lo que garantiza la transparencia. Los participantes inician una computadora portátil desde un sistema operativo de solo lectura confiable, verificando su huella criptográfica en voz alta. Una vez que se insertan las tres llaves de seguridad, un solo comando inicia el proceso de generación de claves dentro del HSM aislado (air-gapped). La clave privada nunca abandona este entorno seguro, excepto como una copia de seguridad cifrada. El identificador de la nueva clave, como 38696 para la clave de 2024, se registra luego, y el proceso concluye con todos los participantes firmando un guion en papel. Para obtener más detalles sobre estos procedimientos, consulte la documentación de IANA Root KSK Ceremonies.
¿Te está gustando? Recibe uno así en tu bandeja cada mañana.
un correo al día · date de baja en dos clics · sin rastreadores de terceros
Qué cambia cuando se renueva la clave raíz
Las renovaciones de claves introducen una nueva Key Signing Key (KSK), que reemplaza a la anterior como la clave de firma activa para el conjunto de registros DNSKEY de la zona raíz. Aunque la nueva clave se genera y certifica con meses de antelación, la "renovación" real ocurre cuando se convierte en la clave de firma principal, y su componente público debe estar disponible para todos los resolutores que validan DNSSEC como un trust anchor.
No actualizar este trust anchor puede causar interrupciones significativas. Un resolutor con una clave pública obsoleta no podrá validar las firmas generadas por la nueva KSK, rechazando todas las respuestas DNS para dominios firmados. Esto resulta en que los usuarios vean errores SERVFAIL, haciendo que los sitios web parezcan inalcanzables incluso si sus servidores están completamente operativos.
Los resolutores modernos que validan DNSSEC, como los de los ISP o servicios públicos como Cloudflare 1.1.1.1 y Google 8.8.8.8, suelen emplear actualizaciones automáticas de trust anchor, lo que mitiga la mayoría de los riesgos. Sin embargo, el firmware de routers antiguos o los sistemas configurados manualmente pueden quedar rezagados, requiriendo actualizaciones explícitas. Si experimenta fallos de DNS que coinciden con una renovación, actualizar el firmware de su router o el software del resolutor es un buen primer paso. Recuerde que la protección DNSSEC depende tanto de los dominios firmados como de los resolutores que validan.
Preguntas frecuentes
¿Qué es la clave maestra DNSSEC de internet?
Es la parte privada de la Key Signing Key (KSK) de la zona raíz, utilizada para firmar las claves DNSSEC de la zona raíz. Su contraparte pública es un trust anchor para los resolutores que validan.
¿Por qué DNS necesita DNSSEC?
DNSSEC añade firmas criptográficas que permiten a los resolutores que validan verificar si los datos DNS son auténticos y no han sido modificados, ayudando a evitar que se acepten respuestas falsificadas.
¿Puede una renovación de la clave raíz romper mi conexión a internet?
Puede interrumpir el DNS para los usuarios detrás de un resolutor que valida que no ha aprendido el nuevo trust anchor. El resolutor puede rechazar las respuestas, devolviendo a menudo un error SERVFAIL.
¿Cómo se protege la clave raíz?
La clave privada se mantiene en hardware seguro, y las operaciones de clave requieren múltiples participantes autorizados. Las ceremonias utilizan instalaciones controladas, procedimientos documentados y registros públicos.