stringtranslate.com

Extensiones de seguridad del sistema de nombres de dominio

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 .

Descripció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 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 ) por varias dificultades:

Operación

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.

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 su uso con DNSSEC:

RRSIG (firma de registro de recursos)
Contiene la firma DNSSEC de un conjunto de registros. Los solucionadores DNS verifican la firma con una clave pública, almacenada en un registro DNSKEY.
Clave DNS
Contiene la clave pública que utiliza un solucionador de DNS para verificar las firmas DNSSEC en 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 delegantes.
NSEC (próximo registro seguro)
Contiene un vínculo al siguiente nombre de registro en la zona y enumera los tipos de registro que existen para el nombre del registro. Los solucionadores 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 (próxima versión 3 del registro seguro)
Contiene vínculos al siguiente nombre de registro en la zona (en orden de clasificación de nombres en hash) y enumera los tipos de registro que existen para el nombre cubierto por el valor en hash en la primera etiqueta del nombre propio del registro NSEC3. Los solucionadores pueden utilizar estos registros 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 registro en hash criptográfico para evitar la enumeración de los nombres de registro en una zona.
NSEC3PARAM (próxima versión de registro seguro 3 parámetros)
Los servidores DNS autorizados utilizan este registro para calcular y determinar qué registros NSEC3 incluir en las respuestas a las solicitudes DNSSEC para nombres/tipos no existentes.

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.

Algoritmos

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]

El procedimiento de búsqueda

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]

Servidores de nombres recursivos

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 " .

  1. El proceso comienza cuando un solucionador que tiene en cuenta la seguridad establece el bit indicador "DO" ("DNSSEC OK") en una consulta DNS. Dado que el bit DO se encuentra en los bits indicadores extendidos definidos por los mecanismos de extensión para DNS (EDNS) , RFC  6891, todas las transacciones DNSSEC deben admitir EDNS. La compatibilidad con EDNS también es necesaria para permitir los tamaños de paquetes mucho más grandes que requieren las transacciones DNSSEC.
  2. Cuando el solucionador recibe una respuesta a través del proceso de búsqueda DNS normal, verifica que la respuesta sea correcta. Lo ideal sería que el solucionador consciente de la seguridad comenzara verificando 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 allí, 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 que se encuentre en la zona "example.com". Finalmente, verificaría el registro RRSIG que se encuentra en la respuesta para los registros A de "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 , 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]

Resolvedores de stubs

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]

Anclajes de confianza y cadenas de autenticación

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.

Firmas y firmas de zona

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.

Gestión de claves

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]

Grupo de trabajo del DANE

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]

Historia

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]

Autenticación de respuestas NXDOMAIN y NSEC

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.

Prevenir el desvío de dominios

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]

Despliegue

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.

Despliegues tempranos

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 llevó a cabo un proyecto piloto para permitir que los dominios .com y .net se registraran a sí mismos con el propósito 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 demoras causadas 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 para 2011 por su papel en el avance de DNSSEC [46] [47]

Implementación en la raíz del DNS

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:

Planificación

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, más del 25% de los dominios de nivel superior están firmados con DNSSEC. [57]

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 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]

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 DNSSEC Lookaside: histórico

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]

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

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] por qué cree 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".

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

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]

Despliegue en resolutores

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 solucionadores de DNS que realizan la 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 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]

Compatibilidad con DNSSEC

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]

Despliegue en infraestructura

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]

Recepción

Geoff Hutson ha argumentado que se debería abandonar la implementación de DNSSEC. [81]

Publicaciones de la IETF

Herramientas

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

Véase también


Referencias

  1. ^ Herzberg, Amir; Shulman, Haya (2014). "Reequipamiento de la seguridad en los protocolos de red: el caso de DNSSEC". IEEE Internet Computing . 18 (1). págs. 66–71. doi :10.1109/MIC.2014.14. ISSN  1089-7801. S2CID  12230888.
  2. ^ Vinculación de servicios y especificación de parámetros a través del DNS (DNS SVCB y HTTPS RRS).
  3. ^ Cliente cifrado TLS Hola.
  4. ^ Entrevista con Dan Kaminsky sobre DNSSEC (25 de junio de 2009) Entrevista a Kaminsky: DNSSEC aborda la confianza y la seguridad entre organizaciones
  5. ^ "Números del algoritmo de seguridad del sistema de nombres de dominio (DNSSEC)". IANA . 2010-07-12 . Consultado el 2010-07-17 .
  6. ^ ab "Entender DNSSEC en Windows". Microsoft . 7 de octubre de 2009. El cliente DNS de Windows es un solucionador de stubs...
  7. ^ ab "Extensiones de seguridad de DNS (DNSSEC)". Microsoft . 21 de octubre de 2009. 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.
  8. ^ "DNSSEC raíz".
  9. ^ "Computación: la principal fuente del Reino Unido para el análisis de tecnología empresarial".
  10. ^ Rose, Scott; Larson, Matt; Massey, Dan; Austein, Rob; Arends, Roy (marzo de 2005). RFC 4033: Introducción y requisitos de seguridad de DNS. The Internet Society . p. 11. doi :10.17487/RFC4033. 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 [...]
  11. ^ abc Rose, Scott; Larson, Matt; Massey, Dan; Austein, Rob; Arends, Roy (marzo de 2005). RFC 4033: Introducción y requisitos de seguridad del DNS. The Internet Society . p. 12. doi :10.17487/RFC4033.
  12. ^ Muñoz Merino, Pedro J.; García-Martínez, Alberto; Organero, Mario Muñoz; Kloos, Carlos Delgado (2006). Meersman, Robert; Tari, Zahir; Herrero, Herrero Martín (eds.). Habilitación de la autenticación práctica de IPsec para Internet (PDF) . En camino hacia sistemas de Internet significativos 2006: Talleres OTM 2006. vol. 1. Saltador . Archivado desde el original (PDF) el 26 de abril de 2012.
  13. ^ anclajes de raíz
  14. ^ Ubbink, Stefan. "Nuevo algoritmo DNSSEC para .nl". www.sidn.nl . Consultado el 29 de enero de 2024 .
  15. ^ Wessels, Duane (10 de agosto de 2023). "Verisign ayudará a fortalecer la seguridad con la actualización del algoritmo DNSSEC". Blog de Verisign . Consultado el 29 de enero de 2024 .
  16. ^ Wessels, Duane. "Transición de los TLD de Verisign a DNSSEC de curva elíptica". DNS-OARC . Consultado el 29 de enero de 2024 .
  17. ^ "Root Zone KSK Algorithm Rollover - ICANN" (Rotación del algoritmo KSK de la zona raíz - ICANN) www.icann.org . Consultado el 29 de enero de 2024 .
  18. ^ IETF: Autenticación basada en DNS de entidades nombradas (dane)
  19. ^ "ImperialViolet" . Consultado el 26 de noviembre de 2011 .
  20. ^ "chromium git" . Consultado el 9 de marzo de 2013 .
  21. ^ "Validador DNSSEC/TLSA".
  22. ^ Bugzilla@Mozilla: Error 672600: utilizar la cadena DNSSEC/DANE integrada en el protocolo de enlace TLS en la validación de la cadena de certificados
  23. ^ "Uso del sistema de nombres de dominio para intrusiones en el sistema" por Steve Bellovin, 1995
  24. ^ Elias Heftrig; Haya Schulmann; Niklas Vogel; Michael Waidne. "Los ataques de complejidad algorítmica de denegación de servicio de KeyTrap en la versión DNS: enero de 2024" (PDF) . ATHENE .(presione soltar)
  25. ^ "NSEC5: Prevención demostrable de la enumeración de zonas DNSSEC".
  26. ^ Denegación de existencia autenticada en el DNS. doi : 10.17487/RFC7129 . RFC 7129.
  27. ^ ab "Económicamente hablando: cómo hacer que las respuestas de DNSSEC sean económicas". 24 de junio de 2016.
  28. ^ "Mentiras negras". Negación de existencia o mentiras negras de DNSSEC compacta. sección 2. ID draft-valsorda-dnsop-black-lies.
  29. ^ "DNSSEC bien hecho". 29 de enero de 2015.
  30. ^ Estrategia nacional de Estados Unidos para proteger el ciberespacio, pág. 30 de febrero de 2003
  31. ^ Metzger, Perry; William Allen Simpson y Paul Vixie. "Mejora de la seguridad TCP con cookies robustas" (PDF) . Usenix . Consultado el 17 de diciembre de 2009 .
  32. ^ https://ccnso.icann.org/de/node/7603 [ URL básica PDF ]
  33. ^ Centro de Información sobre Privacidad Electrónica (EPIC) (27 de mayo de 2008). DNSSEC
  34. ^ Política DNSSEC de RIPE NCC Archivado el 22 de octubre de 2007 en Wayback Machine.
  35. ^ Plan de implementación de DNSSEC de ARIN
  36. ^ Eklund-Löwinder, Anne-Marie (12 de febrero de 2012). «[dns-wg] El proveedor de servicios de Internet sueco TCD Song adopta DNSSEC». Lista de correo dns-wg . RIPE NCC . Consultado el 2 de diciembre de 2012 .
  37. ^ Archivo dns-wg: Lista de zonas firmadas Archivado el 5 de marzo de 2007 en Wayback Machine.
  38. ^ ISC lanza el registro DLV para iniciar la implementación mundial de DNSSEC Archivado el 18 de noviembre de 2008 en Wayback Machine .
  39. ^ Repositorio provisional de anclas de confianza
  40. ^ .ORG es el primer TLD abierto firmado con DNSSEC
  41. ^ Sean Michael Kerner. ".ORG, ¿el dominio más seguro?". internetnews.com . Consultado el 27 de septiembre de 2008 .
  42. ^ "Lista de registradores .ORG con DNSSEC habilitado en la parte superior" . Consultado el 23 de junio de 2010 .
  43. ^ VeriSign: Apoyaremos la seguridad DNS en 2011 Archivado el 3 de marzo de 2009 en Wayback Machine
  44. ^ "VeriSign: Importante actualización de seguridad de Internet para 2011". Archivado desde el original el 19 de noviembre de 2009. Consultado el 18 de noviembre de 2009 .
  45. ^ Dominio .com finalmente seguro
  46. ^ Matt Larson de Verisign gana el premio InfoWorld Technology Leadership Award 2011
  47. ^ Premios al liderazgo tecnológico InfoWorld 2011
  48. ^ ab "Archivo del proyecto DNSSEC".
  49. ^ Singel, Ryan (8 de octubre de 2006). "Los federales comienzan a actuar sobre el agujero de seguridad en la red". Wired News . CondéNet . Consultado el 9 de octubre de 2008 .
  50. ^ "Comunicado de prensa: La NTIA solicita comentarios públicos sobre la implementación de tecnología de seguridad en el sistema de nombres de dominio de Internet" (Comunicado de prensa). Administración Nacional de Telecomunicaciones e Información, Departamento de Comercio de los Estados Unidos. 9 de octubre de 2008. Archivado desde el original el 13 de octubre de 2008. Consultado el 9 de octubre de 2008 .
  51. ^ "El Departamento de Comercio trabajará con la ICANN y VeriSign para mejorar la seguridad y estabilidad del sistema de nombres de dominio y direcciones de Internet" (Comunicado de prensa). Instituto Nacional de Normas y Tecnología. 3 de junio de 2009. Archivado desde el original el 29 de junio de 2011 . Consultado el 13 de julio de 2017 .
  52. ^ ab "DNSSEC para la zona raíz" (PDF) .
  53. ^ ab Hutchinson, James (6 de mayo de 2010). «ICANN y Verisign colocan las últimas piezas del rompecabezas en la saga DNSSEC». NetworkWorld . Archivado desde el original el 20 de diciembre de 2013. Consultado el 17 de mayo de 2010 .
  54. ^ "DNSSEC se convertirá en estándar en los dominios .ORG a finales de junio". Archivado desde el original el 15 de marzo de 2010. Consultado el 24 de marzo de 2010 .
  55. ^ The Inquirer: Verisign implementa DNSSEC en el TLD .com
  56. ^ Más seguridad para los servidores DNS raíz Heise Online, 24 de marzo de 2010
  57. ^ CircleID: Actualización de DNSSEC de la ICANN 42 en Dakar
  58. ^ ISC lanza el registro DLV para iniciar la implementación mundial de DNSSEC Archivado el 14 de junio de 2011 en Wayback Machine .
  59. ^ RFC 5011, "Actualizaciones automáticas de los anclajes de confianza de seguridad de DNS (DNSSEC)"
  60. ^ RFC 4431, "El registro de recursos DNS de validación de búsqueda lateral (DLV) de DNSSEC"
  61. ^ RFC 5074, "Validación de búsqueda DNSSEC (DLV)"
  62. ^ "DLV reemplazado por zona vacía firmada - Internet Systems Consortium". isc.org . 30 de septiembre de 2017 . Consultado el 5 de junio de 2020 .
  63. ^ "BIND 9.16.0, rama estable para 2020 y más allá - Internet Systems Consortium". isc.org . 20 de febrero de 2020 . Consultado el 5 de junio de 2020 .
  64. ^ "Cambios en Unbound 1.5.4". NLnet Labs . Consultado el 5 de junio de 2020 .
  65. ^ Mekking, W.; Mahoney, D. (marzo de 2020). Trasladar la validación de búsqueda de DNSSEC (DLV) a un estado histórico. IETF . doi : 10.17487/RFC8749 . RFC 879 . Consultado el 3 de junio de 2020 .
  66. ^ El Departamento de Seguridad Nacional quiere una clave maestra para el DNS Archivado el 6 de abril de 2007 en Wayback Machine Heise News, 30 de marzo de 2007
  67. ^ Análisis: Poseer las claves de Internet UPI , 21 de abril de 2007
  68. ^ Análisis de UPI: Poseer las llaves de Internet 24 de marzo de 2011 - El primer enlace está inactivo, se cree que se trata del mismo contenido
  69. ^ Boletín informativo de la iniciativa de implementación de DNSSEC - Volumen 1, número 2 Archivado el 22 de noviembre de 2007 en Wayback Machine , junio de 2006
  70. ^ Memorándum para los directores de sistemas informáticos Archivado el 16 de septiembre de 2008 en Wayback Machine Oficina Ejecutiva del Presidente — Oficina de Administración y Presupuesto, 22 de agosto de 2008
  71. ^ Los federales refuerzan la seguridad en .gov Archivado el 25 de septiembre de 2008 en Wayback Machine Network World, 22 de septiembre de 2008
  72. ^ Blog de Comcast: Comienza la implementación de la seguridad DNS, 18 de octubre de 2010
  73. ^ Vídeo de anuncio de servicio público de DNSSEC de Comcast Archivado el 21 de octubre de 2010 en Wayback Machine , 18 de octubre de 2010
  74. ^ Comcast completa la implementación de DNSSEC, 11 de enero de 2012
  75. ^ Geoff Huston: DNS, DNSSEC y el servicio DNS público de Google (CircleID)
  76. ^ Presentación del DNS público de Verisign
  77. ^ Uso de la validación DNSSEC para el mundo (XA)
  78. ^ El DNS público de Google ahora admite la validación DNSSEC Blog de Google Code, 1 de junio de 2013
  79. ^ "Quad9 FAQ". Quad9 . Consultado el 7 de julio de 2018 .
  80. ^ "Implementación de DANE SMTP entrante con DNSSEC para el flujo de correo de Exchange Online". TECHCOMMUNITY.MICROSOFT.COM . Consultado el 28 de mayo de 2024 .
  81. ^ Huston, Geoff (28 de mayo de 2024). "¿Se acabó el DNSSEC?". Blog de APNIC . Consultado el 28 de mayo de 2024 .
  82. ^ Seshadri, Shyam (11 de noviembre de 2008). "DNSSEC en el cliente DNS de Windows 7". Puerto 53. Microsoft.
  83. ^ DNSSEC en Windows Server

Lectura adicional

Enlaces externos