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 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 agregar seguridad, manteniendo al mismo tiempo la compatibilidad con versiones anteriores . RFC 3833 de 2004 documenta algunas de las amenazas conocidas al DNS y sus soluciones en DNSSEC.
DNSSEC fue diseñado para proteger las aplicaciones que usan DNS para que no acepten datos DNS falsificados o manipulados, como los creados por el envenenamiento de la caché de DNS . Todas las respuestas de las zonas protegidas DNSSEC están firmadas digitalmente . [1] Al verificar la firma digital, un solucionador de 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 entregada en un servidor DNS autorizado. Si bien proteger las direcciones IP es la preocupación inmediata de muchos usuarios, DNSSEC puede proteger cualquier dato publicado en el DNS, incluidos registros de texto (TXT) y registros de intercambio de correo (MX), y puede usarse para iniciar otros sistemas de seguridad que publican referencias a datos criptográficos. certificados 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 cliente cifrado. (Registros SVCB/HTTPS para ECH [2] [3] ).
DNSSEC no proporciona confidencialidad de datos; en particular, todas las respuestas DNSSEC están autenticadas pero no cifradas. DNSSEC no protege directamente contra ataques DoS , aunque indirectamente proporciona algún beneficio (porque la verificación de firmas permite el uso de partes potencialmente no confiables). [ cita necesaria ]
Se utilizan otros estándares (no DNSSEC) para proteger 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 realmente provienen del propietario del dominio o no están disponibles en él. [ cita necesaria ]
Las especificaciones DNSSEC (llamadas DNSSEC-bis ) describen con gran detalle el protocolo DNSSEC actual. Consulte RFC 4033, RFC 4034 y RFC 4035. Con la publicación de estos nuevos RFC (marzo de 2005), un RFC anterior, el RFC 2535, quedó obsoleto. El conjunto completo de RFC que especifican DNSSEC se recopila en RFC 9364, que también es BCP 237.
Se cree ampliamente [4] que proteger el DNS es de vital importancia para proteger Internet en su conjunto, pero la implementación de DNSSEC específicamente se ha visto obstaculizada (al 22 de enero de 2010 [update]) por varias dificultades:
DNSSEC funciona mediante la firma digital de registros para la búsqueda de DNS mediante criptografía de clave pública . El registro DNSKEY correcto se autentica a través de una cadena de confianza , comenzando con un conjunto de claves públicas verificadas para la zona raíz del DNS , que es el tercero de confianza . Los propietarios de dominios generan sus propias claves y las cargan usando 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 zona (por ejemplo, Verisign para .com) quien las firma y publica en DNS.
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 de DNS contiene un registro DNS RRSIG, además del tipo de registro que se solicitó. El registro RRSIG es una firma digital del conjunto de registros de recursos DNS de respuesta . La firma digital se verifica localizando 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 sólida resistencia 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 otros nuevos de manera compatible con versiones anteriores, como se describe en RFC 8624. La siguiente tabla define, a partir de junio de 2019, los algoritmos de seguridad que son o fueron más utilizado: [5]
A partir de los resultados de una búsqueda de DNS, un solucionador de DNS consciente de la seguridad puede determinar si el servidor de nombres autorizado para el dominio que se consulta 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 servidores de nombres recursivos , como los de muchos ISP , y para resolutores de código auxiliar , como los incluidos de forma predeterminada en los sistemas operativos convencionales. Microsoft Windows utiliza un solucionador de código auxiliar, y Windows Server 2008 R2 y Windows 7 en particular utilizan un solucionador de código auxiliar que no valida pero que admite DNSSEC. [6] [7]
Usando el modelo de cadena de confianza , se puede usar 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 subdominios adicionales. Digamos que un solucionador recursivo, como un servidor de nombres ISP, desea obtener las direcciones IP ( registro A y/o registros AAAA ) del dominio "www.example.com " .
Hay varias excepciones al ejemplo anterior.
Primero, si "example.com" no admite DNSSEC, no habrá ningún registro RRSIG en la respuesta y no habrá un registro DS para "example.com" en la zona "com". Si hay un registro DS para "example.com", pero no hay un registro RRSIG en la respuesta, algo anda mal y tal vez se esté produciendo un ataque de intermediario , eliminando la información DNSSEC y modificando los registros A. O podría ser un servidor de nombres roto y ajeno a la seguridad en el camino que eliminó el bit del indicador DO de la consulta o el registro RRSIG de la respuesta. O podría ser un error de configuración.
A continuación, puede ser que no haya un nombre de dominio llamado "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 "próximos seguros" 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 indica arriba.
Finalmente, 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. A partir del 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 solucionadores de código auxiliar son "resolutores 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". [10] Un solucionador de código auxiliar 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 solucionador de código auxiliar, y Windows Server 2008 R2 y Windows 7 en particular utilizan un solucionador de código auxiliar que no valida pero que admite bits de AD. [6] [7]
Un solucionador de código auxiliar de validación también puede realizar su propia validación de firma configurando el bit Comprobación deshabilitada (CD) en sus mensajes de consulta. [11] Un solucionador de código auxiliar de validación utiliza el bit de CD para realizar su propia autenticación recursiva. El uso de un solucionador de código auxiliar de validación 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 resolutores de stub no validados deben depender de 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 ellos 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 de fuentes distintas al DNS. Estos puntos de partida se conocen como anclajes de confianza y normalmente se obtienen con el sistema operativo o mediante alguna otra fuente confiable. Cuando se diseñó originalmente DNSSEC, se pensó que el único ancla de confianza que se necesitaría sería la raíz DNS . Los anclajes de 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, una respuesta a una búsqueda de DNS no se puede autenticar de forma segura.
Para limitar los ataques de reproducció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 conscientes de la seguridad deben tener relojes que estén bastante sincronizados, digamos en unos pocos minutos.
Estas marcas de tiempo implican que una zona debe volver a firmarse y redistribuirse periódicamente a servidores secundarios, o las firmas serán rechazadas por los resolutores de validación.
DNSSEC implica muchas claves diferentes, almacenadas tanto en registros DNSKEY como de otras fuentes para formar anclajes de confianza .
Para permitir el reemplazo de claves, se requiere un esquema de transferencia de claves . Normalmente, esto implica implementar primero 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 provocado que el almacenamiento en caché de las claves antiguas haya pasado, se podrán utilizar estas nuevas claves. Finalmente, cuando sea seguro asumir que el almacenamiento en caché de los registros que utilizan las claves antiguas ha caducado, los registros DNSKEY antiguos se pueden eliminar. Este proceso es más complicado para cosas como las claves para confiar en los anclajes, 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 cosas diferentes y, por lo general, se usan registros DNSKEY diferentes para cada una. En primer lugar, existen 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 control total y son utilizadas por una zona DNS en particular , se pueden cambiar más fácilmente y con mayor frecuencia. Como resultado, las ZSK pueden ser mucho más cortas que las KSK y seguir ofreciendo 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 mensajes de la KSK en lugar de la clave completa para mantener pequeño el tamaño de los registros. 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 sustitución del algoritmo , 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 finales de 2023. [15] [16] La migración del dominio raíz del algoritmo 8 al algoritmo 13 está actualmente en planificación a principios de 2024. [17]
La autenticación de entidades nombradas basada en DNS (DANE) es un grupo de trabajo del IETF [18] con el objetivo de 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 para el modelo tradicional basado en infraestructura de clave pública . También permitirán a los titulares de dominios hacer valer sus propios certificados, sin referencia a autoridades certificadoras de terceros .
La compatibilidad con certificados grapados DNSSEC se habilitó en Google Chrome 14, [19] pero luego se eliminó. [20] Para Mozilla Firefox , el soporte lo proporcionó un complemento [21] mientras que el soporte nativo actualmente está esperando que alguien comience a trabajar en él. [22]
DNS es un servicio de Internet fundamental y crítico; sin embargo, en 1990 Steve Bellovin descubrió graves fallas de seguridad en él. La investigación para asegurarlo comenzó y progresó dramáticamente cuando su artículo se hizo público en 1995. [23] El RFC 2065 inicial fue publicado por el IETF en 1997, y los intentos iniciales de implementar esa especificación condujeron a una revisión (y se cree que es completamente viable). especificación en 1999 como IETF RFC 2535. Se hicieron planes para implementar DNSSEC basado en RFC 2535.
Desafortunadamente, la especificación IETF RFC 2535 tuvo problemas muy importantes para ampliarse a Internet completo; en 2001 quedó claro que esta especificación no era utilizable para redes grandes. En funcionamiento normal, los servidores DNS a menudo no están sincronizados con sus padres. Esto no suele ser un problema, pero cuando DNSSEC está habilitado, estos datos no sincronizados podrían tener el efecto de una denegación de servicio grave creada por uno mismo. El DNSSEC original requería un protocolo complejo de seis mensajes y muchas transferencias de datos para realizar cambios clave para un niño (las zonas DNS secundarias tenían que enviar todos sus datos al padre, hacer que el padre firmara cada registro y luego enviarlos). firmas al niño para que las almacene en un registro SIG). Además, los cambios de clave pública podrían tener efectos absurdos; por ejemplo, si la zona ".com" cambiara su clave pública, tendría que enviar 22 millones de registros (porque necesitaría actualizar todas las firmas de todos sus hijos). Por lo tanto, DNSSEC tal como se define en RFC 2535 no podría ampliarse a Internet.
El IETF modificó fundamentalmente 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 del firmante de delegación (DS)" para proporcionar un nivel adicional de direccionamiento indirecto en los puntos de delegación entre una zona para padres e hijos. En el nuevo enfoque, cuando la clave pública maestra de un niño cambia, en lugar de tener seis mensajes para cada registro en el niño, hay un mensaje simple: el niño envía la nueva clave pública a su padre (firmada, por supuesto). Los padres simplemente almacenan una clave pública maestra para cada niño; esto es mucho más práctico. Esto significa que se envían algunos datos a los padres, en lugar de que se intercambien cantidades masivas de datos entre padres e hijos. Esto significa que los clientes tienen que trabajar un poco más al verificar las claves. Más específicamente, verificar el RRset 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 RRset). La mayoría ve esto como un pequeño precio a pagar, ya que hace que la implementación de DNSSEC sea más práctica. La nueva versión está publicada en RFC4033-4035.
En enero de 2024, se anunció un ataque de denegación de servicio "KeyTrap" para todos los solucionadores DNSSEC que respetan las especificaciones. La especificación DNSSEC (RFC4033-4035) especifica que un solucionador, al recibir un paquete firmado desde el flujo ascendente, debe probar todas las claves con la "etiqueta" correcta en todas las firmas hasta que una de las combinaciones se verifique con éxito. Al poner muchas claves con la misma "etiqueta" y muchas firmas correspondientes a esa "etiqueta" en un paquete, los investigadores pueden ralentizar un solucionador en un factor de 2 millones. En respuesta, los resolutores comenzaron a imponer límites a la cantidad de errores de verificación, colisiones de etiquetas clave y cálculos 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 se diseñó en torno al uso de computadoras fuera de línea para firmar registros, de modo que las claves de firma de zona pudieran mantenerse en almacenamiento en frío. Esto representa un problema al intentar autenticar respuestas a consultas de dominios inexistentes, ya que es imposible generar previamente una respuesta para cada posible consulta de nombre de host.
La solución inicial fue crear registros NSEC para cada par de dominios en una zona. Por lo tanto, si un cliente solicita un registro en el lugar inexistente k.example.com, el servidor responderá con un registro NSEC indicando 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 tradicionales de NXDOMAIN no autenticados 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 hashing mediante el uso de GPU y hardware dedicado significaron que las respuestas NSEC3 podían ser forzadas de forma económica mediante ataques de diccionario fuera de línea. Se ha propuesto NSEC5 para permitir que los servidores autorizados firmen 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 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 una negación de existencia directamente. La técnica descrita en RFC 4470 devuelve un registro NSEC en el que los pares de dominios rodean léxicamente al dominio solicitado. Por ejemplo, la solicitud de k.example.comdaría lugar a un registro NSEC que demostraría que no existe nada entre los dominios (ficticios) j.example.comy l.example.com. Esto también es posible con registros NSEC3. [26]
CloudFlare fue pionero en un par de enfoques alternativos, que logran lograr el mismo resultado en un tercio del tamaño de la respuesta. [27] La primera es una variación del enfoque de "mentiras piadosas", llamado "mentiras negras", que explota el comportamiento común de los clientes DNS para declarar 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 llaman "escopeta DNS". [29] [27]
Internet es una infraestructura crítica, pero su funcionamiento depende del DNS fundamentalmente inseguro. Por lo tanto, existe un fuerte incentivo para proteger el DNS y, en general, se considera que la implementación de DNSSEC es una parte fundamental 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 de gran escala también supone un desafío. Ozment y Schechter observan que DNSSEC (y otras tecnologías) tienen un "problema de arranque": los usuarios normalmente sólo implementan una tecnología si reciben un beneficio inmediato, pero si se requiere un nivel mínimo de implementación antes de que cualquier usuario reciba un beneficio mayor que sus costos. (como ocurre con DNSSEC), es difícil de implementar. DNSSEC se puede implementar en cualquier nivel de la jerarquía DNS, pero debe estar ampliamente disponible en una zona antes de que muchos otros quieran adoptarlo. Los servidores DNS deben actualizarse con software que admita DNSSEC, y los datos DNSSEC deben crearse y agregarse a los datos de la zona DNS. Un cliente que utiliza TCP/IP debe tener actualizado su solucionador de DNS (cliente) antes de poder utilizar 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 utilizar DNSSEC.
La implementación de DNSSEC puede agregar una carga significativa a algunos servidores DNS. Las respuestas comunes firmadas por DNSSEC 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 muchas "cajas intermedias" 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 muy cargados pueden quedarse sin recursos simplemente al intentar 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án realizando esfuerzos significativos para implementar DNSSEC, porque Internet es vital para muchas organizaciones.
Los primeros usuarios incluyen Brasil ( .br ), Bulgaria ( .bg ), República Checa ( .cz ), Namibia ( .na ) [32] Puerto Rico ( .pr ) y Suecia ( .se ), que utilizan DNSSEC para su código de país. dominios de nivel superior ; [33] RIPE NCC , que ha firmado todos los registros de búsqueda inversa (in-addr.arpa) que le son 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 empezar a ofrecer esta característica a sus clientes. [36]
La 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 varios anclajes de confianza alternativos. El IKS Jena introdujo uno el 19 de enero de 2006, [37] el Internet Systems Consortium 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 del Registro de Interés Público firmó el TLD .org. [40] 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 fuerte relación de trabajo ("amigos y familiares"), sería la primera en poder firmar sus dominios, comenzando " principios de 2009". [41] El 23 de junio de 2010, 13 registradores figuraban en la lista que ofrecían registros DNSSEC para dominios .ORG. [42]
VeriSign ejecutó 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.) dentro de 24 meses, [43] y el 16 de noviembre del mismo año, dijeron que . com y .net se firmarían en el primer trimestre de 2011, después de retrasos causados por aspectos técnicos de la implementación. [44] Este objetivo se logró a tiempo [45] y el vicepresidente de DNSSEC de Verisign, Matt Larson, ganó el premio al liderazgo tecnológico de InfoWorld en 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 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 se debe rastrear hasta una raíz confiable sin interrupción para poder validarla, los anclajes de confianza aún deben configurarse para zonas seguras si alguna de las zonas superiores a ellas no lo es. 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 en para validar la zona.
Las cuestiones políticas en torno a la firma de la raíz han sido una preocupación continua, principalmente sobre algunas cuestiones centrales:
En septiembre de 2008, ICANN y VeriSign publicaron propuestas de implementación [49] y en octubre, la Administración Nacional de Información y Telecomunicaciones (NTIA) pidió comentarios al público. [50] No está claro si los comentarios recibidos afectaron el diseño del plan de despliegue 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 finales de 2009, en conjunto 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 incrementalmente en un servidor de nombres raíz por mes, a partir del 1 de diciembre de 2009, con el servidor de nombres raíz final sirviendo una zona firmada DNSSEC el 1 de julio de 2010, y el servidor raíz La zona se firmará con una clave DNS 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 señalar el uso de la zona y no son deliberadamente 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 posteriormente en 2010 y 2011. [54] [55] Los dominios de nivel superior con código de país pudieron depositar claves a partir de en mayo de 2010. [56] En 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 servicios en una zona raíz deliberadamente no validable (DURZ). La zona utiliza firmas de un hash SHA-2 (SHA-256) creado utilizando el algoritmo RSA , tal como se define en RFC 5702. En mayo de 2010, los trece servidores raíz comenzaron a prestar servicios en DURZ. [53] El 15 de julio de 2010, se firmó la primera zona raíz DNSSEC de producción completa, con la serie SOA 2010071501. Los anclajes de confianza raíz están disponibles en la IANA. [48]
Debajo de la raíz hay un gran conjunto de dominios de nivel superior que deben firmarse para lograr una implementación DNSSEC completa. 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 Internet Systems Consortium introdujo el registro DNSSEC Lookaside Validation. [58] DLV tenía como objetivo hacer que DNSSEC fuera más fácil de implementar en ausencia de un ancla de confianza raíz. En ese momento se imaginó que un validador podría tener que mantener una gran cantidad de anclajes de confianza correspondientes a subárboles firmados del DNS. [59] El propósito de DLV era permitir a los validadores descargar el esfuerzo de administrar un repositorio de anclaje de confianza a un tercero confiable. El registro DLV mantuvo una lista central de anclajes 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 soportara, 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, se referían 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 dominios de nivel superior no firmados o registradores que no admitían delegaciones DNSSEC, significaban que los administradores de dominios de nivel inferior podían usar DLV para permitir que sus datos DNS fueran validados por solucionadores que habían sido configurados para usar DLV. . Esto puede haber obstaculizado la implementación de DNSSEC al quitar presión a los registradores y registros de TLD para que admitan adecuadamente DNSSEC. DLV también agregó complejidad al agregar más actores y rutas de código para la validación de DNSSEC.
ISC dio de baja 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 (julio de 2015) de Unbound marcó a DLV como fuera de servicio en la configuración de ejemplo y en la página del manual. [64] Knot Resolver y PowerDNS Recursor nunca implementaron DLV.
En marzo de 2020, el IETF publicó RFC 8749, retirando DLV como estándar y moviendo RFC 4432 y RFC 5074 al estado "Histórico". [65]
La Dirección de Ciencia y Tecnología del Departamento de Seguridad Nacional (DHS) de EE. UU. patrocina la "Iniciativa de implementación DNSSEC". Esta iniciativa alienta "a todos los sectores a adoptar voluntariamente medidas de seguridad que mejorarán 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 madurar DNSSEC e implementarlo dentro del gobierno federal de EE. UU.
Se informó [66] 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 sólidamente en manos del gobierno de EE.UU." Sin embargo, ningún funcionario del gobierno de Estados Unidos estuvo presente en la sala de reuniones y el comentario que provocó el artículo fue hecho por otra parte. Más tarde, el DHS comentó [67] [68] sobre por qué creen que otros llegaron a la falsa conclusión de que el gobierno de los EE. UU. había hecho tal propuesta: "El Departamento de Seguridad Nacional de los EE. UU. está financiando el desarrollo de un plan técnico para implementar DNSSec, y por último October distribuyó un borrador inicial a una larga lista de expertos internacionales para que realizaran comentarios. 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, reduciéndose esencialmente a una agencia gubernamental. o un contratista "En ninguna parte del documento hacemos ninguna propuesta sobre la identidad del operador de clave raíz", dijo Maughan, gerente de investigación y desarrollo de seguridad cibernética de Seguridad Nacional.
El Instituto Nacional de Estándares y Tecnología (NIST) publicó la Guía de implementación del sistema de nombres de dominio (DNS) seguro, publicación especial 800-81 del NIST, el 16 de mayo de 2006, con orientación sobre cómo implementar DNSSEC. NIST tenía la intención de publicar nuevos requisitos de la Ley Federal de Gestión de Seguridad de la Información (FISMA) de 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 FISMA. [69] Sin embargo, en ese momento NSEC3 no se había completado. NIST había sugerido utilizar 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 mencionadas anteriormente.
El 22 de agosto de 2008, la Oficina de Gestión y Presupuesto (OMB) publicó un memorando que exige a las agencias federales de EE. UU. implementar DNSSEC en todos los sitios .gov; la raíz .gov debe firmarse antes de enero de 2009, y todos los subdominios bajo .gov deben firmarse 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 EE. UU. dice que tiene la intención de cumplir con los requisitos DNSSEC de la OMB. también en el dominio .mil (militar estadounidense). Carolyn Duffy Marsan, de NetworkWorld, afirmó que DNSSEC "no se ha implementado ampliamente porque sufre el clásico dilema 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 solucionadores recursivos de DNS que validan DNSSEC. Comcast se convirtió en 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 solucionadores de DNS que realizan validación DNSSEC aumentó al 8,3% en mayo de 2013. [75] Aproximadamente la mitad de estos clientes utilizaban el solucionador de DNS público de Google .
En septiembre de 2015, Verisign anunció su servicio público gratuito de resolución de DNS [76] y, aunque no lo menciona en sus comunicados de prensa, también realiza validación DNSSEC.
A principios de 2016, el monitoreo de APNIC mostró que la proporción de clientes que utilizan exclusivamente solucionadores de DNS que realizan 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 de Quad9 ha realizado la validación de 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 de 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 el despliegue de DNSSEC. [81]
La implementación de DNSSEC requiere software en el lado del servidor y del cliente. Algunas de las herramientas que admiten DNSSEC incluyen:
El cliente DNS de Windows es un solucionador de código auxiliar...
El cliente DNS en Windows Server 2008 R2 y Windows® 7 es un solucionador de código auxiliar que no valida la seguridad.
Los solucionadores de código auxiliar, 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 ( Grupo de Trabajo de Ingeniería de Internet ). pag. 74. doi : 10.17487/RFC1123.
Un "stub resolve" depende de los servicios de un servidor de nombres recursivo [...]