DNSSEC

Las Extensiones de seguridad del sistema de nombres de dominio o DNSSEC por sus siglas en inglés Domain Name System Security Extensions 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, negación de existencia autenticada e integridad de datos, pero no disponibilidad ni confidencialidad.

Visión general

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 la compatibilidad con versiones anteriores. La solicitud de comentarios 3833 documenta algunas de las amenazas conocidas para el DNS y sus soluciones en DNSSEC.

DNSSEC se diseñó para proteger las aplicaciones que usan DNS de aceptar datos de DNS falsificados o manipulados, como los creados por el envenenamiento de caché de DNS. Todas las respuestas de las zonas protegidas DNSSEC están firmadas digitalmente. Al verificar la firma digital, un resolutor de DNS puede verificar si la información es idéntica (es decir, sin modificar 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 las 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 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 dactilares SSH (SSHFP, RFC 4255), claves públicas IPSec (IPSECKEY,).

DNSSEC no proporciona confidencialidad de datos; en particular, todas las respuestas DNSSEC están autenticadas pero no encriptadas. DNSSEC no protege contra los ataques DoS directamente, aunque indirectamente brinda algún beneficio (porque la verificación de firmas permite el uso de partes potencialmente no confiables).

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 IETF RFC 4367, algunos usuarios y desarrolladores hacen suposiciones falsas sobre los nombres de 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 no están disponibles.

Las especificaciones DNSSEC (llamadas DNSSEC-bis) describen el protocolo DNSSEC actual con gran detalle. 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.

Se cree ampliamente 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 (a partir del 22 de enero de 2010) por varias dificultades:

• La necesidad de diseñar un estándar compatible con versiones anteriores que pueda escalar al tamaño de Internet
• Prevención de "enumeración de zonas" donde se desee
• Despliegue de implementaciones de DNSSEC en una amplia variedad de servidores DNS y resolutores (clientes)
• Desacuerdo entre los implementadores sobre quién debe poseer las claves raíz del dominio de nivel superior
• Superar la complejidad percibida del despliegue de DNSSEC y DNSSEC

Operación

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 mediante una cadena de confianza, que comienza 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 utilizando su panel de control de 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 (p. ej., Verisign para.com) que las firma y publica en DNS.

Registros de recursos

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 usar con DNSSEC:RRSIG (firma de registro de recursos)Contiene la firma DNSSEC para un conjunto de registros. Los resolutores de DNS verifican la firma con una clave pública, almacenada en un registro DNSKEY.DNSKEYContiene la clave pública que utiliza un solucionador de DNS para verificar las firmas DNSSEC en los registros RRSIG.DS (firmante de la delegación)Contiene el nombre de una zona delegada. Hace referencia a un registro DNSKEY en la zona subdelegada. El registro DS se coloca en la zona principal junto con los registros NS delegadores.NSEC (próximo registro seguro)Contiene un enlace al siguiente nombre de registro en la zona y enumera los tipos de registro que existen para el nombre del registro. Los resolutores de DNS utilizan registros NSEC para verificar la inexistencia de un nombre y tipo de registro como parte de la validación de DNSSEC.NSEC3 (siguiente registro seguro versión 3)Contiene enlaces al siguiente nombre de registro en la zona (en orden de clasificación de nombre con hash) y enumera los tipos de registro que existen para el nombre cubierto por el valor hash en la primera etiqueta del nombre propio del registro NSEC3. Estos registros pueden ser utilizados por los resolutores para verificar la inexistencia de un nombre y tipo de registro como parte de la validación de DNSSEC. Los registros NSEC3 son similares a los registros NSEC, pero NSEC3 utiliza nombres de registros con hash criptográfico para evitar la enumeración de los nombres de registros en una zona.NSEC3PARAM (parámetros de la versión 3 del siguiente registro seguro)Los servidores DNS autorizados usan este registro para calcular y determinar qué registros NSEC3 incluir en las respuestas a las solicitudes de DNSSEC para nombres/tipos no existentes.

Cuando se usa DNSSEC, cada respuesta a una búsqueda de DNS contiene un registro de 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 una resistencia robusta contra la suplantación de identidad.

Algoritmos

DNSSEC fue diseñado para ser extensible, de modo que a medida que se descubren ataques contra algoritmos existentes, se pueden introducir nuevos de manera compatible con versiones anteriores. La siguiente tabla define, a partir de abril de 2013, los algoritmos de seguridad que se utilizan con mayor frecuencia:

campo de algoritmo	Algoritmo	Fuente	Firma DNSSEC	Validación DNSSEC
1	RSA/MD5		No debe implementar	No debe implementar
3	DSA/SHA-1		No debe implementar	No debe implementar
5	RSA/SHA-1	RFC 3110	No recomendado	Requerido
6	DSA-NSEC3-SHA1		No debe implementar	No debe implementar
7	RSASHA1-NSEC3-SHA1	RFC 5155	No recomendado	Requerido
8	RSA/SHA-256	RFC 5702	Requerido	Requerido
10	RSA/SHA-512	No recomendado	Requerido
12	GOST R 34.10-2001	RFC 5933	No debe implementar	Opcional
13	ECDSA/SHA-256	RFC 6605	Requerido	Requerido
14	ECDSA/SHA-384	Opcional	Recomendado
15	Ed25519	RFC 8080	Recomendado	Recomendado
dieciséis	Ed448	Opcional	Recomendado

campo de resumen	Digerir	Fuente	Estado de implementación
1	SHA-1	RFC 3658	Requerido
2	SHA-256	RFC 4509	Requerido
3	GOST R 34.10-2001	RFC 5933	Opcional
4	SHA-384	RFC 6605	Opcional

El procedimiento de consulta

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 es compatible con 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 resolutores de stub, como los que se incluyen de forma predeterminada en los sistemas operativos principales. Microsoft Windows usa un resolutor de stub, y Windows Server 2008 R2 y Windows 7 en particular usan un resolutor de stub que no valida pero reconoce DNSSEC.

Servidores de nombres recursivos

Con 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 más subdominios. Digamos que una resolución recursiva, como un servidor de nombres ISP, desea obtener las direcciones IP (registro A y/o registros AAAA) del dominio "www.example.com".

1. El proceso comienza cuando un resolutor consciente de la seguridad establece el bit indicador "DO" ("DNSSEC OK") en una consulta de DNS. Dado que el bit DO se encuentra en los bits de bandera extendidos definidos por los Mecanismos de extensión para DNS (EDNS), todas las transacciones de DNSSEC deben ser compatibles con EDNS. El soporte de EDNS también es necesario para permitir tamaños de paquete mucho más grandes que requieren las transacciones de DNSSEC.
2. Cuando el resolutor recibe una respuesta a través del proceso normal de búsqueda de DNS, verifica para asegurarse de que la respuesta sea correcta. Idealmente, la resolución consciente de la seguridad comenzaría con la verificación de los registros DS y DNSKEY en la raíz DNS. Luego, usaría los registros DS para el dominio de nivel superior "com" que se encuentra en la raíz para verificar los registros DNSKEY en la zona "com". A partir de ahí, vería si hay un registro DS para el subdominio "example.com" en la zona "com", y si lo hubiera, usaría el registro DS para verificar un registro DNSKEY encontrado en el "example. zona com". Finalmente, verificaría el registro RRSIG que se encuentra en la respuesta de los registros A para "www.example.com".

Hay varias excepciones al ejemplo anterior.

Primero, si "example.com" no es compatible con DNSSEC, no habrá un 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 intermediario, eliminando la información DNSSEC y modificando los registros A. O bien, podría ser un servidor de nombres ajeno a la seguridad roto en el camino que eliminó el bit de indicador DO de la consulta o el registro RRSIG de la respuesta. O bien, 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 los registros "siguientes seguros" que permiten que el resolutor demuestre que un nombre de dominio no existe. Los registros NSEC/NSEC3 tienen registros RRSIG, que se pueden verificar como se indicó anteriormente.

Finalmente, puede ser que la zona "example.com" implemente DNSSEC, pero la zona "com" o la zona raíz no lo hagan, creando una "isla de seguridad" que debe validarse de alguna otra manera. A partir del 15 de julio de 2010, se completó la implementación de DNSSEC en la raíz. 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.

Resolutores de código auxiliar

Los resolutores de stub 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". Un resolutor de código auxiliar simplemente enviará 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 firmas para todos los datos en el las secciones Respuesta y Autoridad de la respuesta". Microsoft Windows usa un resolutor de stub, y Windows Server 2008 R2 y Windows 7 en particular usan un resolutor de stub que no valida pero reconoce los bits de AD.

Un resolutor de código auxiliar de validación también puede potencialmente realizar su propia validación de firma configurando el bit Comprobación deshabilitada (CD) en sus mensajes de consulta. Un resolutor de código auxiliar de validación utiliza el bit de CD para realizar su propia autenticación recursiva. El uso de un resolutor de stub de validación le brinda al cliente seguridad de 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 de confianza.

Los resolutores de stubs que no validan deben confiar en los servicios de validación de 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.

Anclajes de confianza y cadenas de autenticación

Para poder probar que una respuesta DNS es correcta, se necesita saber 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, por lo general, 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 era para la raíz del DNS. Los anclajes de raíz se publicaron por primera vez el 15 de julio de 2010.

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.

Firmas y firma de zona

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 resolutores de DNS conscientes de la seguridad deben tener relojes que estén bastante sincronizados, digamos dentro de unos pocos minutos.

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

Gestión de claves

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

Para permitir el reemplazo de llaves, se requiere un esquema de transferencia de llaves. 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 causado que haya pasado el almacenamiento en caché de las claves antiguas, se pueden usar estas nuevas claves. Finalmente, cuando es 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 diferentes registros DNSKEY para cada una. En primer lugar, existen claves de firma de claves (KSK) que se utilizan para firmar otros registros DNSKEY. En segundo lugar, existen claves de firma de zona (ZSK) que se utilizan para firmar otros registros. Dado que los ZSK están bajo control completo y son utilizados 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 aun así ofrecer el mismo nivel de protección mientras se reduce 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 pequeño el tamaño de los registros. Esto es ú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 simple que las versiones anteriores de DNSSEC que requerían que los registros DNSKEY estuvieran en la zona principal.

Grupo de Trabajo DANE

La autenticación de entidades nombradas (DANE) basada en DNS es un grupo de trabajo del IETF 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 para el modelo tradicional basado en infraestructura de clave pública. También permitirán a los titulares de dominios afirmar certificados por sí mismos, sin referencia a autoridades de certificación de terceros.

La compatibilidad con los certificados engrapados de DNSSEC se habilitó en Google Chrome 14, pero luego se eliminó. Para Mozilla Firefox, el soporte fue proporcionado por un complemento, mientras que el soporte nativo actualmente está esperando que alguien comience a trabajar en él.

Historia

El DNS es un servicio de Internet crítico y fundamental, pero en 1990 Steve Bellovin descubrió en él graves fallas de seguridad. La investigación para asegurarlo comenzó y progresó dramáticamente cuando su artículo se hizo público en 1995. El RFC 2065 inicial fue publicado por el IETF en 1997, y los intentos iniciales de implementar esa especificación llevaron a una especificación revisada (y que se creía totalmente funcional) en 1999. como IETF RFC 2535. Se hicieron planes para implementar DNSSEC basados ​​en RFC 2535.

Desafortunadamente, la especificación IETF RFC 2535 tuvo problemas muy importantes para escalar a Internet completo; en 2001 quedó claro que esta especificación no se podía utilizar 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 grave denegación de servicio autocreada. El DNSSEC original requería un protocolo complejo de seis mensajes y muchas transferencias de datos para realizar cambios 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 esos firmas al niño para que el niño 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" cambió 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 podía escalar a Internet.

El IETF modificó fundamentalmente DNSSEC, que se llama DNSSEC-biscuando sea 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 direccionamiento indirecto 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 un niño, 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 (firmado, 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ía una pequeña cantidad de datos al padre, en lugar de que se intercambien cantidades masivas de datos entre el padre y los hijos. Esto significa que los clientes tienen que hacer un poco más de trabajo al verificar las claves. Más específicamente, verificar una zona DNS' s KEY RRset requiere dos operaciones de verificación de firmas en lugar de la requerida por RFC 2535 (no hay impacto en el número de firmas verificadas para otros tipos de RRsets). 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.

Autenticación de respuestas NXDOMAIN y NSEC

Demostrar criptográficamente la ausencia de un dominio requiere firmar la respuesta a cada consulta de un dominio inexistente. Esto no es un problema para los servidores de firmas 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 cuando se trata de autenticar las respuestas a las consultas de dominios inexistentes, ya que es imposible generar previamente una respuesta a cada consulta de nombre de host posible.

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 inexistente k.example.com, el servidor responderá con un registro NSEC que indica 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.

Evitar caminar por el dominio

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 usando GPU y hardware dedicado significaron que las respuestas de NSEC3 podían ser forzadas de forma barata usando ataques de diccionario fuera de línea. Se ha propuesto NSEC5 para permitir que los servidores autorizados firmen las respuestas de NSEC sin tener que mantener una clave privada que pueda usarse para modificar la zona. Por lo tanto, robar un NSEC5KEY solo daría como resultado la capacidad de enumerar una zona más fácilmente.

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 los pares de dominios rodean léxicamente al dominio solicitado. Por ejemplo, la solicitud de k.example.comdaría como resultado un registro NSEC que demuestre que no existe nada entre los dominios (ficticios) j.example.comy l.example.com. Esto también es posible con registros NSEC3.

CloudFlare fue pionero en un par de enfoques alternativos, que logran lograr el mismo resultado en un tercio del tamaño de la respuesta. El primero es una variación del enfoque de "mentiras piadosas", llamado "mentiras negras", que explota el comportamiento común del cliente DNS para declarar la inexistencia de manera más compacta. En cambio, el segundo enfoque elige probar que "el registro existe pero el tipo de registro solicitado no", a lo que llaman "escopeta de DNS".

Despliegue

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 para la Seguridad del Ciberespacio de EE. UU. identificó específicamente la necesidad de proteger el DNS. 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 las 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 generalmente solo implementan una tecnología si reciben un beneficio inmediato, pero si se requiere un nivel mínimo de implementación antes de cualquierlos usuarios reciben un beneficio mayor que sus costos (como ocurre con 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 deben actualizarse con un software compatible con DNSSEC, y los datos DNSSEC deben crearse y agregarse a los datos de la zona DNS. Un cliente que usa TCP/IP debe tener actualizado su sistema de resolución de DNS (cliente) antes de que pueda usar las capacidades de DNSSEC. Además, cualquier resolutor 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 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 conduce 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 tratando de responder a una mayor cantidad de solicitudes de DNSSEC (posiblemente falsas). Se han desarrollado algunas extensiones de protocolo, como TCP Cookie Transactions, para reducir esta carga. Para hacer frente a estos desafíos, se está realizando un esfuerzo significativo para implementar DNSSEC, porque Internet es vital para muchas organizaciones.

Primeros despliegues

Los primeros usuarios incluyen Brasil (.br), Bulgaria (.bg), República Checa (.cz), Namibia (.na), Puerto Rico (.pr) y Suecia (.se), que utilizan DNSSEC para su código de país de nivel superior. dominios; 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). ARIN también está firmando sus zonas inversas. En febrero de 2007, TDC se convirtió en el primer ISP sueco en comenzar a ofrecer esta función a sus clientes.

IANA probó públicamente una raíz firmada de muestra desde junio de 2007. Durante este período anterior a la firma de producción de la raíz, también hubo varias anclas de confianza alternativas. El IKS Jena presentó uno el 19 de enero de 2006, el Consorcio de Sistemas de Internet presentó otro el 27 de marzo del mismo año, mientras que la propia ICANN anunció un tercero el 17 de febrero de 2009.

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. 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". El 23 de junio de 2010, se enumeraron 13 registradores que ofrecían registros DNSSEC para dominios.ORG.

VeriSign ejecutó un proyecto piloto para permitir que los dominios.com y.net se registraran solos 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, y el 16 de noviembre del mismo año, dijeron que.com y. net estarían firmados para el primer trimestre de 2011, luego de demoras ocasionadas por aspectos técnicos de la implementación. Este objetivo se logró a tiempo 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.

Despliegue en la raíz DNS

DNSSEC se implementó por primera vez en el nivel raíz el 15 de julio de 2010. Se espera que esto simplifique en gran medida la implementación de los solucionadores de DNSSEC, ya que el ancla de confianza raíz se puede usar para validar cualquier zona DNSSEC que tenga una cadena completa de confianza desde la raíz. Dado que la cadena de confianza debe rastrearse hasta una raíz de confianza 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, aunque la zona ".org" y la raíz estén firmadas, se debe implementar un ancla de confianza en para validar la zona.

Los problemas políticos relacionados con la firma de la raíz han sido una preocupación continua, principalmente sobre algunos temas centrales:

• Otros países están preocupados por el control de EE. UU. sobre Internet y pueden rechazar cualquier clave centralizada por este motivo.
• Algunos gobiernos podrían intentar prohibir la distribución de claves de cifrado respaldadas por DNSSEC.

Planificación

En septiembre de 2008, ICANN y VeriSign publicaron propuestas de implementación y en octubre, la Administración Nacional de Telecomunicaciones e Información (NTIA) solicitó comentarios al público. 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 NTIA.

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. En la reunión se anunció que se implementaría gradualmente 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 la zona raíz será firmado con un DNSKEY RSA/SHA256. Durante el período de implementación incremental, la zona raíz brindará servicio a una Zona raíz deliberadamente no validable (DURZ) que usa claves ficticias, y el registro DNSKEY final no se distribuirá hasta el 1 de julio de 2010.Esto significa que las claves que se usaron 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 consultas que solicitan registros de recursos de DNSSEC.

El dominio de nivel superior.org se firmó con DNSSEC en junio de 2010, seguido de.com,.net y.edu más adelante en 2010 y 2011. Los dominios de nivel superior de código de país pudieron depositar claves a partir de mayo de 2010. Como de noviembre de 2011, más del 25 % de los dominios de nivel superior están firmados con DNSSEC.

Implementación

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 usa firmas de un hash SHA-2 (SHA-256) creado con el algoritmo RSA, como se define en RFC 5702. A partir de mayo de 2010, los trece servidores raíz comenzaron a prestar servicios a DURZ. El 15 de julio de 2010, se firmó la primera zona raíz DNSSEC de producción completa raíz, con el número de serie SOA 2010071501. Los anclajes de confianza raíz están disponibles en IANA.

Implementación a nivel de TLD

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.

Validación de DNSSEC Lookaside - histórico

En marzo de 2006, el Consorcio de Sistemas de Internet introdujo el registro de validación Lookaside de DNSSEC. DLV estaba destinado a facilitar la implementación de DNSSEC 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 los subárboles firmados del DNS. El propósito de DLV era permitir que los validadores descarguen el esfuerzo de administrar un repositorio de anclaje de confianza a un tercero de confianza. El registro DLV mantuvo 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 soporte, como BIND o Unbound, configurado con un ancla de confianza para una zona DLV. Esta zona contenía registros DLV; 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 otro lugar 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.

Las brechas en la cadena de confianza, como dominios de nivel superior sin firmar o registradores que no admitían delegaciones de DNSSEC, significaban que los administradores de dominios de nivel inferior podían usar DLV para permitir que sus datos de DNS fueran validados por resolutores que habían sido configurados para usar DLV.. Esto puede haber obstaculizado la implementación de DNSSEC al eliminar la presión de los registradores y los registros de TLD para admitir DNSSEC de manera adecuada. DLV también agregó complejidad al agregar más actores y rutas de código para la validación de DNSSEC.

ISC desmanteló su registro DLV en 2017. La compatibilidad con DLV quedó obsoleta en BIND 9.12 y se eliminó por completo de BIND 9.16. La versión 1.5.4 de Unbound (julio de 2015) marcó DLV como fuera de servicio en la configuración de ejemplo y en la página del manual. 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".

Iniciativa de implementación de DNSSEC del gobierno federal de EE. UU.

La Dirección de Ciencia y Tecnología del Departamento de Seguridad Nacional de EE. UU. (DHS) patrocina la "Iniciativa de implementación de 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 en los sectores público y privado". El DHS también financia esfuerzos para madurar las DNSSEC e implementarlas dentro del gobierno federal de los EE. UU.

Se informó que el 30 de marzo de 2007, el Departamento de Seguridad Nacional de los EE. UU. propuso "tener la clave para firmar la zona raíz del DNS sólidamente en manos del gobierno de los EE. UU.". Sin embargo, ningún funcionario del gobierno de EE. UU. estuvo presente en la sala de reuniones y el comentario que provocó el artículo fue hecho por otra parte. DHS comentó más tardesobre por qué creen que otros llegaron a la falsa conclusión 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 un larga lista de expertos internacionales para 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, esencialmente reduciéndose a una agencia gubernamental o un contratista. ¿Hacemos alguna 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.

Implementación de DNSSEC en el gobierno federal de EE. UU.

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 de la 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 los nuevos requisitos de la Ley Federal de Administració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 de FISMA. Sin embargo, en ese momento NSEC3 no se había completado. NIST sugirió 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 mencionadas anteriormente.

El 22 de agosto de 2008, la Oficina de Administración y Presupuesto (OMB, por sus siglas en inglés) publicó un memorando que exige que las agencias federales de EE. UU. implementen DNSSEC en 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. Si bien el memorando se enfoca 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 OMB DNSSEC en. mil (militar estadounidense) también. 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".

Despliegue en resolutores

Varios ISP han comenzado a implementar resolutores recursivos de DNS que validan DNSSEC. Comcast se convirtió en el primer ISP importante en hacerlo en los Estados Unidos, anunció sus intenciones el 18 de octubre de 2010 y completó la implementación el 11 de enero de 2012.

Según un estudio de APNIC, la proporción de clientes que utilizan exclusivamente resolutores de DNS que realizan la validación de DNSSEC aumentó al 8,3 % en mayo de 2013. Aproximadamente la mitad de estos clientes usaban el resolutor de DNS público de Google.

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

A principios de 2016, el monitoreo de APNIC mostró que la proporción de clientes que utilizan exclusivamente resolutores de DNS que realizan la validación de DNSSEC había aumentado a alrededor del 15 %.

Soporte DNSSEC

El servidor DNS recursivo público de Google habilitó la validación de DNSSEC el 6 de mayo de 2013.

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 la depuración.

Publicaciones del IETF

• Extensiones de seguridad del sistema de nombres de dominio RFC 2535
• RFC 3225 que indica el soporte de resolución de DNSSEC
• RFC 3226 DNSSEC e IPv6 A6 Aware Server/Resolver requisitos de tamaño de mensaje
• RFC 3833 A Análisis de amenazas del sistema de nombres de dominio
• RFC 4033 Introducción y requisitos de seguridad de DNS (DNSSEC-bis)
• RFC 4034 Registros de recursos para las extensiones de seguridad de DNS (DNSSEC-bis)
• Modificaciones del protocolo RFC 4035 para las extensiones de seguridad DNS (DNSSEC-bis)
• RFC 4398 Almacenamiento de certificados en el sistema de nombres de dominio (DNS)
• RFC 4431 El registro de recursos de DNS de Validación Lookaside (DLV) de DNSSEC
• RFC 4470 que cubre mínimamente los registros NSEC y la firma en línea de DNSSEC
• RFC 4509 Uso de SHA-256 en los registros de recursos (RR) del firmante de delegación (DS) de DNSSEC
• RFC 4641 Prácticas operativas de DNSSEC
• Experimentos de seguridad DNS RFC 4955 (DNSSEC)
• RFC 5011 Actualizaciones automáticas de anclajes de confianza de seguridad DNS (DNSSEC)
• RFC 5155 DNSSEC Negación de existencia autenticada con hash
• RFC 5702 Uso de algoritmos SHA-2 con RSA en registros de recursos DNSKEY y RRSIG para DNSSEC
• Algoritmo de firma digital (DSA) de curva elíptica RFC 6605 para DNSSEC
• RFC 6725 Seguridad DNS (DNSSEC) Algoritmo DNSKEY Actualizaciones del registro IANA
• RFC 6781 Prácticas operativas de DNSSEC, versión 2
• RFC 6840 Aclaraciones y notas de implementación para la seguridad de DNS (DNSSEC)
• RFC 7129 Denegación de existencia autenticada en el DNS
• RFC 7344 Automatización del mantenimiento de confianza de delegación de DNSSEC
• RFC 7583 DNSSEC Key Rollover Consideraciones de tiempo
• Algoritmo de seguridad digital RFC 8080 Edwards-Curve (EdDSA) para DNSSEC
• Requisitos de implementación del algoritmo RFC 8624 y guía de uso para DNSSEC
• RFC 8749 Traslado de la Validación Lookaside (DLV) de DNSSEC al estado histórico

Instrumentos

La implementación de DNSSEC requiere software en el lado del servidor y del cliente. Algunas de las herramientas que admiten DNSSEC incluyen:

• Windows 7 y Windows Server 2008 R2 incluyen un resolutor de código auxiliar "consciente de la seguridad" que puede diferenciar entre respuestas seguras y no seguras de un servidor de nombres recursivo. DNSSEC de Windows Server 2012 es compatible con actualizaciones dinámicas seguras con zonas integradas en Active Directory, además de la replicación de Active Directory de claves ancla a otros servidores similares.
• BIND, el servidor de nombres DNS más popular (que incluye excavación), incorpora el nuevo protocolo DNSSEC-bis (registros DS), así como soporte para registros NSEC3.
• Unbound es un servidor de nombres DNS que se escribió desde cero para diseñarse en torno a los conceptos de DNSSEC.
• mysqlBind El software de administración de DNS GPL para DNS ASP ahora es compatible con DNSSEC.
• OpenDNSSEC es una herramienta de firma de DNSSEC designada que utiliza PKCS#11 para interactuar con módulos de seguridad de hardware.
• Knot DNS ha agregado soporte para la firma automática de DNSSEC en la versión 1.4.0.
• PowerDNS es totalmente compatible con DNSSEC a partir de la versión 3.0 en los modos prefirmado y firmado en vivo.
• DNSSEC: ¿Qué es y por qué es importante implementarlo durante mucho tiempo? — Check it Iniciativa de la comunidad de Internet y el gobierno holandés