Las Extensiones de seguridad del sistema de nombres de dominio ( DNSSEC ) es 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 las redes de Protocolo de Internet (IP). El protocolo proporciona autenticación criptográfica de datos, negación autenticada de existencia 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 solo como un sistema distribuido escalable. Las extensiones de seguridad del sistema de nombres de dominio (DNSSEC) intentan agregar seguridad, mientras mantienen la compatibilidad con versiones anteriores . Solicitud de comentarios 3833 documenta algunas de las amenazas conocidas al DNS y sus soluciones en DNSSEC.
DNSSEC fue diseñado para proteger las aplicaciones que utilizan DNS de aceptar datos de DNS falsificados o manipulados, como los creados por el envenenamiento de la caché de DNS . Todas las respuestas de las zonas protegidas de DNSSEC están firmadas digitalmente . Al verificar la firma digital, un solucionador de DNS puede verificar si la información es idéntica (es decir, no modificada y completa) a la información publicada por el propietario de la zona y servida en un servidor DNS autorizado. Si bien la protección de las direcciones IP es una preocupación inmediata para 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 criptografía. certificados almacenados en el DNS como registros de certificados ( registros CERT , RFC 4398), huellas digitales SSH ( SSHFP , RFC 4255), claves públicas IPSec (IPSECKEY, RFC 4025) y anclajes de confianza TLS (TLSA, RFC 6698).
DNSSEC no proporciona confidencialidad de datos; en particular, todas las respuestas DNSSEC están autenticadas pero no cifradas. DNSSEC no protege contra ataques DoS directamente, aunque indirectamente proporciona algún beneficio (porque la verificación de firmas permite el uso de partes 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 IETF RFC 4367, algunos usuarios y desarrolladores hacen suposiciones falsas sobre los nombres DNS, como suponer que el nombre común de una empresa más ".com" es siempre su nombre de dominio. DNSSEC no puede proteger contra suposiciones falsas; solo puede autenticar que los datos realmente provienen del propietario del dominio o no están disponibles. [ cita requerida ]
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 estas nuevas RFC (marzo de 2005), una RFC anterior, RFC 2535, se ha vuelto obsoleta.
Se cree ampliamente [1] que proteger el DNS es de vital importancia para proteger Internet en su conjunto, pero la implementación de DNSSEC específicamente se ha visto obstaculizada (al 22 de enero de 2010[actualizar]) por varias dificultades:
- La necesidad de diseñar un estándar compatible con versiones anteriores que pueda adaptarse al tamaño de Internet.
- Prevención de la "enumeración de zonas" cuando se desee
- Despliegue de implementaciones de DNSSEC en una amplia variedad de servidores DNS y resolutores (clientes)
- Desacuerdo entre los implementadores sobre quién debería poseer las claves raíz del dominio de nivel superior
- Superar la complejidad percibida de la implementación 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 , comenzando con un conjunto de claves públicas verificadas para la zona raíz del DNS, que es el tercero de confianza . Los propietarios de dominios generan sus propias claves y las cargan usando su panel de control 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 (por ejemplo, Verisign para .com), quien 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 solucionadores de DNS verifican la firma con una clave pública, almacenada en un registro DNSKEY.
- DNSKEY
- Contiene 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 delegados.
- NSEC (siguiente 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 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 de registro seguro 3)
- Contiene enlaces al siguiente nombre de registro en la zona (en orden de clasificación de nombres con hash) y enumera los tipos de registros que existen para el nombre cubierto por el valor de hash en la primera etiqueta del propio nombre del registro NSEC3. Los resolutores 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 cifrados con hash para evitar la enumeración de los nombres de registro en una zona.
- NSEC3PARAM (parámetros de la versión 3 del siguiente registro seguro)
- Los servidores DNS autorizados utilizan este registro para calcular y determinar qué registros NSEC3 incluir en las respuestas a las solicitudes DNSSEC de nombres / tipos no existentes.
Cuando se utiliza 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 RR. El registro DS se utiliza en la autenticación de DNSKEY en el procedimiento de búsqueda mediante la cadena de confianza. Los registros NSEC y NSEC3 se utilizan para ofrecer una sólida resistencia contra la suplantación de identidad.
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 . La siguiente tabla define, a abril de 2013, los algoritmos de seguridad que se utilizan con más frecuencia: [2]
Campo de algoritmo | Algoritmo | Fuente | Firma DNSSEC | Validación DNSSEC [3] |
---|---|---|---|---|
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 [4] |
---|---|---|---|
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 búsqueda
A partir de los resultados de una búsqueda de DNS, un solucionador de DNS consciente de la seguridad puede determinar si el servidor de nombres autorizado para el dominio que se consulta admite DNSSEC, si la respuesta que recibe es segura y si hay algún tipo de error. El procedimiento de búsqueda es diferente para los servidores de nombres recursivos , como los de muchos ISP , y para los solucionadores de códigos auxiliares , como los que se incluyen de forma predeterminada en los sistemas operativos convencionales. Microsoft Windows utiliza un solucionador de stub, y Windows Server 2008 R2 y Windows 7 en particular utilizan un solucionador de stub no validante pero compatible con DNSSEC. [5] [6]
Servidores de nombres recursivos
Con 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 más subdominios. Supongamos que un solucionador recursivo, como un servidor de nombres ISP, desea obtener las direcciones IP ( registro A y / o registros AAAA ) del dominio "www. Example.com ".
- El proceso comienza cuando un solucionador consciente de la seguridad establece el bit de marca "DO" ("DNSSEC OK" [7] ) en una consulta de DNS. Dado que el bit DO está en los bits de bandera extendidos definidos por los mecanismos de extensión para DNS (EDNS) , todas las transacciones DNSSEC deben admitir EDNS. El soporte de EDNS también es necesario para permitir tamaños de paquetes mucho más grandes que requieren las transacciones de DNSSEC.
- Cuando el resolutor recibe una respuesta a través del proceso normal de búsqueda de DNS, luego verifica para asegurarse de que la respuesta sea correcta. Idealmente, el solucionador consciente de la seguridad comenzaría verificando los registros DS y DNSKEY en la raíz del 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 que se encuentra en el "example. com "zona. 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á ningún registro RRSIG en la respuesta y no habrá un registro DS para "example.com" en la zona "com". Si hay un registro DS para "example.com", pero no hay ningún registro RRSIG en la respuesta, algo está mal y tal vez un hombre en el medio ataque está ocurriendo, eliminando la información DNSSEC y modificando los registros A. O bien, podría ser un servidor de nombres roto y ajeno a la seguridad en el camino que eliminó el bit de indicador DO de la consulta o el registro RRSIG de la respuesta. O podría ser un error de configuración.
A continuación, puede ser que no haya un nombre de dominio llamado "www.example.com", en cuyo caso, en lugar de devolver un registro RRSIG en la respuesta, habrá un registro NSEC o un registro NSEC3. Estos son registros de "siguiente seguridad" que permiten al resolutor probar que no existe un nombre de dominio. 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, creando una "isla de seguridad" que necesita ser validada de alguna otra manera. Al 15 de julio de 2010[actualizar], se completa 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 stub
Los solucionadores de stub 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". [10] Un solucionador de stub simplemente enviará una solicitud a un servidor de nombres recursivo y usará 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 las secciones Respuesta y Autoridad de la respuesta ". [11] Microsoft Windows usa un solucionador de stub, y Windows Server 2008 R2 y Windows 7 en particular usan un solucionador de stub no validante pero compatible con AD-bit. [5] [6]
Un solucionador de stub de validación también puede potencialmente realizar su propia validación de firma estableciendo el bit Checking Disabled (CD) en sus mensajes de consulta. [11] Un solucionador de stub de validación usa el bit de CD para realizar su propia autenticación recursiva. El uso de un solucionador de stub de validación le brinda al cliente una 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.
Para que el solucionador de stub no validante pueda confiar realmente en los servicios de DNSSEC, el solucionador de stub debe confiar tanto en los servidores de nombres recursivos en cuestión (que generalmente son controlados por el proveedor de servicios de Internet ) como en los canales de comunicación entre él y esos servidores de nombres. utilizando métodos como IPsec , SIG (0) o TSIG. [11] El uso de IPsec no está muy extendido. [12]
Confíe en anclas 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 de fuentes distintas del DNS. Estos puntos de partida se conocen como anclajes de confianza y normalmente se obtienen con el sistema operativo o mediante alguna otra fuente de confianza. Cuando se diseñó originalmente DNSSEC, se pensó que el único ancla de confianza que se necesitaría era la raíz del DNS . Los anclajes de raíz se publicaron por primera vez el 15 de julio de 2010. [13]
Una cadena de autenticación es una serie de registros DS y DNSKEY vinculados, comenzando 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 solucionadores de DNS conscientes de la seguridad deben tener relojes que estén bastante sincronizados, por ejemplo, en 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 anclajes 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. Entonces, cuando sea seguro asumir que los valores de tiempo de vida han causado que el almacenamiento en caché de las claves antiguas haya pasado, estas nuevas claves se pueden usar. Finalmente, cuando es seguro asumir que el almacenamiento en caché de los registros que utilizan las claves antiguas ha expirado, los registros DNSKEY antiguos pueden eliminarse. 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 en los registros DNSKEY se pueden usar para dos cosas diferentes y, por lo general, se usan registros DNSKEY diferentes para cada uno. Primero, hay 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 las ZSK están bajo control total y son utilizadas por una zona DNS en particular , se pueden cambiar más fácilmente y con más frecuencia. Como resultado, las ZSK pueden ser mucho más cortas que las KSK y aún 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 mensajes 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 sencillo 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 IETF [14] con el objetivo de desarrollar protocolos y técnicas que permitan a las aplicaciones de Internet establecer comunicaciones criptográficamente seguras con TLS , DTLS , SMTP y S / MIME basadas en DNSSEC.
Los nuevos protocolos permitirán garantías y restricciones adicionales para el modelo tradicional basado en la infraestructura de clave pública . También permitirán a los titulares de dominios hacer valer los certificados por sí mismos, sin hacer referencia a autoridades de certificación de terceros .
La compatibilidad con certificados grapados DNSSEC se habilitó en Google Chrome 14, [15] pero luego se eliminó. [16] Para Mozilla Firefox , el soporte fue proporcionado por un complemento [17] mientras que el soporte nativo está esperando a alguien para comenzar a trabajar en él. [18]
Historia
El DNS es un servicio de Internet fundamental y fundamental, pero en 1990 Steve Bellovin descubrió graves fallas de seguridad en él. La investigación para asegurarlo comenzó y progresó dramáticamente cuando su artículo se hizo público en 1995. [19] El RFC 2065 inicial fue publicado por el IETF en 1997, y los intentos iniciales de implementar esa especificación condujeron a una revisión (y se creyó completamente viable) especificación en 1999 como IETF RFC 2535. Se hicieron planes para implementar DNSSEC basado en RFC 2535.
Desafortunadamente, la especificación IETF RFC 2535 tuvo problemas muy importantes para escalar a la Internet completa; en 2001 quedó claro que esta especificación no se podía utilizar para redes grandes. En el funcionamiento normal, los servidores DNS a menudo no están sincronizados con sus padres. Por lo general, esto no es un problema, pero cuando DNSSEC está habilitado, estos datos desincronizados podrían tener el efecto de una seria denegación de servicio creada por uno mismo. El DNSSEC original requería un protocolo complejo de seis mensajes y una gran cantidad de transferencias de datos para realizar cambios clave para un niño (las zonas secundarias de DNS tenían que enviar todos sus datos al padre, hacer que el padre firmara cada registro y luego enviarlos firmas al niño para que 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" cambiara 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 se puede escalar a Internet.
El IETF modificó fundamentalmente DNSSEC, que se denomina DNSSEC-bis cuando es necesario para distinguirlo del enfoque DNSSEC original de RFC 2535. Esta nueva versión utiliza "registros de recursos de firmante de delegación (DS)" para proporcionar un nivel adicional de direccionamiento indirecto en puntos de delegación entre una zona de padres e hijos. 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 intercambiar cantidades masivas de datos entre el padre y los hijos. Esto significa que los clientes tienen que trabajar un poco más al verificar las claves. Más específicamente, la verificación del KEY RRset de una zona DNS 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.
Autenticar las respuestas de NXDOMAIN y NSEC
Probar criptográficamente la ausencia de un dominio requiere firmar la respuesta a cada consulta para 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 al intentar autenticar las respuestas a las consultas de dominios inexistentes, ya que es imposible generar previamente una respuesta a todas las posibles consultas de nombre de host.
La solución inicial fue crear registros NSEC para cada par de dominios en una zona. Por lo tanto, si un cliente solicita un registro en el que no existe k.example.com
, el servidor respondería con un registro NSEC indicando que no existe nada entre a.example.com
y z.example.com
. Sin embargo, esto filtra más información sobre la zona que los errores tradicionales de NXDOMAIN no autenticados porque expone la existencia de dominios reales.
Los registros NSEC3 (RFC 5155) se crearon como una alternativa que utiliza el hash del nombre en lugar de enumerarlos directamente. Con el tiempo, los avances en el hash con GPU y hardware dedicado significaron que las respuestas de NSEC3 podrían ser forzadas de forma barata y bruta mediante ataques de diccionario fuera de línea. Se ha propuesto NSEC5 para permitir que los servidores autorizados firmen respuestas NSEC sin tener que mantener una clave privada que se pueda usar para modificar la zona. Por lo tanto, robar una NSEC5KEY solo resultaría en la capacidad de enumerar más fácilmente una zona. [20]
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 blanca" en lugar de autenticar una negación de existencia directamente. La técnica descrita en RFC 4470 devuelve un registro NSEC en el que los pares de dominios rodean léxicamente el dominio solicitado. Por ejemplo, la solicitud de k.example.com
daría como resultado un registro NSEC que demuestre que no existe nada entre los dominios (ficticios) j.example.com
y l.example.com
. CloudFlare fue pionero en otro enfoque en el que demuestra que "el registro existe pero el tipo de registro solicitado no" que tiene la ventaja de un tamaño de carga útil significativamente reducido. [21]
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 de EE. UU . Para asegurar el ciberespacio identificó específicamente la necesidad de proteger el DNS. [22] 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) tiene 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 que cualquier usuario reciba un beneficio mayor que sus costos. (como ocurre con DNSSEC), es difícil de implementar. DNSSEC se puede implementar en cualquier nivel de 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 software que admita 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 resolución de DNS (cliente) antes de que pueda 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 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 de TCP actuales almacenan una gran cantidad de datos para cada conexión de TCP; Los servidores muy cargados pueden quedarse sin recursos simplemente tratando de responder a una mayor cantidad de solicitudes DNSSEC (posiblemente falsas). Algunas extensiones de protocolo, como las transacciones de cookies de TCP , se han desarrollado para reducir esta carga. [23] Para abordar estos desafíos, se está realizando un esfuerzo significativo para implementar DNSSEC, porque Internet es vital para muchas organizaciones.
Implementaciones tempranas
Los primeros en adoptarlo son Brasil ( .br ), Bulgaria ( .bg ), República Checa ( .cz ), Namibia ( .na ) [24] Puerto Rico ( .pr ) y Suecia ( .se ), que utilizan DNSSEC como código de país. dominios de nivel superior ; [25] 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). [26] ARIN también está firmando sus zonas inversas. [27] En febrero de 2007, TDC se convirtió en el primer ISP sueco en empezar a ofrecer esta función a sus clientes. [28]
IANA probó públicamente una raíz firmada de muestra 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 presentó uno el 19 de enero de 2006, [29] el Consorcio de sistemas de Internet presentó otro el 27 de marzo del mismo año, [30] mientras que la ICANN anunció un tercero el 17 de febrero de 2009. [31]
El 2 de junio de 2009, Afilias , el proveedor de servicios de registro para la zona .org del Registro de interés público, firmó el TLD .org. [32] 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 ". [33] El 23 de junio de 2010, se enumeraron 13 registradores que ofrecían registros DNSSEC para dominios .ORG. [34]
VeriSign ejecutó un proyecto piloto para permitir que los dominios .com y .net se registren con el propósito de experimentar con NSEC3. El 24 de febrero de 2009, anunciaron que desplegarían DNSSEC en todos sus dominios de nivel superior (.com, .net, etc.) dentro de 24 meses, [35] y el 16 de noviembre del mismo año, dijeron. Los dominios .com y .net se firmarían en el primer trimestre de 2011, después de los retrasos causados por aspectos técnicos de la implementación. [36] Este objetivo se logró según lo programado [37] y el vicepresidente de DNSSEC de Verisign, Matt Larson, ganó el premio al liderazgo tecnológico de InfoWorld en 2011 por su papel en el avance de las DNSSEC. [38] [39]
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. [40] Se espera que esto simplifique en gran medida la implementación de resolutores 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 de confianza sin interrupciones para validar, los anclajes de confianza deben configurarse para zonas seguras si alguna de las zonas por encima de ellas no es segura. Por ejemplo, si la zona "igned.example.org "estaba protegida pero la zona" example.org "no, entonces, aunque la zona" .org "y la raíz estén firmadas, se debe implementar un ancla de confianza en para validar la zona.
Los problemas políticos que rodean la firma de la raíz han sido una preocupación constante, principalmente sobre algunos temas centrales:
- Otros países están preocupados por el control estadounidense sobre Internet y pueden rechazar cualquier codificación centralizada por este motivo.
- Algunos gobiernos pueden 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 [41] y en octubre, la Administración Nacional de Telecomunicaciones e Información (NTIA) pidió comentarios al público. [42] No está claro si los comentarios recibidos afectaron el diseño del plan de despliegue final.
El 3 de junio de 2009, el Instituto Nacional de Estándares y Tecnología (NIST) anunció planes para firmar la raíz para fines de 2009, junto con ICANN, VeriSign y la NTIA. [43]
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. [44] 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 por DNSSEC el 1 de julio de 2010, y la raíz La zona se firmará con una DNSKEY RSA / SHA256. [44] Durante el período de implementación incremental, la zona raíz servirá 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. [45] Esto significa que las claves que se utilizaron para firmar el uso de la zona son deliberadamente no verificables; la razón 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 de .com , .net y .edu más tarde en 2010 y 2011. [46] [47] Los dominios de nivel superior de código de país pudieron depositar claves a partir de mayo de 2010. [48] A noviembre de 2011[actualizar]más del 25% de los dominios de nivel superior están firmados con DNSSEC. [49]
Implementación
El 25 de enero de 2010, el servidor raíz L (ell) comenzó a servir una zona raíz deliberadamente no validable (DURZ). La zona utiliza firmas de un hash SHA-2 (SHA-256) creado con el algoritmo RSA , como se define en RFC 5702. [50] [51] [52] A partir de mayo de 2010, los trece servidores raíz han comenzado a servir el DURZ . [45] El 15 de julio de 2010, se firmó la primera zona raíz de DNSSEC de producción completa de raíz, con la serie SOA 2010071501. Los anclajes de confianza de raíz están disponibles en IANA . [40]
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 la 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. [53] El objetivo de DLV era 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 un gran número de anclajes de confianza correspondientes a subárboles firmados del DNS. [54] El propósito de DLV era permitir a los validadores descargar el esfuerzo de administrar un repositorio de anclaje de confianza a un tercero de confianza. El registro DLV mantuvo una lista central de anclajes de confianza, en lugar de que cada validador repitiera el trabajo de mantener su propia lista.
Para usar DLV, se necesitaba un validador que lo admita, como BIND o Unbound , configurado con un ancla de confianza para una zona DLV. Esta zona contenía registros DLV; [55] Estos tenían exactamente el mismo formato que los registros DS, pero en lugar de referirse a una subzona delegada, se referían a una zona en otra parte del árbol DNS. Cuando el validador no pudo encontrar una cadena de confianza desde la raíz hasta el RRset que está tratando de verificar, buscó un registro DLV que pudiera proporcionar una cadena de confianza alternativa. [56]
Las brechas en la cadena de confianza, como los dominios de nivel superior sin firmar o los 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 quitar presión a los registradores y registros de TLD para que respalden adecuadamente las DNSSEC. DLV también agregó complejidad al agregar más actores y rutas de código para la validación de DNSSEC.
ISC retiró su registro DLV en 2017. [57] La compatibilidad con DLV quedó obsoleta en BIND 9.12 y se eliminó por completo de BIND 9.16. [58] La versión sin consolidar 1.5.4 (julio de 2015) marcó DLV como dado de baja en la configuración de ejemplo y en la página del manual [ [59] ]. 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". [60]
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 anima 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 los esfuerzos para madurar las DNSSEC e implementarlas dentro del gobierno federal de los EE. UU.
Se informó [61] que el 30 de marzo de 2007, el Departamento de Seguridad Nacional de EE. UU. Propuso "tener la clave para firmar la zona raíz del DNS sólidamente en manos del gobierno de EE. UU.". Sin embargo, ningún funcionario del gobierno de Estados Unidos estuvo presente en la sala de reuniones y el comentario que provocó el artículo fue hecho por otra parte. DHS comentó más tarde [62] [63] sobre 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 por último October distribuyó un borrador inicial del mismo a una larga lista de expertos internacionales para comentarios. El borrador establece una serie de opciones para 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. "En ninguna parte del documento hacemos ninguna propuesta sobre la identidad del Operador 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 Publicación especial 800-81 de NIST Secure Domain Name System (DNS) Deployment Guide el 16 de mayo de 2006, con orientación sobre cómo implementar DNSSEC. NIST tenía la intención de publicar nuevos requisitos de la Ley Federal de 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. [64] 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 que tiene las debilidades de seguridad mencionadas anteriormente.
El 22 de agosto de 2008, la Oficina de Administración y Presupuesto (OMB) publicó un memorando que exige que las agencias federales de los Estados Unidos 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. [65] Si bien el memorando se centra en 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 de OMB DNSSEC también en el dominio .mil (militares de EE. UU.). Carolyn Duffy Marsan, de NetworkWorld, declaró que DNSSEC "no se ha implementado ampliamente porque sufre el clásico dilema del huevo y la gallina ... con el mandato OMB, parece que el huevo se está rompiendo". [66]
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, anunciando sus intenciones el 18 de octubre de 2010 [67] [68] y completando la implementación el 11 de enero de 2012. [69]
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. [70] Aproximadamente la mitad de estos clientes utilizaban el resolutor de DNS público de Google .
En septiembre de 2015, Verisign anunció su servicio público gratuito de resolución de DNS [71] 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 usan exclusivamente resolutores de DNS que realizan la validación de DNSSEC había aumentado a aproximadamente un 15%. [72]
Soporte DNSSEC
El DNS público de Google es un servicio de DNS público que se proporciona de forma gratuita y es totalmente compatible con DNSSEC.
El 6 de mayo de 2013, Google Public DNS habilitó la validación DNSSEC de forma predeterminada; lo que significa que todas las consultas serán validadas a menos que los clientes se excluyan explícitamente. [73]
BIND , el software de administración de DNS más popular, habilita la compatibilidad con DNSSEC de forma predeterminada desde la versión 9.5.
Quad9 habilita DNSSEC de forma predeterminada en sus servidores principales. Sin embargo, también proporcionan servidores que no usan DNSSEC en diferentes direcciones IP. [74]
Publicaciones 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 Requisitos de tamaño de mensaje de servidor / solucionador consciente
- RFC 3833 Un 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 de 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 de lookaside (DLV) de DNSSEC
- RFC 4470 que cubre mínimamente los registros NSEC y la firma en línea DNSSEC
- RFC 4509 Uso de SHA-256 en registros de recursos (RR) de firmante de delegación (DS) de DNSSEC
- Experimentos RFC 4955 DNS Security (DNSSEC)
- RFC 5011 Actualizaciones automatizadas de anclajes de confianza de seguridad DNS (DNSSEC)
- RFC 5155 DNSSEC Denegación de existencia autenticada con hash
- RFC 5702 Uso de algoritmos SHA-2 con RSA en registros de recursos DNSKEY y RRSIG para DNSSEC
- RFC 6605 Algoritmo de firma digital de curva elíptica (DSA) para DNSSEC
- RFC 6725 DNS Security (DNSSEC) Actualizaciones del registro IANA del algoritmo DNSKEY
- RFC 6781 Prácticas operativas de DNSSEC, versión 2
- RFC 6840 Aclaraciones y notas de implementación para la seguridad del DNS (DNSSEC)
- RFC 7344 Automatización del mantenimiento de la confianza de delegación de DNSSEC
- RFC 7583 Consideraciones sobre el tiempo de transferencia de claves de DNSSEC
- RFC 8080 Algoritmo de seguridad digital Edwards-Curve (EdDSA) para DNSSEC
- Requisitos de implementación del algoritmo RFC 8624 y guía de uso para DNSSEC
- RFC 8749 Mover la validación de DNSSEC Lookaside (DLV) al estado histórico
Herramientas
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 solucionador de códigos auxiliar "consciente de la seguridad" que puede diferenciar entre respuestas seguras y no seguras mediante un servidor de nombres recursivo. Windows Server 2012 DNSSEC es compatible con actualizaciones dinámicas seguras con zonas integradas en Active Directory, además de la replicación de claves de anclaje de Active Directory a otros servidores similares. [75] [76]
- BIND , el servidor de nombres DNS más popular (que incluye dig ), incorpora el protocolo DNSSEC-bis (registros DS) más nuevo, así como soporte para registros NSEC3.
- Unbound es un servidor de nombres DNS que fue escrito desde cero para ser diseñado en torno a los conceptos de DNSSEC.
- mysqlBind El software de administración de DNS GPL para ASP de DNS ahora es compatible con DNSSEC.
- OpenDNSSEC es una herramienta de firma de DNSSEC designada que utiliza PKCS # 11 para interactuar con los 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 de firma previa y firma 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
Ver también
- DNSCrypt
- DNSCurve
- Mecanismos de extensión para DNS (EDNS)
- TSIG
- Infraestructura de clave pública de recursos (RPKI)
Referencias
- ^ Entrevista con Dan Kaminsky sobre DNSSEC (25 de junio de 2009) Entrevista de Kaminsky: DNSSEC aborda la confianza y seguridad entre organizaciones
- ^ "Números de algoritmo de seguridad del sistema de nombres de dominio (DNSSEC)" . IANA . 2010-07-12 . Consultado el 17 de julio de 2010 .
- ^ "RFC-8624" . IETF .
- ^ "RFC-4035" . IETF .
- ^ a b "Comprensión de DNSSEC en Windows" . Microsoft . 7 de octubre de 2009.
El cliente DNS de Windows es un solucionador de códigos auxiliares ...
- ^ a b "Extensiones de seguridad DNS (DNSSEC)" . Microsoft . 21 de octubre de 2009.
El cliente DNS en Windows Server 2008 R2 y Windows® 7 es un solucionador de stub consciente de la seguridad que no es de validación.
- ^ Conrad, D. "Indicando el soporte de resolución de DNSSEC" . Grupo de trabajo de ingeniería de Internet . Consultado el 27 de abril de 2017 .
- ^ "Raíz DNSSEC" .
- ^ http://www.v3.co.uk/v3-uk/news/2039287/verisign-adds-dnssec-com-domain-boost-online-security/
- ^ "RFC 4033: Introducción y requisitos de seguridad DNS" . La Sociedad de Internet . Marzo de 2005: 11. Los
resolutores de stub, por definición, 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.
Cite journal requiere|journal=
( ayuda ) Se dio una definición anterior en un RFC anterior: Robert Braden (octubre de 1989). "RFC 1123 - Requisitos para hosts de Internet - Aplicación y soporte" . IETF ( Grupo de trabajo de ingeniería de Internet ): 74.Un "solucionador de stub" depende de los servicios de un servidor de nombres recursivo [...]
Cite journal requiere|journal=
( ayuda ) - ^ a b c "RFC 4033: Introducción y requisitos de seguridad DNS" . La Sociedad de Internet . Marzo de 2005: 12. Cite journal requiere
|journal=
( ayuda ) - ^ 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 IPsec práctica para Internet (PDF) . En movimiento hacia sistemas de Internet significativos 2006: Talleres de OTM 2006. 1 . Springer . Archivado desde el original (PDF) el 26 de abril de 2012.
- ^ anclajes de raíz
- ^ IETF: autenticación basada en DNS de entidades nombradas (dane)
- ^ "ImperialViolet" . Consultado el 26 de noviembre de 2011 .
- ^ "cromo git" . Consultado el 9 de marzo de 2013 .
- ^ "Validador DNSSEC / TLSA" .
- ^ Bugzilla @ Mozilla: Error 672600: use la cadena DNSSEC / DANE grapada en el protocolo de enlace TLS en la validación de la cadena de certificados
- ^ "Uso del sistema de nombres de dominio para intrusiones en el sistema" por Steve Bellovin, 1995
- ^ "NSEC5: prevención demostrable de la enumeración de zona DNSSEC" .
- ^ "DNSSEC bien hecho" . 2015-01-29.
- ^ Estrategia nacional de Estados Unidos para asegurar el ciberespacio , p. 30 de febrero de 2003
- ^ Metzger, Perry; William Allen Simpson y Paul Vixie. "Mejora de la seguridad de TCP con cookies robustas" (PDF) . Usenix . Consultado el 17 de diciembre de 2009 .
- ^ https://ccnso.icann.org/de/node/7603
- ^ Centro de información de privacidad electrónica (EPIC) (27 de mayo de 2008). DNSSEC
- ^ Política de RIPE NCC DNSSEC archivada el 22 de octubre de 2007 en Wayback Machine.
- ^ Plan de implementación de ARIN DNSSEC
- ^ Eklund-Löwinder, Anne-Marie (12 de febrero de 2012). "[dns-wg] Canción de TCD del ISP sueco adopta DNSSEC" . lista de correo dns-wg . MADURO NCC . Consultado el 2 de diciembre de 2012 .
- ^ Archivo dns-wg: Lista de zonas firmadas Archivado el 5 de marzo de 2007 en Wayback Machine.
- ^ ISC lanza el registro DLV para iniciar la implementación de DNSSEC en todo el mundo. Archivado el 18 de noviembre de 2008 en Wayback Machine.
- ^ Repositorio de anclaje de confianza provisional
- ^ .ORG es el primer TLD abierto firmado con DNSSEC
- ^ Sean Michael Kerner. "¿.ORG el dominio más seguro?" . www.internetnews.com . Consultado el 27 de septiembre de 2008 .
- ^ "Lista de registradores .ORG - con DNSSEC habilitado en la parte superior" . Consultado el 23 de junio de 2010 .
- ^ VeriSign: Apoyaremos la seguridad de DNS en 2011. Archivado el 3 de marzo de 2009 en Wayback Machine.
- ^ VeriSign: actualización importante de seguridad de Internet en 2011
- ^ Dominio .com finalmente seguro
- ^ Matt Larson de Verisign gana el premio al liderazgo tecnológico de InfoWorld 2011
- ^ Premios al liderazgo tecnológico de InfoWorld 2011
- ^ a b "Actualización de estado de la raíz DNSSEC, 2010-07-16" . 16 de julio de 2010.
- ^ Singel, Ryan (8 de octubre de 2006). "Los federales comienzan a moverse en el agujero de seguridad de la red" . Noticias por cable . CondéNet . Consultado el 9 de octubre de 2008 .
- ^ "Comunicado de prensa: NTIA busca comentarios públicos para la implementación de tecnología de seguridad dentro del sistema de nombres de dominio de Internet" (Comunicado de prensa). Administración Nacional de Telecomunicaciones e Información, Departamento de Comercio de EE. UU. 9 de octubre de 2008 . Consultado el 9 de octubre de 2008 .
- ^ "El Departamento de Comercio trabajará con ICANN y VeriSign para mejorar la seguridad y estabilidad del sistema de direcciones y nombres de dominio de Internet" (Comunicado de prensa). Instituto Nacional de Estándares y Tecnología. 3 de junio de 2009.
- ^ a b "DNSSEC para la zona raíz" (PDF) .
- ^ a b Hutchinson, James (6 de mayo de 2010). "ICANN, Verisign coloca las últimas piezas del rompecabezas en la saga DNSSEC" . NetworkWorld. Cite journal requiere
|journal=
( ayuda ) - ^ "DNSSEC se convertirá en estándar en dominios .ORG a finales de junio" . Archivado desde el original el 15 de marzo de 2010 . Consultado el 24 de marzo de 2010 .
- ^ The Inquirer: Verisign implementa DNSSEC en .com TLD
- ^ Más seguridad para los servidores DNS raíz Heise Online, 24 de marzo de 2010
- ^ CircleID: Actualización de DNSSEC de ICANN 42 en Dakar
- ^ "Arquitectura técnica de alto nivel de la zona raíz de DNSSEC" (PDF) .
- ^ RFC 5702, §2.1. "Las claves públicas RSA para su uso con RSA / SHA-256 se almacenan en registros de recursos (RR) de DNSKEY con el algoritmo número 8."
- ^ RFC 5702, §3.1. "Las firmas RSA / SHA-256 se almacenan en el DNS utilizando registros de recursos (RR) RRSIG con el algoritmo número 8."
- ^ ISC lanza el registro DLV para iniciar la implementación de DNSSEC en todo el mundo. Archivado el 14 de junio de 2011 en Wayback Machine.
- ^ RFC 5011, "Actualizaciones automatizadas de anclajes de confianza de seguridad DNS (DNSSEC)"
- ^ RFC 4431, "El registro de recursos DNS de validación de DNSSEC Lookaside (DLV)"
- ^ RFC 5074, "Validación de DNSSEC Lookaside (DLV)"
- ^ "DLV reemplazado con zona vacía firmada - Consorcio de sistemas de Internet" . www.isc.org . Consultado el 5 de junio de 2020 .
- ^ "BIND 9.16.0, sucursal estable para 2020 y más allá - Consorcio de sistemas de Internet" . www.isc.org . Consultado el 5 de junio de 2020 .
- ^ "Cambios 1.5.4 sin consolidar" . NLnet Labs . Consultado el 5 de junio de 2020 .
- ^ Mekking, W .; Mahoney, D. (marzo de 2020). Mover la validación de DNSSEC Lookaside (DLV) al estado histórico . IETF . doi : 10.17487 / RFC8749 . RFC 879 . Consultado el 3 de junio de 2020 .
- ^ El Departamento de Patria y Seguridad quiere una llave maestra para DNS. Archivado el 6 de abril de 2007 en Wayback Machine Heise News, 30 de marzo de 2007.
- ^ Análisis: de poseer las claves de Internet UPI , 21 de abril de 2007
- ^ Análisis de UPI: poseer las claves de Internet 24 de marzo de 2011: el primer enlace está muerto, se cree que es el mismo contenido
- ^ Boletín 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
- ^ Memorando para los directores de información archivado el 16de septiembre de 2008en laoficina ejecutiva del presidente de Wayback Machine - Oficina de administración y presupuesto, 22 de agosto de 2008
- ^ Los federales refuerzan la seguridad en .gov Archivado el 25 de septiembre de 2008 en Wayback Machine Network World, 22 de septiembre de 2008
- ^ Blog de Comcast: comienza la implementación de seguridad de DNS , 18 de octubre de 2010
- ^ Video de anuncio de servicio público DNSSEC de Comcast Archivado el 21 de octubre de 2010en Wayback Machine , 18 de octubre de 2010
- ^ Comcast completa la implementación de DNSSEC , 11 de enero de 2012
- ^ Geoff Huston: DNS, DNSSEC y servicio de DNS público de Google (CircleID)
- ^ Presentación de Verisign Public DNS
- ^ Uso de la validación DNSSEC para el mundo (XA)
- ^ El DNS público de Google ahora admite el blog de código de Google de validación de DNSSEC , 1 de junio de 2013
- ^ "Preguntas frecuentes sobre Quad9" . Quad9 . Consultado el 7 de julio de 2018 .
- ^ Seshadri, Shyam (11 de noviembre de 2008). "DNSSEC en el cliente DNS de Windows 7" . Puerto 53 . Microsoft.
- ^ DNSSEC en Windows Server
Otras lecturas
- H. Yang; E. Osterweil; D. Massey; S. Lu; L. Zhang (8 de abril de 2010). "Implementación de criptografía en sistemas a escala de Internet: un estudio de caso sobre DNSSEC". Transacciones IEEE sobre computación segura y confiable . 8 (5): 656–669. CiteSeerX 10.1.1.158.1984 . doi : 10.1109 / TDSC.2010.10 .
enlaces externos
- DNSSEC - Sitio de información de DNSSEC: DNSSEC.net
- DNSEXT Grupo de trabajo IETF Extensiones DNS
- Proyecto de herramientas DNSSEC