Extensiones de seguridad del sistema de nombres de dominio

DNS se implementa mediante el uso de varios registros de recursos. Para implementar DNSSEC, se crearon o adaptaron varios tipos de registros DNS nuevos para su uso con DNSSEC:

RRSIG (firma de registro de recursos)

Contiene la firma DNSSEC para un conjunto de registros. Los resolvedores DNS verifican la firma con una clave pública, almacenada en un registro DNSKEY.

Clave DNS

Contiene la clave pública que un resolvedor DNS utiliza para verificar las firmas DNSSEC en los registros RRSIG.

DS (firmante de delegación)

Contiene el nombre de una zona delegada. Hace referencia a un registro DNSKEY en la subzona delegada. El registro DS se ubica en la zona principal junto con los registros NS delegadores.

NSEC (siguiente registro seguro)

Contiene un enlace al siguiente nombre de registro en la zona y enumera los tipos de registro que existen para dicho nombre. Los resolvedores DNS utilizan los registros NSEC para verificar la inexistencia de un nombre y tipo de registro como parte de la validación DNSSEC.

NSEC3 (próxima versión de registro seguro 3)

Contiene enlaces al siguiente nombre de registro en la zona (en orden de clasificación por hash) y enumera los tipos de registro existentes para el nombre cubierto por el valor hash en la primera etiqueta del nombre del registro NSEC3. Estos registros pueden ser utilizados por los resolvedores para verificar la inexistencia de un nombre y tipo de registro como parte de la validación DNSSEC. Los registros NSEC3 son similares a los registros NSEC, pero NSEC3 utiliza nombres de registro con hash criptográfico para evitar la enumeración de los nombres de registro en una zona.

NSEC3PARAM (parámetros de la versión 3 del siguiente registro seguro)

Los servidores DNS autoritativos utilizan este registro para calcular y determinar qué registros NSEC3 deben incluir en las respuestas a las solicitudes DNSSEC para nombres/tipos inexistentes.

Cuando se utiliza DNSSEC, cada respuesta a una consulta DNS contiene un registro DNS RRSIG, además del tipo de registro solicitado. El registro RRSIG es una firma digital del conjunto de registros de recursos DNS de la respuesta . La firma digital se verifica localizando la clave pública correcta en un registro DNSKEY. Los registros NSEC y NSEC3 se utilizan para proporcionar evidencia criptográfica de la inexistencia de cualquier registro de recursos (RR). El registro DS se utiliza en la autenticación de DNSKEY durante el procedimiento de consulta mediante la cadena de confianza. Los registros NSEC y NSEC3 se utilizan para ofrecer una sólida resistencia contra la suplantación de identidad.

A partir de los resultados de una consulta DNS, un resolvedor DNS con seguridad puede determinar si el servidor de nombres autoritativo del dominio consultado admite DNSSEC, si la respuesta recibida es segura y si existe algún tipo de error. El procedimiento de consulta es diferente para servidores de nombres recursivos, como los de muchos proveedores de servicios de Internet (ISP) , y para resolvedores stub, como los incluidos por defecto en los sistemas operativos más comunes. Microsoft Windows utiliza un resolvedor stub, y Windows Server 2008 R2 y Windows 7, en particular, utilizan un resolvedor stub no validador pero compatible con DNSSEC. ^{[ 11 ] [ 12 ]}

Para poder demostrar que una respuesta DNS es correcta, es necesario conocer al menos una clave o registro DS correcto de fuentes distintas al DNS. Estos puntos de partida se conocen como anclas de confianza y normalmente se obtienen con el sistema operativo o a través de alguna otra fuente de confianza. Cuando se diseñó originalmente DNSSEC, se pensó que el único ancla de confianza necesaria sería la raíz DNS . Las anclas raíz se publicaron por primera vez el 15 de julio de 2010. ^{[ 18 ]}

Una cadena de autenticación es una serie de registros DS y DNSKEY vinculados, que comienza con un ancla de confianza al servidor de nombres autoritativo del dominio en cuestión. Sin una cadena de autenticación completa, una respuesta a una consulta DNS no puede autenticarse de forma segura.

Para limitar los ataques de repetición, no solo se utilizan los valores TTL de DNS habituales para el almacenamiento en caché, sino también marcas de tiempo adicionales en los registros RRSIG para limitar la validez de una firma. A diferencia de los valores TTL, que son relativos al momento en que se enviaron los registros, las marcas de tiempo son absolutas. Esto significa que todos los servidores DNS que priorizan la seguridad deben tener relojes sincronizados con bastante precisión, por ejemplo, con una diferencia de pocos minutos.

Estas marcas de tiempo implican que una zona debe volver a firmarse periódicamente y redistribuirse a los servidores secundarios, o las firmas serán rechazadas por los resolvedores de validación.

DNSSEC implica muchas claves diferentes, almacenadas tanto en registros DNSKEY como procedentes de otras fuentes para formar anclas de confianza .

Para permitir el reemplazo de claves, se requiere un esquema de rotación de claves . Normalmente, esto implica primero implementar nuevas claves en nuevos registros DNSKEY, además de las claves antiguas existentes. Luego, cuando se puede asumir con seguridad que el tiempo de vida ha expirado, se pueden usar estas nuevas claves. Finalmente, cuando se puede asumir con seguridad que el almacenamiento en caché de los registros que usan las claves antiguas ha expirado, se pueden eliminar los registros DNSKEY antiguos. Este proceso es más complejo para elementos como las claves de anclaje de confianza, como en la raíz, que pueden requerir una actualización del sistema operativo.

Las claves en los registros DNSKEY se pueden usar para dos propósitos distintos, y normalmente se utilizan registros DNSKEY diferentes para cada uno. En primer lugar, están las claves de firma de clave (KSK), que se usan para firmar otros registros DNSKEY que contienen claves de firma de zona (ZSK), las cuales se usan para firmar otros registros. Dado que las ZSK están bajo el control y uso exclusivo de una zona DNS específica , se pueden cambiar con mayor facilidad y frecuencia. Como resultado, las ZSK pueden ser mucho más cortas que las KSK y aun así ofrecer el mismo nivel de protección, a la vez que reducen el tamaño de los registros RRSIG/DNSKEY.

Cuando se crea una nueva KSK, el registro DS debe transferirse a la zona principal y publicarse allí. Los registros DS utilizan un resumen del mensaje de la KSK en lugar de la clave completa para mantener un tamaño reducido. Esto resulta útil para zonas como el dominio .com , que son muy grandes. El procedimiento para actualizar las claves DS en la zona principal también es más sencillo que en versiones anteriores de DNSSEC, que requerían que los registros DNSKEY estuvieran en dicha zona.

Un principio estrechamente relacionado es el de la rotación de algoritmos , que implica la migración de una zona de un algoritmo de firma a otro. Un buen ejemplo de esto sería la migración del algoritmo 8 (RSA/SHA-256) al algoritmo 13 (ECDSA/SHA-256). Varios ccTLD ya han migrado, incluidos .at , .br , .cz , .ch , .fr , .ie , .nl ^{[ 19 ]} y .ph . Verisign migró .com, .net y .edu al algoritmo 13 a finales de 2023. ^{[ 20 ] [ 21 ]} La migración del dominio raíz del algoritmo 8 al algoritmo 13 se encuentra actualmente en fase de planificación a principios de 2024. ^{[ 22 ]}

La autenticación basada en DNS de entidades nombradas (DANE) es un grupo de trabajo de la IETF ^{[ 23 ]} cuyo objetivo es desarrollar protocolos y técnicas que permitan a las aplicaciones de Internet establecer comunicaciones criptográficamente seguras con TLS , DTLS , SMTP y S/MIME basadas en DNSSEC.

Los nuevos protocolos permitirán mayor seguridad y restricciones para el modelo tradicional basado en infraestructura de clave pública . Además, permitirán a los titulares de dominios emitir certificados por sí mismos, sin necesidad de recurrir a autoridades de certificación de terceros .

La compatibilidad con certificados DNSSEC vinculados se habilitó en Google Chrome 14, ^{[ 24 ]} pero posteriormente se eliminó. ^{[ 25 ]} Para Mozilla Firefox , la compatibilidad se proporcionó mediante un complemento ^{[ 26 ]} hasta Firefox 56, mientras que la compatibilidad nativa se propuso pero finalmente se rechazó. ^{[ 27 ]}

Los registros NSEC3 (RFC 5155) se crearon como una alternativa que aplica un hash al nombre en lugar de listarlos directamente. Con el tiempo, los avances en el hash mediante GPU y hardware dedicado permitieron que las respuestas NSEC3 fueran fácilmente atacadas por fuerza bruta mediante ataques de diccionario sin conexión. Se propuso NSEC5 para permitir que los servidores autorizados firmen las respuestas NSEC sin necesidad de conservar una clave privada que pueda utilizarse para modificar la zona. Por lo tanto, robar una NSEC5KEY solo facilitaría la enumeración de una zona. ^{[ 30 ]}

Debido a la evolución desordenada del protocolo y al deseo de preservar la compatibilidad con versiones anteriores, los servidores de firma DNSSEC en línea devuelven una "mentira piadosa" en lugar de autenticar directamente una negación de existencia. La técnica descrita en la RFC 4470 devuelve un registro NSEC en el que los pares de dominios rodean léxicamente el dominio solicitado. Por ejemplo, la solicitud de k.example.comdaría como resultado un registro NSEC que prueba que no existe nada entre los dominios (ficticios) j.example.comy l.example.com. Esto también es posible con los registros NSEC3. ^{[ 31 ]}

Cloudflare fue pionera en un par de enfoques alternativos, que logran el mismo resultado en un tercio del tamaño de la respuesta. ^{[ 32 ]} El primero es una variación del enfoque de "mentiras piadosas", llamado "mentiras negras", que explota el comportamiento común del cliente DNS para indicar la no existencia de manera más compacta. ^{[ 33 ]} El segundo enfoque, en cambio, opta por demostrar que "el registro existe, pero el tipo de registro solicitado no", lo que ellos llaman "escopeta DNS". ^{[ 34 ] [ 32 ]}

Entre los primeros en adoptarlo se encuentran Brasil ( .br ), Bulgaria ( .bg ), República Checa ( .cz ), Namibia ( .na ) ^{[ 37 ]} Puerto Rico ( .pr ) y Suecia ( .se ), que utilizan DNSSEC para sus dominios de nivel superior de código de país ; ^{[ 38 ]} RIPE NCC , que ha firmado todos los registros de búsqueda inversa (in-addr.arpa) que le delega la Autoridad de Números Asignados de Internet (IANA). ^{[ 39 ]} ARIN también está firmando sus zonas inversas. ^{[ 40 ]} En febrero de 2007, TDC se convirtió en el primer ISP sueco en comenzar a ofrecer esta función a sus clientes. ^{[ 41 ]}

IANA probó públicamente una raíz firmada de muestra desde junio de 2007. Durante este período previo a la firma de producción de la raíz, también hubo varias anclas de confianza alternativas. IKS Jena introdujo una el 19 de enero de 2006, ^{[ 42 ]} el Consorcio de Sistemas de Internet introdujo otra el 27 de marzo del mismo año, ^{[ 43 ]} mientras que la propia ICANN anunció una tercera el 17 de febrero de 2009. ^{[ 44 ]}

El 2 de junio de 2009, Afilias , el proveedor de servicios de registro para la zona .org de Public Interest Registry, firmó el TLD .org. ^{[ 45 ]} Afilias y PIR también detallaron el 26 de septiembre de 2008 que la primera fase, que involucra a grandes registradores con los que tiene una sólida relación de trabajo ("amigos y familiares"), sería la primera en poder firmar sus dominios, comenzando a "principios de 2009". ^{[ 46 ]} El 23 de junio de 2010, se enumeraron 13 registradores que ofrecían registros DNSSEC para dominios .ORG. ^{[ 47 ]}

VeriSign llevó a cabo un proyecto piloto para permitir que los dominios .com y .net se registraran con el fin de experimentar con NSEC3. El 24 de febrero de 2009, anunciaron que implementarían DNSSEC en todos sus dominios de nivel superior (.com, .net, etc.) en un plazo de 24 meses, ^{[ 48 ]} y el 16 de noviembre del mismo año, dijeron que los dominios .com y .net estarían firmados para el primer trimestre de 2011, después de retrasos causados ​​por aspectos técnicos de la implementación. ^{[ 49 ]} Este objetivo se logró según lo previsto ^{[ 50 ]} y el vicepresidente de DNSSEC de Verisign, Matt Larson, ganó el premio InfoWorld Technology Leadership Award de 2011 por su papel en el avance de DNSSEC. ^{[ 51 ] [ 52 ]}

DNSSEC se implementó por primera vez a nivel raíz el 15 de julio de 2010. ^{[ 53 ]} Se espera que esto simplifique enormemente la implementación de los resolvedores DNSSEC, ya que el ancla de confianza raíz se puede usar para validar cualquier zona DNSSEC que tenga una cadena de confianza completa desde la raíz. Dado que la cadena de confianza debe rastrearse hasta una raíz de confianza sin interrupción para la validación, aún se deben configurar anclas de confianza para las zonas seguras si alguna de las zonas superiores a ellas no es segura. Por ejemplo, si la zona "signed.example.org" estaba protegida pero la zona "example.org" no lo estaba, entonces, aunque la zona ".org" y la raíz estén firmadas, se debe implementar un ancla de confianza para validar la zona.

Las cuestiones políticas que rodean la firma del tratado fundamental han sido una preocupación constante, principalmente en lo que respecta a algunos temas centrales:

• Otros países están preocupados por el control estadounidense sobre Internet y, por este motivo, podrían rechazar cualquier sistema de cifrado centralizado.
• Algunos gobiernos podrían intentar prohibir la distribución de claves de cifrado basadas en DNSSEC.

Debajo del dominio raíz hay un amplio conjunto de dominios de nivel superior que deben firmarse para lograr una implementación completa de DNSSEC. La lista de dominios de nivel superior de Internet proporciona detalles sobre cuáles de los dominios de nivel superior existentes se han firmado y vinculado al dominio raíz.

En marzo de 2006, el Consorcio de Sistemas de Internet presentó el registro de validación DNSSEC Lookaside (DLV). ^{[ 63 ]} El DLV tenía como objetivo facilitar la implementación de DNSSEC en ausencia de un ancla de confianza raíz. En ese momento, se imaginaba que un validador podría tener que mantener un gran número de anclas de confianza correspondientes a subárboles firmados del DNS. ^{[ 64 ]} El propósito del DLV era permitir que los validadores delegaran el esfuerzo de administrar un repositorio de anclas de confianza a un tercero de confianza. El registro DLV mantenía una lista central de anclas de confianza, en lugar de que cada validador repitiera el trabajo de mantener su propia lista.

Para usar DLV, se necesitaba un validador que lo soportara, como BIND o Unbound , configurado con un ancla de confianza para una zona DLV. Esta zona contenía registros DLV; ^{[ 65 ]} estos tenían exactamente el mismo formato que los registros DS, pero en lugar de referirse a una subzona delegada, se referían a una zona en otra parte del árbol DNS. Cuando el validador no podía encontrar una cadena de confianza desde la raíz hasta el RRset que estaba intentando comprobar, buscaba un registro DLV que pudiera proporcionar una cadena de confianza alternativa. ^{[ 66 ]}

Las deficiencias en la cadena de confianza, como los dominios de nivel superior sin firmar o los registradores que no admitían las delegaciones DNSSEC, permitían a los administradores de dominios de nivel inferior utilizar DLV para que sus datos DNS fueran validados por los resolvedores configurados para usar DLV. Esto pudo haber dificultado la implementación de DNSSEC al reducir la presión sobre los registradores y los registros de TLD para que lo admitieran correctamente. DLV también añadió complejidad al incorporar más actores y rutas de código para la validación DNSSEC.

ISC desmanteló su registro DLV en 2017. ^{[ 67 ]} El soporte para DLV se dejó de usar en BIND 9.12 y se eliminó por completo de BIND 9.16. ^{[ 68 ]} La versión 1.5.4 de Unbound (julio de 2015) marcó DLV como desmantelado en la configuración de ejemplo y en la página del manual. ^{[ 69 ]} Knot Resolver y PowerDNS Recursor nunca implementaron DLV.

En marzo de 2020, el IETF publicó el RFC 8749 , retirando DLV como estándar y pasando los RFC 4432 y RFC 5074 al estado de "Histórico". ^{[ 70 ]} 

La Dirección de Ciencia y Tecnología del Departamento de Seguridad Nacional de los Estados Unidos (DHS) patrocina la "Iniciativa de Despliegue de DNSSEC". Esta iniciativa alienta a todos los sectores a adoptar voluntariamente medidas de seguridad que mejoren la seguridad de la infraestructura de nombres de Internet, como parte de un esfuerzo global y cooperativo que involucra a numerosas naciones y organizaciones de los sectores público y privado. El DHS también financia iniciativas para perfeccionar DNSSEC e implementarlo dentro del gobierno federal de los Estados Unidos.

Se informó ^{[ 71 ]} que el 30 de marzo de 2007, el Departamento de Seguridad Nacional de EE. UU. propuso "tener la clave para firmar la zona raíz del DNS firmemente en manos del gobierno de EE. UU.". Sin embargo, ningún funcionario del gobierno de EE. UU. estuvo presente en la sala de reuniones y el comentario que originó el artículo fue realizado por otra persona. El DHS comentó posteriormente ^{[ 72 ] [ 73 ]} sobre por qué creen que otros llegaron a la conclusión errónea de que el gobierno de EE. UU. había hecho tal propuesta: "El Departamento de Seguridad Nacional de EE. UU. está financiando el desarrollo de un plan técnico para implementar DNSSec y, en octubre pasado, distribuyó un borrador inicial a una larga lista de expertos internacionales para que hicieran comentarios. El borrador presenta una serie de opciones sobre quién podría ser el titular, u "operador", de la clave de la zona raíz, reduciéndose esencialmente a una agencia gubernamental o un contratista. "En ninguna parte del documento hacemos ninguna propuesta sobre la identidad del operador de la clave raíz", dijo Maughan, gerente de investigación y desarrollo de ciberseguridad del Departamento de Seguridad Nacional."

El Instituto Nacional de Estándares y Tecnología (NIST) publicó la Publicación Especial NIST 800-81, Guía de Implementación del Sistema de Nombres de Dominio Seguro (DNS), el 16 de mayo de 2006, con orientación sobre cómo implementar DNSSEC. El NIST tenía previsto publicar nuevos requisitos de la Ley Federal de Gestión de la Seguridad de la Información (FISMA) para DNSSEC en la publicación NIST SP800-53-R1, haciendo referencia a esta guía de implementación. Las agencias estadounidenses habrían tenido entonces un año después de la publicación final de NIST SP800-53-R1 para cumplir con estos nuevos requisitos de FISMA. ^{[ 74 ]} Sin embargo, en ese momento, NSEC3 no se había completado. El NIST había sugerido el uso de dominios divididos, una técnica que se sabe que es posible pero difícil de implementar correctamente, y que tiene las debilidades de seguridad señaladas anteriormente.

El 22 de agosto de 2008, la Oficina de Administración y Presupuesto (OMB) publicó un memorando que exigía a las agencias federales estadounidenses implementar DNSSEC en todos los sitios .gov; el dominio raíz .gov debía estar firmado antes de enero de 2009, y todos los subdominios bajo .gov debían estar firmados antes de diciembre de 2009. ^{[ 75 ]} Si bien el memorando se centra en los sitios .gov, la Agencia de Sistemas de Información de Defensa de EE. UU. afirma que tiene la intención de cumplir con los requisitos de DNSSEC de la OMB también en el dominio .mil (militar estadounidense). Carolyn Duffy Marsan, de NetworkWorld, declaró que DNSSEC "no se ha implementado ampliamente porque sufre del clásico dilema del huevo y la gallina... con el mandato de la OMB, parece que el huevo se está rompiendo". ^{[ 76 ]}

Varios ISP han comenzado a implementar resolutores recursivos DNS que validan DNSSEC. Comcast se convirtió en el primer gran ISP en hacerlo en los Estados Unidos, anunciando sus intenciones el 18 de octubre de 2010 ^{[ 77 ] [ 78 ]} y completando la implementación el 11 de enero de 2012. ^{[ 79 ]}

Según un estudio de APNIC , la proporción de clientes que utilizan exclusivamente resolvedores DNS que realizan validación DNSSEC aumentó al 8,3 % en mayo de 2013. ^{[ 80 ]} Aproximadamente la mitad de estos clientes utilizaban el resolvedor DNS público de Google .

En septiembre de 2015, Verisign anunció su servicio gratuito de resolución pública de DNS, ^{[ 81 ]} y aunque no se menciona en sus comunicados de prensa, también realiza la validación DNSSEC.

A principios de 2016, el monitoreo de APNIC mostró que la proporción de clientes que usan exclusivamente resolvedores DNS que realizan validación DNSSEC había aumentado a aproximadamente el 15%. ^{[ 82 ]}

En septiembre de 2023, Microsoft anunció que utilizaría DNSSEC (a través de DANE ) para verificar la autenticidad de los certificados durante las comunicaciones SMTP. ^{[ 85 ]}