Las extensiones de seguridad del sistema de nombres de dominio ( DNSSEC ) son un conjunto de especificaciones de extensión del Grupo de trabajo de ingeniería de Internet (IETF) para proteger los datos intercambiados en el sistema de nombres de dominio ( DNS ) en redes de protocolo de Internet ( IP ) . El protocolo proporciona autenticación criptográfica de datos, denegación de existencia autenticada e integridad de los datos , pero no disponibilidad ni confidencialidad .
El diseño original del Sistema de nombres de dominio no incluía ninguna característica de seguridad. Fue concebido únicamente como un sistema distribuido escalable. Las Extensiones de seguridad del sistema de nombres de dominio (DNSSEC) intentan añadir seguridad, manteniendo al mismo tiempo la compatibilidad con versiones anteriores . El RFC 3833 de 2004 documenta algunas de las amenazas conocidas al DNS y sus soluciones en DNSSEC.
DNSSEC fue diseñado para proteger a las aplicaciones que utilizan DNS de aceptar datos DNS falsificados o manipulados, como los creados por envenenamiento de caché DNS . Todas las respuestas de las zonas protegidas por DNSSEC están firmadas digitalmente . [1] Al verificar la firma digital, un solucionador DNS puede verificar si la información es idéntica (es decir, no modificada y completa) a la información publicada por el propietario de la zona y servida en un servidor DNS autorizado. Si bien la protección de direcciones IP es la preocupación inmediata de muchos usuarios, DNSSEC puede proteger cualquier dato publicado en el DNS, incluidos los registros de texto (TXT) y los registros de intercambio de correo (MX), y se puede utilizar para iniciar otros sistemas de seguridad que publican referencias a certificados criptográficos almacenados en el DNS, como registros de certificados ( registros CERT , RFC 4398), huellas digitales SSH ( SSHFP , RFC 4255), claves públicas IPSec (IPSECKEY, RFC 4025), anclajes de confianza TLS ( TLSA , RFC 6698) o Encrypted Client Hello (registros SVCB/HTTPS para ECH [2] [3] ).
DNSSEC no garantiza la confidencialidad de los datos; en particular, todas las respuestas de DNSSEC están autenticadas pero no cifradas. DNSSEC no protege directamente contra ataques DoS , aunque indirectamente proporciona algún beneficio (ya que la verificación de firmas permite el uso de terceros potencialmente no confiables). [ cita requerida ]
Se utilizan otros estándares (no DNSSEC) para proteger los datos masivos (como una transferencia de zona DNS ) enviados entre servidores DNS. Como se documenta en RFC 4367, algunos usuarios y desarrolladores hacen suposiciones falsas sobre los nombres DNS, como suponer que el nombre común de una empresa más ".com" es siempre su nombre de dominio. DNSSEC no puede proteger contra suposiciones falsas; solo puede autenticar que los datos son realmente del propietario del dominio o que no están disponibles a través de él. [ cita requerida ]
Las especificaciones DNSSEC (denominadas DNSSEC-bis ) describen el protocolo DNSSEC actual con gran detalle. Consulte RFC 4033, RFC 4034 y RFC 4035. Con la publicación de estas nuevas RFC (marzo de 2005), una RFC anterior, la RFC 2535, ha quedado obsoleta. El conjunto completo de RFC que especifican DNSSEC se recoge en RFC 9364, que también es BCP 237.
Se cree ampliamente [4] que proteger el DNS es de importancia crítica para proteger Internet en su conjunto, pero la implementación de DNSSEC específicamente se ha visto obstaculizada (a partir del 22 de enero de 2010 [update]) por varias dificultades:
DNSSEC funciona firmando digitalmente registros para búsquedas DNS mediante criptografía de clave pública . El registro DNSKEY correcto se autentica mediante una cadena de confianza , comenzando con un conjunto de claves públicas verificadas para la zona raíz DNS , que es el tercero de confianza . Los propietarios de dominios generan sus propias claves y las cargan mediante su panel de control DNS en su registrador de nombres de dominio, que a su vez envía las claves a través de secDNS al operador de la zona (por ejemplo, Verisign para .com) que las firma y las publica en DNS.
El 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:
Cuando se utiliza DNSSEC, cada respuesta a una búsqueda 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 respuesta . La firma digital se verifica ubicando la clave pública correcta que se encuentra 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 en el procedimiento de búsqueda mediante la cadena de confianza. Los registros NSEC y NSEC3 se utilizan para ofrecer una resistencia sólida contra la suplantación de identidad.
DNSSEC fue diseñado para ser extensible de modo que, a medida que se descubran ataques contra algoritmos existentes, se puedan introducir nuevos de manera compatible con versiones anteriores, como se describe en RFC 8624. La siguiente tabla define, a junio de 2019, los algoritmos de seguridad que se utilizan o se utilizaban con mayor frecuencia: [5]
A partir de los resultados de una búsqueda de DNS, un solucionador de DNS que tenga en cuenta la seguridad puede determinar si el servidor de nombres autorizado para el dominio consultado admite DNSSEC, si la respuesta que recibe es segura y si hay algún tipo de error. El procedimiento de búsqueda es diferente para los servidores de nombres recursivos , como los de muchos ISP , y para los solucionadores de stubs, como los que se incluyen de forma predeterminada en los sistemas operativos principales. Microsoft Windows utiliza un solucionador de stubs, y Windows Server 2008 R2 y Windows 7 en particular utilizan un solucionador de stubs que no realiza la validación, pero que tiene en cuenta DNSSEC. [6] [7]
Mediante el modelo de cadena de confianza , se puede utilizar un registro de firmante de delegación (DS) en un dominio principal ( zona DNS ) para verificar un registro DNSKEY en un subdominio , que luego puede contener otros registros DS para verificar otros subdominios. Supongamos que un solucionador recursivo, como un servidor de nombres de ISP, desea obtener las direcciones IP ( registro A y/o registros AAAA ) del dominio "www.example.com " .
Hay varias excepciones al ejemplo anterior.
En primer lugar, si "example.com" no es compatible con DNSSEC, no habrá ningún registro RRSIG en la respuesta y no habrá ningún registro DS para "example.com" en la zona "com". Si hay un registro DS para "example.com", pero no hay ningún registro RRSIG en la respuesta, algo anda mal y tal vez se esté produciendo un ataque de intermediario que elimine la información de DNSSEC y modifique los registros A. O bien, podría tratarse de un servidor de nombres dañado que no presta atención a la seguridad y que eliminó el bit de indicador DO de la consulta o el registro RRSIG de la respuesta. O bien, podría tratarse de un error de configuración.
A continuación, puede suceder que no exista un nombre de dominio denominado "www.example.com", en cuyo caso, en lugar de devolver un registro RRSIG en la respuesta, habrá un registro NSEC o un registro NSEC3. Estos son registros "next secure" que permiten al solucionador demostrar que un nombre de dominio no existe. Los registros NSEC/NSEC3 tienen registros RRSIG, que se pueden verificar como se indicó anteriormente.
Por último, puede ser que la zona "example.com" implemente DNSSEC, pero la zona "com" o la zona raíz no, creando una "isla de seguridad" que necesita ser validada de alguna otra manera. El 15 de julio de 2010 [update], se completó la implementación de DNSSEC en la raíz. [8] El dominio .com se firmó con claves de seguridad válidas y la delegación segura se agregó a la zona raíz el 1 de abril de 2011. [9]
Los stub resolvers son "solucionadores DNS mínimos que utilizan el modo de consulta recursiva para descargar la mayor parte del trabajo de resolución DNS a un servidor de nombres recursivo". [10] Un stub resolver simplemente reenviará una solicitud a un servidor de nombres recursivo y utilizará el bit de datos autenticados (AD) en la respuesta como una "pista para averiguar si el servidor de nombres recursivo pudo validar las firmas para todos los datos en las secciones Respuesta y Autoridad de la respuesta". [11] Microsoft Windows utiliza un stub resolver, y Windows Server 2008 R2 y Windows 7 en particular utilizan un stub resolver no validador pero que reconoce el bit AD. [6] [7]
Un solucionador de stub de validación también puede potencialmente realizar su propia validación de firma al configurar el bit de verificación deshabilitada (CD) en sus mensajes de consulta. [11] Un solucionador de stub de validación utiliza el bit CD para realizar su propia autenticación recursiva. El uso de un solucionador de stub de validación de este tipo le brinda al cliente seguridad DNS de extremo a extremo para los dominios que implementan DNSSEC, incluso si el proveedor de servicios de Internet o la conexión a ellos no son confiables.
Los solucionadores de stubs no validadores deben confiar en servicios de validación DNSSEC externos, como los controlados por el proveedor de servicios de Internet del usuario o un servidor de nombres recursivo público , y los canales de comunicación entre él mismo y esos servidores de nombres, utilizando métodos como DNS sobre TLS . [11] [12]
Para poder demostrar que una respuesta de DNS es correcta, es necesario conocer al menos una clave o registro DS que sea correcto a partir de fuentes distintas del DNS. Estos puntos de partida se conocen como puntos de referencia 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 punto de referencia de confianza que se necesitaría era para la raíz del DNS . Los puntos de referencia de la raíz se publicaron por primera vez el 15 de julio de 2010. [13]
Una cadena de autenticación es una serie de registros DS y DNSKEY vinculados, que comienzan con un ancla de confianza al servidor de nombres autorizado para el dominio en cuestión. Sin una cadena de autenticación completa, no se puede autenticar de forma segura una respuesta a una búsqueda de DNS.
Para limitar los ataques de repetición, no solo existen los valores TTL de DNS normales para fines de 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 solucionadores de DNS que se preocupan por la seguridad deben tener relojes que estén bastante sincronizados, por ejemplo, con una diferencia de unos pocos minutos.
Estas marcas de tiempo implican que una zona debe volver a firmarse periódicamente y redistribuirse a servidores secundarios, o los resolutores de validación rechazarán las firmas.
DNSSEC involucra muchas claves diferentes, almacenadas tanto en registros DNSKEY como en otras fuentes para formar anclajes de confianza .
Para permitir el reemplazo de claves, se requiere un esquema de renovación de claves . Por lo general, esto implica primero implementar nuevas claves en nuevos registros DNSKEY, además de las claves antiguas existentes. Luego, cuando sea seguro asumir que los valores de tiempo de vida han hecho que el almacenamiento en caché de las claves antiguas haya expirado, se pueden usar estas nuevas claves. Finalmente, cuando sea seguro asumir que el almacenamiento en caché de los registros que utilizan las claves antiguas ha expirado, se pueden eliminar los registros DNSKEY antiguos. Este proceso es más complicado para cosas como las claves para los anclajes de confianza, como en la raíz, que pueden requerir una actualización del sistema operativo.
Las claves de los registros DNSKEY se pueden utilizar para dos cosas diferentes y, por lo general, se utilizan distintos registros DNSKEY para cada una de ellas. En primer lugar, existen las claves de firma de claves (KSK), que se utilizan para firmar otros registros DNSKEY que contienen claves de firma de zona (ZSK), que se utilizan para firmar otros registros. Dado que las ZSK están bajo el control y el uso completos de una zona DNS en particular , se pueden cambiar con mayor facilidad y frecuencia. Como resultado, las ZSK pueden ser mucho más cortas que las KSK y aún así ofrecer el mismo nivel de protección al tiempo 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 de mensaje de la KSK en lugar de la clave completa para mantener el tamaño de los registros pequeño. 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 las versiones anteriores de DNSSEC que requerían que los registros DNSKEY estuvieran en la zona principal.
Un principio estrechamente relacionado es el de la renovación de algoritmos , que implica migrar una zona de un algoritmo de firma a otro. Un buen ejemplo de esto sería migrar 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 [14] y .ph . Verisign migró .com, .net y .edu al algoritmo 13 a fines de 2023. [15] [16] La migración del dominio raíz del algoritmo 8 al algoritmo 13 está actualmente en planificación para principios de 2024. [17]
La autenticación basada en DNS de entidades nombradas (DANE) es un grupo de trabajo del IETF [18] 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 garantías y restricciones adicionales al modelo tradicional basado en la infraestructura de clave pública . También permitirán a los titulares de dominios hacer valer sus propios certificados, sin necesidad de recurrir a autoridades de certificación de terceros .
La compatibilidad con certificados DNSSEC se habilitó en Google Chrome 14, [19] pero luego se eliminó. [20] Para Mozilla Firefox , la compatibilidad se proporcionó mediante un complemento [21] mientras que el soporte nativo actualmente está esperando que alguien comience a trabajar en él. [22]
El DNS es un servicio fundamental y crítico de Internet, pero en 1990 Steve Bellovin descubrió graves fallos de seguridad en él. Se inició una investigación para protegerlo, que avanzó drásticamente cuando su artículo se hizo público en 1995. [23] La RFC 2065 inicial fue publicada por el IETF en 1997, y los primeros intentos de implementar esa especificación condujeron a una especificación revisada (y que se cree que es totalmente funcional) en 1999, llamada IETF RFC 2535. Se hicieron planes para implementar DNSSEC basándose en la RFC 2535.
Lamentablemente, la especificación IETF RFC 2535 tuvo problemas muy importantes para escalar a Internet en su totalidad; en 2001 se hizo evidente que esta especificación no era utilizable para redes grandes. En funcionamiento normal, los servidores DNS a menudo se desincronizan con sus padres. Esto no suele ser un problema, pero cuando DNSSEC está habilitado, estos datos desincronizados podrían tener el efecto de una denegación de servicio grave autocreada. El DNSSEC original requería un protocolo complejo de seis mensajes y una gran cantidad de transferencias de datos para realizar cambios de clave para un hijo (las zonas secundarias de DNS tenían que enviar todos sus datos al padre, hacer que el padre firmara cada registro y luego enviar esas firmas de vuelta al hijo para que el hijo las almacenara en un registro SIG). Además, los cambios de clave pública podían tener efectos absurdos; por ejemplo, si la zona ".com" cambiaba su clave pública, tendría que enviar 22 millones de registros (porque necesitaría actualizar todas las firmas en todos sus hijos). Por lo tanto, DNSSEC tal como se define en RFC 2535 no podría escalar a Internet.
El IETF modificó fundamentalmente el DNSSEC, que se denomina DNSSEC-bis cuando es necesario para distinguirlo del enfoque DNSSEC original de RFC 2535. Esta nueva versión utiliza "registros de recursos de firmante de delegación (DS)" para proporcionar un nivel adicional de indirección en los puntos de delegación entre una zona principal y una secundaria. En el nuevo enfoque, cuando cambia la clave pública maestra de una secundaria, en lugar de tener seis mensajes para cada registro en la secundaria, hay un mensaje simple: la secundaria envía la nueva clave pública a su principal (firmada, por supuesto). Los principales simplemente almacenan una clave pública maestra para cada secundaria; esto es mucho más práctico. Esto significa que se envían pocos datos al principal, en lugar de intercambiar cantidades masivas de datos entre el principal y los secundarios. Esto significa que los clientes tienen que hacer un poco más de trabajo al verificar las claves. Más específicamente, verificar el conjunto de claves KEY de una zona DNS requiere dos operaciones de verificación de firma en lugar de la requerida por RFC 2535 (no hay impacto en la cantidad de firmas verificadas para otros tipos de conjuntos de claves). La mayoría considera que se trata de un pequeño precio a pagar, ya que hace que la implementación de DNSSEC sea más práctica. La nueva versión se publicó en RFC4033-4035.
En enero de 2024, se anunció un ataque de denegación de servicio "KeyTrap" para todos los resolutores DNSSEC que respetan la especificación. La especificación DNSSEC (RFC4033-4035) especifica que un resolutor, al recibir un paquete firmado desde el upstream, debe probar todas las claves con la "etiqueta" correcta en todas las firmas hasta que una de las combinaciones se verifique correctamente. Al colocar muchas claves con la misma "etiqueta" y muchas firmas correspondientes a esa "etiqueta" en un paquete, los investigadores pueden ralentizar un resolutor en un factor de 2 millones. En respuesta, los resolutores comenzaron a poner límites a la cantidad de errores de verificación, colisiones de etiquetas de clave y cálculos de hash. [24]
Para demostrar criptográficamente la ausencia de un dominio es necesario firmar la respuesta a cada consulta de un dominio inexistente. Esto no es un problema para los servidores de firma en línea, que mantienen sus claves disponibles en línea. Sin embargo, DNSSEC fue diseñado para utilizar computadoras fuera de línea para firmar registros, de modo que las claves de firma de zona se pudieran guardar en un almacenamiento en frío. Esto representa un problema cuando se intenta autenticar las respuestas a consultas de dominios inexistentes, ya que es imposible generar previamente una respuesta a cada posible consulta de nombre de host.
La solución inicial fue crear registros NSEC para cada par de dominios en una zona. De esta manera, si un cliente solicitaba un registro en el inexistente k.example.com, el servidor respondía con un registro NSEC que indicaba que no existe nada entre a.example.comy z.example.com. Sin embargo, esto filtra más información sobre la zona que los errores NXDOMAIN no autenticados tradicionales porque expone la existencia de dominios reales.
Los registros NSEC3 (RFC 5155) se crearon como una alternativa que codifica el nombre en lugar de enumerarlos directamente. Con el tiempo, los avances en el codificado mediante GPU y hardware dedicado significaron que las respuestas NSEC3 podían ser atacadas por la fuerza bruta de manera económica mediante ataques de diccionario fuera de línea. Se propuso NSEC5 para permitir que los servidores autorizados firmen las respuestas NSEC sin tener que mantener una clave privada que pueda usarse para modificar la zona. Por lo tanto, robar una NSEC5KEY solo daría como resultado la capacidad de enumerar una zona más fácilmente. [25]
Debido a la desordenada evolución 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 una denegación de existencia directamente. La técnica descrita en RFC 4470 devuelve un registro NSEC en el que se encuentran los pares de dominios que rodean léxicamente al dominio solicitado. Por ejemplo, la solicitud de k.example.comdaría como resultado un registro NSEC que probaría que no existe nada entre los dominios (ficticios) j.example.comy l.example.com. Esto también es posible con los registros NSEC3. [26]
CloudFlare fue pionero en un par de enfoques alternativos, que logran alcanzar el mismo resultado en un tercio del tamaño de la respuesta. [27] El primero es una variación del enfoque de las "mentiras piadosas", llamado "mentiras negras", que explota el comportamiento común del cliente DNS para indicar la inexistencia de manera más compacta. [28] 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". [29] [27]
Internet es una infraestructura crítica, pero su funcionamiento depende de un sistema DNS fundamentalmente inseguro. Por lo tanto, existe un fuerte incentivo para proteger el DNS, y la implementación de DNSSEC se considera generalmente una parte crítica de ese esfuerzo. Por ejemplo, la Estrategia Nacional de Estados Unidos para Proteger el Ciberespacio identificó específicamente la necesidad de proteger el DNS. [30] La implementación a gran escala de DNSSEC también podría resolver muchos otros problemas de seguridad, como la distribución segura de claves para direcciones de correo electrónico.
La implementación de DNSSEC en redes a gran escala también es un desafío. Ozment y Schechter observan que DNSSEC (y otras tecnologías) tienen un "problema de arranque": los usuarios normalmente solo implementan una tecnología si reciben un beneficio inmediato, pero si se requiere un nivel mínimo de implementación antes de que los usuarios reciban un beneficio mayor que sus costos (como es el caso de DNSSEC), es difícil de implementar. DNSSEC se puede implementar en cualquier nivel de una jerarquía de DNS, pero debe estar ampliamente disponible en una zona antes de que muchos otros quieran adoptarlo. Los servidores DNS se deben actualizar con software que admita DNSSEC, y los datos DNSSEC se deben crear y agregar a los datos de la zona DNS. Un cliente que utiliza TCP/IP debe tener su solucionador DNS (cliente) actualizado antes de poder usar las capacidades de DNSSEC. Es más, cualquier solucionador debe tener, o tener una forma de adquirir, al menos una clave pública en la que pueda confiar antes de poder comenzar a usar DNSSEC.
La implementación de DNSSEC puede agregar una carga significativa a algunos servidores DNS. Las respuestas firmadas DNSSEC comunes son mucho más grandes que el tamaño UDP predeterminado de 512 bytes. En teoría, esto se puede manejar a través de múltiples fragmentos de IP, pero muchos "middleboxes" en el campo no los manejan correctamente. Esto lleva al uso de TCP en su lugar. Sin embargo, muchas implementaciones TCP actuales almacenan una gran cantidad de datos para cada conexión TCP; los servidores altamente cargados pueden quedarse sin recursos simplemente tratando de responder a una mayor cantidad de solicitudes DNSSEC (posiblemente falsas). Se han desarrollado algunas extensiones de protocolo, como TCP Cookie Transactions , para reducir esta carga. [31] Para abordar estos desafíos, se está realizando un esfuerzo significativo para implementar DNSSEC, porque Internet es vital para muchas organizaciones.
Entre los primeros en adoptar esta tecnología se incluyen Brasil ( .br ), Bulgaria ( .bg ), República Checa ( .cz ), Namibia ( .na ) [32] Puerto Rico ( .pr ) y Suecia ( .se ), que utilizan DNSSEC para sus dominios de nivel superior de código de país ; [33] RIPE NCC , que ha firmado todos los registros de búsqueda inversa (in-addr.arpa) que le han sido delegados por la Autoridad de Números Asignados de Internet (IANA). [34] ARIN también está firmando sus zonas inversas. [35] En febrero de 2007, TDC se convirtió en el primer ISP sueco en comenzar a ofrecer esta función a sus clientes. [36]
La IANA ha estado probando públicamente una muestra de raíz firmada desde junio de 2007. Durante este período, antes de la firma de producción de la raíz, también hubo varios anclajes de confianza alternativos. El IKS Jena introdujo uno el 19 de enero de 2006, [37] el Consorcio de Sistemas de Internet introdujo otro el 27 de marzo del mismo año, [38] mientras que la propia ICANN anunció un tercero el 17 de febrero de 2009. [39]
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. [40] Afilias y PIR también detallaron el 26 de septiembre de 2008 que la primera fase, que involucra a los grandes registradores con los que tiene una fuerte relación de trabajo ("amigos y familiares"), sería la primera en poder firmar sus dominios, comenzando "a principios de 2009". [41] El 23 de junio de 2010, 13 registradores fueron listados como proveedores de registros DNSSEC para dominios .ORG. [42]
VeriSign puso en marcha un proyecto piloto para permitir que los dominios .com y .net se registraran a sí mismos 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 [43] y el 16 de noviembre del mismo año, dijeron que los dominios .com y .net estarían firmados en el primer trimestre de 2011, después de retrasos causados por aspectos técnicos de la implementación [44] . Este objetivo se logró según lo previsto [45] y el vicepresidente de DNSSEC de Verisign, Matt Larson, ganó el premio al liderazgo tecnológico de InfoWorld de 2011 por su papel en el avance de DNSSEC [46] [47]
DNSSEC se implementó por primera vez en el nivel raíz el 15 de julio de 2010. [48] Se espera que esto simplifique en gran medida la implementación de los solucionadores DNSSEC, ya que el ancla de confianza raíz se puede utilizar 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 confiable sin interrupción para poder validar, los anclajes de confianza aún deben configurarse para zonas seguras si alguna de las zonas por encima de ellas no es segura. Por ejemplo, si la zona "signed.example.org" estaba protegida pero la zona "example.org" no, 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 en torno a la firma de la raíz han sido una preocupación constante, principalmente en torno a algunas cuestiones centrales:
En septiembre de 2008, la ICANN y VeriSign publicaron sus propuestas de implementación [49] y en octubre, la Administración Nacional de Telecomunicaciones e Información (NTIA) solicitó comentarios del público. [50] No está claro si los comentarios recibidos afectaron el diseño del plan de implementación final.
El 3 de junio de 2009, el Instituto Nacional de Estándares y Tecnología (NIST) anunció planes para firmar la raíz a fines de 2009, junto con ICANN, VeriSign y la NTIA. [51]
El 6 de octubre de 2009, en la 59.ª reunión de la Conferencia RIPE , ICANN y VeriSign anunciaron el cronograma de implementación planificado para implementar DNSSEC dentro de la zona raíz. [52] En la reunión se anunció que se implementaría de manera incremental en un servidor de nombres raíz por mes, a partir del 1 de diciembre de 2009, y que el servidor de nombres raíz final prestaría servicio a una zona firmada con DNSSEC el 1 de julio de 2010, y que la zona raíz se firmaría con una DNSKEY RSA/SHA256. [52] Durante el período de implementación incremental, la zona raíz prestará servicio a una zona raíz deliberadamente no validable (DURZ) que utiliza claves ficticias, y el registro DNSKEY final no se distribuirá hasta el 1 de julio de 2010. [53] Esto significa que las claves que se utilizaron para firmar el uso de la zona son deliberadamente no verificables; el motivo de esta implementación fue monitorear los cambios en los patrones de tráfico causados por las respuestas más grandes a las consultas que solicitan registros de recursos DNSSEC.
El dominio de nivel superior .org se firmó con DNSSEC en junio de 2010, seguido por .com , .net y .edu más tarde en 2010 y 2011. [54] [55] Los dominios de nivel superior de código de país pudieron depositar claves a partir de mayo de 2010. [56] A noviembre de 2011, [update]más del 25% de los dominios de nivel superior están firmados con DNSSEC. [57]
El 25 de enero de 2010, el servidor raíz L (ell) comenzó a prestar servicio a una zona raíz deliberadamente no validable (DURZ). La zona utiliza firmas de un hash SHA-2 (SHA-256) creado con el algoritmo RSA , tal como se define en RFC 5702. A partir de mayo de 2010, los trece servidores raíz comenzaron a prestar servicio a la DURZ. [53] El 15 de julio de 2010, se firmó la primera zona raíz DNSSEC de producción completa, con el número de serie SOA 2010071501. Los anclajes de confianza raíz están disponibles en IANA. [48]
Debajo de la raíz hay un gran 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 a la raíz.
En marzo de 2006, el Consorcio de Sistemas de Internet introdujo el registro DNSSEC Lookaside Validation. [58] 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 una gran cantidad de anclas de confianza correspondientes a subárboles firmados del DNS. [59] El propósito del DLV era permitir que los validadores descargaran 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 utilizar DLV, se necesitaba un validador que lo admitiera, como BIND o Unbound , configurado con un ancla de confianza para una zona DLV. Esta zona contenía registros DLV; [60] estos tenían exactamente el mismo formato que los registros DS, pero en lugar de referirse a una subzona delegada, hacían referencia a una zona en otra parte del árbol DNS. Cuando el validador no pudo encontrar una cadena de confianza desde la raíz hasta el RRset que intenta verificar, buscó un registro DLV que pudiera proporcionar una cadena de confianza alternativa. [61]
Las brechas en la cadena de confianza, como los dominios de nivel superior sin firmar o los registradores que no admitían delegaciones DNSSEC, implicaban que los administradores de dominios de nivel inferior podían usar DLV para permitir que sus datos DNS fueran validados por los resolutores que habían sido configurados para usar DLV. Esto puede haber dificultado la implementación de DNSSEC al quitarle presión a los registradores y registros de TLD para que admitieran DNSSEC correctamente. DLV también agregó complejidad al agregar más actores y rutas de código para la validación de DNSSEC.
ISC desactivó su registro DLV en 2017. [62] La compatibilidad con DLV quedó obsoleta en BIND 9.12 y se eliminó por completo de BIND 9.16. [63] La versión 1.5.4 de Unbound (julio de 2015) marcó a DLV como descontinuado en la página de configuración y manual de ejemplo. [64] Knot Resolver y PowerDNS Recursor nunca implementaron DLV.
En marzo de 2020, la IETF publicó el RFC 8749, retirando DLV como estándar y moviendo el RFC 4432 y el RFC 5074 al estado "Histórico". [65]
La Dirección de Ciencia y Tecnología del Departamento de Seguridad Nacional de los Estados Unidos (DHS) patrocina la "Iniciativa de Implementación 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 cooperativo global que involucra a muchas naciones y organizaciones de los sectores público y privado". El DHS también financia esfuerzos para desarrollar DNSSEC y lograr su implementación dentro del gobierno federal de los Estados Unidos.
Se informó [66] que el 30 de marzo de 2007, el Departamento de Seguridad Nacional de los Estados Unidos propuso "que la clave para firmar la zona raíz del DNS esté firmemente en manos del gobierno de los Estados Unidos". Sin embargo, no había ningún funcionario del gobierno de los Estados Unidos presente en la sala de reuniones y el comentario que dio origen al artículo fue realizado por otra parte. El DHS comentó más tarde [67] [68] sobre por qué creen que otros llegaron a la falsa conclusión de que el gobierno de los Estados Unidos había hecho tal propuesta: "El Departamento de Seguridad Nacional de los Estados Unidos está financiando el desarrollo de un plan técnico para implementar DNSSec, y el pasado mes de octubre distribuyó un borrador inicial del mismo a una larga lista de expertos internacionales para que lo comentaran. El borrador establece una serie de opciones sobre quién podría ser el titular u "operador" de la clave de la zona raíz, que básicamente se reduce 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, el gerente de investigación y desarrollo de ciberseguridad para Seguridad Nacional".
El Instituto Nacional de Normas y Tecnología (NIST) publicó la Publicación Especial NIST 800-81 Guía de Implementación del Sistema de Nombres de Dominio (DNS) Seguro el 16 de mayo de 2006, con orientación sobre cómo implementar DNSSEC. El NIST tenía la intención de publicar los nuevos requisitos de la Ley Federal de Gestión de Seguridad de la Información (FISMA) DNSSEC en 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. [69] 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 que es difícil de implementar correctamente y 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 exige a las agencias federales de los EE. UU. que implementen DNSSEC en todos los sitios .gov; la raíz .gov debe estar firmada antes de enero de 2009, y todos los subdominios bajo .gov deben estar firmados antes de diciembre de 2009. [70] Si bien el memorando se centra en los sitios .gov, la Agencia de Sistemas de Información de Defensa de los EE. UU. dice que tiene la intención de cumplir con los requisitos DNSSEC de la OMB también en el dominio .mil (militar de los EE. UU.). Carolyn Duffy Marsan de NetworkWorld afirmó que DNSSEC "no se ha implementado ampliamente porque sufre un dilema clásico del huevo y la gallina... con el mandato de la OMB, parece que el huevo se está rompiendo". [71]
Varios ISP han comenzado a implementar resolutores recursivos de DNS que validan DNSSEC. Comcast fue el primer ISP importante en hacerlo en los Estados Unidos, anunciando sus intenciones el 18 de octubre de 2010 [72] [73] y completando la implementación el 11 de enero de 2012. [74]
Según un estudio de APNIC , la proporción de clientes que utilizan exclusivamente resolutores DNS que realizan la validación DNSSEC aumentó al 8,3 % en mayo de 2013. [75] Aproximadamente la mitad de estos clientes utilizaban el resolutor DNS público de Google .
En septiembre de 2015, Verisign anunció su servicio gratuito de resolución de DNS público [76] y, aunque no se menciona en sus comunicados de prensa, también realiza la validación DNSSEC.
A principios de 2016, el seguimiento de APNIC mostró que la proporción de clientes que utilizan exclusivamente resolutores DNS que realizan la validación DNSSEC había aumentado a aproximadamente el 15%. [77]
El servidor DNS recursivo público de Google habilitó la validación DNSSEC el 6 de mayo de 2013. [78]
BIND , el software de gestión de DNS más popular, habilita la compatibilidad con DNSSEC de forma predeterminada desde la versión 9.5.
El DNS recursivo público Quad9 ha realizado la validación DNSSEC en su dirección principal 9.9.9.9 desde que se estableció el 11 de mayo de 2016. Quad9 también proporciona un servicio alternativo que no realiza la validación DNSSEC, principalmente para depuración. [79]
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. [80]
Geoff Hutson ha argumentado que se debería abandonar la implementación de DNSSEC. [81]
La implementación de DNSSEC requiere software en el servidor y en el cliente. Algunas de las herramientas que admiten DNSSEC son:
El cliente DNS de Windows es un solucionador de stubs...
El cliente DNS en Windows Server 2008 R2 y Windows® 7 es un solucionador de código auxiliar que no realiza validaciones y tiene en cuenta la seguridad.
Los solucionadores de stub, por definición, son solucionadores de DNS mínimos que utilizan el modo de consulta recursiva para descargar la mayor parte del trabajo de resolución de DNS a un servidor de nombres recursivo.Una definición anterior se dio en un RFC anterior: Robert Braden (octubre de 1989). Braden, R. (ed.). RFC 1123 - Requisitos para hosts de Internet: aplicación y soporte. IETF ( Internet Engineering Task Force ). p. 74. doi :10.17487/RFC1123.
Un "stub resolver" depende de los servicios de un servidor de nombres recursivo [...]