Domain Name System Security Extensions

Las extensiones de seguridad para el sistema de nombres de dominio (Domain Name System Security Extensions o DNSSEC, por sus siglas en inglés) son un conjunto de especificaciones de la Internet Engineering Task Force (IETF) para asegurar cierto tipo de información proporcionada por el sistema de nombres de dominio (DNS) que se usa en el protocolo de Internet (IP). Se trata de un conjunto de extensiones para el DNS que proporcionan a los clientes DNS (o resolvers), la autenticación de origen de los datos DNS, denegación de existencia de autenticación y la integridad de los datos, pero no la disponibilidad o confidencialidad.^[1]​

Descripción general

El diseño original del Domain Name System (DNS) no incluía la seguridad pues su objetivo de desarrollo estuvo enfocado en ser un sistema distribuido escalable. Las Extensiones de seguridad para el Sistema de Nombres de Dominio (DNSSEC) intentan aumentar la seguridad, y al mismo tiempo mantener la compatibilidad con lo más antiguo. En el documento RFC 3833 se documentan algunas amenazas conocidas en el DNS y cómo DNSSEC puede responder a esas amenazas.^[2]​

DNSSEC fue diseñado para proteger a los resolutores de dominios de Internet (a sus clientes) de datos de DNS que hayan sido falsificados, tales como la creados por envenenamiento de caché DNS. Todas las respuestas en DNSSEC son firmadas digitalmente. Al comprobar la firma digital, el resolver es capaz de comprobar si la información es idéntica (correcta y completa) a la información en el servidor DNS autorizado. Si bien la protección de las direcciones IP es la preocupación inmediata para muchos usuarios, DNSSEC puede proteger otra información también, como certificados de cifrado de propósito general almacenadas en registro CERTs en el DNS. RFC 4398 describe cómo distribuir estos certificados, incluidos los de correo electrónico, haciendo posible el uso de DNSSEC en todo el mundo como una infraestructura de clave pública para el correo electrónico.

DNSSEC no garantiza la confidencialidad de los datos; en particular, todas las respuestas de DNSSEC se autentican, pero no se cifran. DNSSEC no protege directamente contra los Ataques de denegación de servicio, aunque indirectamente, proporciona algún beneficio. Otras normas (no DNSSEC) se utilizan para proteger los datos a granel (como la transferencia de zona DNS) que se envía entre los servidores DNS. Como se documenta en el IETF RFC 4367, algunos usuarios y desarrolladores hacen suposiciones falsas acerca de los nombres DNS, como el supuesto de que el nombre común de una empresa más ".com" es siempre su nombre de dominio. DNSSEC no puede proteger contra las falsas suposiciones, sino que solo puede autenticar que los datos son verdaderamente de o no disponible en el propietario del dominio.

Las especificaciones de DNSSEC (llamadas DNSSEC-bis), describen el actual protocolo DNSSEC en gran detalle. Véase los RFC 4033, RFC 4034 y RFC 4035. Con la publicación de estos nuevos documentos RFC (marzo de 2005), el RFC anterior, RFC 2535 ha quedado obsoleto.

Se cree ampliamente que asegurar los DNS es de vital importancia para la seguridad en Internet como un todo,^[3]​ pero el despliegue de DNSSEC en concreto se ha visto obstaculizado por varias dificultades:

• La necesidad de diseñar un estándar compatible con versiones anteriores que puede escalarse al tamaño de la Internet.
• Prevención de la "enumeración de la zona" (ver abajo) donde se desee.
• El despliegue de las implementaciones DNSSEC en una amplia variedad de servidores de DNS y resolvers (clientes).
• El desacuerdo entre los encargados de la ejecución sobre quién debe poseer las llaves de raíz de los dominios de nivel superior.
• La superación de la aparente complejidad de DNSSEC y su despliegue.

Funcionamiento

DNSSEC trabaja firmando digitalmente estos registros para la búsqueda de DNS mediante criptografía de clave pública. El registro DNSKEY correcto se auténtica a través de una cadena de confianza, que comienza en un conjunto de claves públicas de la zona raíz del DNS, que es la tercera parte de confianza.

Registros

El DNS se implementa mediante el uso de varios registros de recursos. Para implementar DNSSEC, varios de los nuevos tipos de registro DNS se han creado o adaptado para su uso con DNSSEC:

• RRSIG
• DNSKEY
• DS
• NSEC
• NSEC3
• NSEC3PARAM

Cuando se usa DNSSEC, cada respuesta a una búsqueda de DNS contendrá un registro RRSIG DNS además del tipo de registro que se solicitó. El registro RRSIG es una firma digital de la respuesta de DNS registro de recursos conjunto. La firma digital puede ser verificada localizando la clave pública correcta se encuentra en un registro DNSKEY. El registro DS se utiliza en la autenticación de DNSKEYs en el procedimiento de búsqueda usando la cadena de confianza. Los registros NSEC y NSEC3 se utilizan para una resistencia fuerte contra la suplantación de identidad.

Algoritmos

DNSSEC fue diseñado para ser extensible y para que cuando se descubran ataques contra los algoritmos existentes, nuevos pueden ser introducidos en una forma compatible con versiones anteriores. A julio de 2009, se definieron los siguientes algoritmos de seguridad que son utilizados con mayor frecuencia:^[4]​

Campo del Algoritmo	Algoritmo	RFC
0	Borrado	RFC 4034, RFC 4398, RFC 8078
1	RSA/MD5 Desaprobado	RFC 3110, RFC 4034
3	DSA/SHA-1	RFC3755, RFC2536
5	RSA/SHA-1	RFC 3110, RFC 4034
7	RSASHA1-NSEC3-SHA1	RFC 5155
8	RSA/SHA-256	RFC 5702
10	RSA/SHA-512
12	GOST R 34.10-2001	RFC 5933
15	EdDSA ED25519	RFC 8080
16	EdDSA ED448

El procedimiento de búsqueda

De los resultados de una búsqueda de DNS, un resolver de DNS consciente de la seguridad puede determinar si la respuesta que recibió fue segura, o si era insegura y el servidor de nombres autoritativo para el dominio consultado no soporta DNSSEC o si hay algún tipo de error. El procedimiento de búsqueda es diferente para servidor de nombres recursivos, como los de muchos ISPs, que para resolvers stub, como los incluidos por defecto en los sistemas operativos principales. Microsoft Windows utiliza un resolver stub, y Windows Server 2008 R2 y Windows 7, en particular, utilizan un stub resolver que no valida DNSSEC, pero que es capaz de entender los mensajes.^[5]​^[6]​

Servidores de nombres recursivos

Usando el modelo de la cadena de confianza, un registro de firmante delegado (DS) de un dominio principal (zona DNS) se puede utilizar para verificar un registro DNSKEY en un subdominio, que a su vez puede contener otros registros DS para verificar subdominios adicionales. Digamos que un resolver recursivo, como un servidor de nombre de un ISP desea obtener las direcciones IP (registro A y / o registro AAAA s) del dominio "www.example.com".

1. El proceso comienza cuando un resolver que soporte seguridad establece el bit del parámetro "DO" en una consulta DNS. Dado que el bit DO está en los bits de los parámetros extendidos definidos por EDNS, todas las transacciones deben soportar DNSSEC EDNS. El soporte de EDNS también es necesario para permitir paquetes de tamaño mucho más grande como las transacciones DNSSEC requieren.
2. Cuando el resolver recibe una respuesta a través del proceso normal de búsqueda de DNS, la comprueba para asegurarse de que la respuesta es correcta. Lo ideal sería que el resolver que soporte seguridad comenzará con la verificación de la DS y el registro DNSKEY en el Servidor Raíz. A continuación, se utiliza el registro DS para el dominio de nivel superior "com" encontrado en la raíz para verificar los registros DNSKEY en la zona "com". A partir de ahí, revisaría si hay un registro DS para el subdominio "example.com" en la zona "com", y si lo hubiera, entonces utilizaría el registro DS para verificar el registro DNSKEY encuentra en la zona "example.com". Por último, sería verificar el registro RRSIG encontrado en la respuesta de los registros A para "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á un registro DS para "example.com" en la zona "com". Si hay un registro DS para "example.com", pero ningún registro RRSIG en la respuesta, algo está mal y tal vez un Ataque Man-in-the-middle está ocurriendo, modificando los registros A y eliminando la información de DNSSEC. O bien, podría ser un servidor de nombres indolente a la seguridad en alguna parte del camino que eliminó el bit de parámetro DO de la consulta o el registro RRSIG de la respuesta. O bien, podría ser un error de configuración.

Después, podría ser que no haya un dominio llamado "www.example.com", en cuyo caso en lugar de devolver un registro RRSIG en la respuesta, habrá o un registro NSEC o un registro NSEC3. Estos son registros "casi seguros" que permiten al resolver demostrar que un nombre de dominio no existe. Los registros NSEC/NSEC3 tienen registros RRSIG, los que pueden ser verificados como anteriormente.

Por último, puede ser que la zona "example.com" implemente DNSSEC, pero ya sea la raíz o la zona "com" no lo haga, creando una "isla de seguridad", que debe ser validado de alguna otra manera. En julio de 2010 se completó el despliegue de DNSSEC en la raíz^[7]​ El dominio.com fue firmado con claves de seguridad válidas y se añadió delegación segura a la zona de la raíz el 1 de abril del 2011.^[8]​

Stub resolvers

Stub resolvers son "resolvers 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".^[9]​ Un stub resolver simplemente enviará una solicitud a un servidor de nombres recursivo, y utilizará el bit de datos autenticados (Authenticated Data) (AD) en la respuesta como una "pista para averiguar si el servidor de nombres recursivo fue capaz de validar las firmas de todos los datos de las secciones de respuesta y la Autoridad de la respuesta."^[10]​ Microsoft Windows utiliza un stub resolver, y Windows Server 2008 R2 y Windows 7 en particular usan un stub resolver no validante, pero capaz de revisar el bit AD.^[5]​^[6]​

Un stub resolver validante también puede potencialmente llevar a cabo su propia validación de firma al fijar el bit de Checking Disabled (CD) en sus mensajes de consulta.^[10]​ Un stub resolver validante utiliza el CD bit para llevar a cabo su propia autenticación recursiva. Utilizar este tipo de stub resolver validantes le da al cliente DNS seguridad de extremo a extremo para los dominios que hayan implementado DNSSEC, incluso si el proveedor de servicios Internet o la conexión a ellos no es de confianza.

Para que los stub resolver no validante puedan confiar realmente en servicios DNSSEC, el stub resolver debe confiar tanto en los servidores de nombres recursivos en cuestión (los que suele ser controlados por el ISP) y los canales de comunicación entre él y los servidores de nombres, utilizando métodos tales como IPsec, SIG(0), o TSIG.^[10]​El uso de IPsec no está muy extendido^[11]​

Anclas de confianza y cadenas de autenticación

Para ser capaz de demostrar que una respuesta DNS es correcta, es necesario conocer al menos un registro de DS que es correcto a partir de fuentes distintas de la DNS. Estos puntos de partida son conocidos como anclas de confianza y se obtienen normalmente con el sistema operativo o por alguna otra fuente de confianza. Cuando DNSSEC fue originalmente diseñado, se pensó que la única ancla de confianza que se necesitaba era que la raíz del DNS. Las anclas de la raíz se publicaron por primera vez el 15 de julio de 2010.^[12]​

Una cadena de autenticación es una serie de registros DS y registros vinculados DNSKEY, comenzando con el 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 puede autenticar de manera segura.

Firmas y firmas de zona

Para limitar los ataques de repetición, no sólo hay valores TTL para propósitos de caché, sino que también marcas de tiempo adicionales en los registros RRSIG para limitar la validez de una firma. A diferencia de valores TTL que son relativos al momento del envío del registro, las marcas de tiempo son absolutas. Esto significa que todos los resolvers DNS que tengan en cuenta la seguridad deberán tener los relojes sincronizados con un margen de minutos.

Estas marcas de tiempo implica que una zona debe volver a ser firmada y distribuida a los servidores secundarios, o las firmas serán rechazadas por los resolvers que validan.

La gestión de claves

Con el fin de permitir la sustitución de claves, se requiere un esquema de despliegue de clave. Típicamente, esto implica en primer lugar el despliegue de nuevas llaves en nuevos registros DNSKEY, además de las llaves antiguas existentes. Entonces, cuando es seguro asumir que los valores del tiempo para vivir han hecho que las claves antiguas almacenadas en caché que hayan expirado, se puede utilizar estas nuevas claves. Por último, cuando es seguro asumir que los registros almacenados en caché utilizando las claves viejas han expirado, los viejos registros DNSKEY se pueden eliminar. Este proceso es más complicado para cosas tales como las claves para confiar en los anclajes, como en la raíz, los que pueden requerir una actualización del sistema operativo.

Las claves en los registros DNSKEY se puede utilizar para dos cosas diferentes y los normalmente se utilizan diferentes registros para cada uno. En primer lugar, son las claves DNSKEY de firma de clave (KSK), que se utilizan para firmar los registros de otros DNSKEY. En segundo lugar, están las claves de firma de la zona (ZSK) que se utilizan para firmar los registros de otros. Dado que los ZSKs están bajo el control completo y son usados por una determinada zona DNS, ellos se pueden cambiar más fácilmente y más a menudo. Como resultado, ZSKs puede ser mucho más cortos que los KSKs y todavía ofrecer el mismo nivel de protección, pero reduciendo el tamaño de los registros RRSIG / DNSKEY.

Cuando una nueva KSK se crea, el registro DS debe ser transferido a la zona superior y publicado allí. Los registros DS utilizan una síntesis del mensaje de la KSK lugar de la clave completa con el fin de mantener el tamaño de los registros pequeños. Esto es útil para zonas como el dominio. Com, que son muy grandes. El procedimiento para actualizar las claves de DS en la zona principal también es más sencillo que en versiones anteriores DNSSEC las que requerían los registros DNSKEY estuvieran en la zona principal.

Grupo de Trabajo DANE

El grupo de trabajo de autenticación de entidades con nombre basado en DNS (del inglés DNS-based Authentication of Named Entities) (DANE) pertenece a la IETF^[13]​ y tiene el objetivo de desarrollo de protocolos y técnicas que permiten a las aplicaciones de Internet establecer comunicaciones criptográficamente seguras (con IPsec, TLS, DTLS) basadas en DNSSEC.

Los nuevos protocolos permitirán a garantías adicionales y limitaciones para el modelo tradicional basado en la Infraestructura de clave pública. También permitirá a los titulares de dominio para hacer valer los certificados por ellos mismos, sin hacer referencia a terceras Autoridad de certificación.^[14]​

Soporte para certificados grapados DNSSEC se ha habilitado en Google Chrome 14.^[15]​ Para Mozilla Firefox, el soporte es proporcionado por un add-on,^[16]​ mientras que el soporte nativo está actualmente en desarrollo.^[17]​

Historia

DNS es un servicio de Internet crítico y fundamental, sin embargo, en 1990 Steve Bellovin descubrió serias fallas de seguridad en él. Así comenzó la investigación para securitizar la información y aumentó drásticamente cuando su trabajo se hizo público en 1995.^[18]​ El primer RFC 2065 fue publicado por el IETF en 1997, y los intentos iniciales para implementar esa especificación llevaron a una versión revisida (y creían totalmente viable) especificada en 1999 como la IETF RFC 2535. Se hicieron planes para implementar DNSSEC basado en RFC 2535.

Por desgracia, la especificación IETF RFC 2535 tenía problemas muy importantes para escalar su uso a todo Internet; para el año 2001 se hizo evidente que esta especificación no servía para grandes redes. En operación normal los servidores DNS a menudo pierden la sincronización con sus superiores. Esto no suele ser un problema, pero cuando está habilitado DNSSEC, estos datos fuera de sincronización podría tener el serio efecto de una denegación de servicio autocreada. El DNSSEC original requería un complejo protocolo de seis mensaje y una gran cantidad de transferencias de datos para llevar a cabo cambios fundamentales para un dependiente (las zonas DNS dependientes tenían que enviar a todos sus datos a los servidores superiores, que el superior firmara cada registro, y luego enviar los firmas de vuelta al dependiente para que éste la guarde en un registro SIG). Además, los cambios de llaves públicas podría tener efectos absurdos; por ejemplo, si la zona ".com" cambiaba su clave pública, se tenía que enviar 22 millones de registros (ya que tendría que actualizar todas las firmas de todos sus dependientes). Así, DNSSEC como se define en el RFC 2535 no pudo escalar hasta la Internet.

La IETF modificó sustancialmente DNSSEC, que se llama DNSSEC-bis cuando es necesario distinguirlo del enfoque original de la RFC 2535. Esta nueva versión utiliza "registros de recursos de firmante delegado (DS)" (en inglés delegation signer (DS) resource records) para proporcionar un nivel adicional de indirección en los puntos de delegación entre un servidor superior y una zona dependiente. En el nuevo enfoque, cuando un dependiente cambia de clave pública maestra, en lugar de tener que enviar seis mensajes para cada registro, hay un simple mensaje: el dependiente envía la nueva clave pública a su superior (firmado, por supuesto). Los superiores simplemente almacenan una clave pública maestra para cada dependiente, lo que es mucho más práctico. Esto significa que unos pocos datos se empuja a los superiores, en lugar de cantidades masivas de datos que se intercambian entre los superiores y dependientes.

Esto significa que los clientes tienen que hacer un poco más de trabajo al comprobar las llaves. Más específicamente, la verificación de clave RRset de una zona DNS requiere de dos operaciones de verificación de firmas en lugar de solo una, como era requerida por el 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 cambia DNSSEC y lo hace mucho más práctico de implementar.

Normas

• RFC 2535 extensiones de seguridad del sistema de nombres de dominio
• 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 DNS (DNSSEC-bis)
• RFC 4035 Modificaciones de Protocolo de las Extensiones de seguridad DNS (DNSSEC-bis)
• RFC 4398 Almacenamiento de certificados en el Domain Name System (DNS)
• RFC 4470 Cobertura mínima de registros NSEC y firma en línea de DNSSEC
• RFC 4509 uso de SHA-256 en los registros de recursos (RR) de firmante Delegado (DS) DNSSEC
• RFC 4641 DNSSEC Prácticas Operacionales
• RFC 5155 DNSSEC negación autenticada de existencia por hash

Tema de enumeración de zona, la controversia y NSEC3

Aunque el objetivo de DNSSEC es aumentar la seguridad, DNSSEC como se definió en los RFCs 4033 a 4035 presenta un nuevo problema que muchos creen es una nueva vulnerabilidad de seguridad: el tema de la enumeración de zona (también conocido como zone walking). DNSSEC obliga a la exposición de información que por mejores prácticas normales de DNS se mantienen como privada. NSEC3 (RFC 5155) se desarrolló para abordar esta cuestión y fue lanzado en marzo de 2008. NSEC3 mitiga, pero no elimina, la enumeración de la zona, ya que es posible buscar de manera exhaustiva el conjunto de todos los nombres posibles en una zona.^[19]​

Porqué los datos de zona DNS normalmente se mantienen privados

Cuando el protocolo DNS fue diseñado, no estaba destinado a ser un repositorio de información oculta. Sin embargo, como el DNS almacena la información sobre los detalles de una red relacionados con un dominio dado, muchos ven el contenido de su base de datos DNS como privado. En particular, los sistemas de DNS se configuran de manera que la mayoría de los usuarios no se les permite recuperar la lista completa de nombres u otra información en una zona. Esa lista sería de gran ayuda a los atacantes, ya que esta lista les puede dar información importante acerca de las máquinas que existen. Algunos administradores incluso poner el tipo de sistema e información de configuración en sus bases de datos de DNS, que es aún más valiosa para un atacante. El ampliamente utilizado libro de DNS and BIND (4 ª edición) por Albitz y Liu lo explica así:

Podría decirse que incluso más importante que controlar quien puede consultar su servidor de nombres es asegurarse que sólo los verdaderos servidores de nombres esclavos puedan transferir zonas desde su servidor de nombres. Los usuarios de equipos remotos sólo podrán buscar registros (por ejemplo, las direcciones) para nombres de dominio que ya saben, uno a la vez. Es la diferencia entre dejar que la gente al azar llamar a la centralita de su empresa y pregunte por el número de teléfono de John Q. [contra] el envío de una copia de su directorio telefónico corporativo.^[20]​

Además, la información de una zona enumerada se puede utilizar como una clave para múltiples consultas WHOIS, lo que podría revelar datos del registrante, lo que muchos registros deben proteger, ya que están bajo estrictas obligaciones legales en virtud de diversos contratos.

No está claro si es legal implementar DNSSEC en muchos países, a menos que dichas listas se puedan mantener en privado. DENIC ha declarado que la cuestión de enumeración de zona de DNSSEC viola la Ley Federal alemana de Protección de Datos. Otros países europeos tienen leyes similares que prohíben la privacidad de la publicación de ciertos tipos de información.^{[cita requerida]}

DNSSEC revela datos de zona

El diseño original de DNSSEC requería que toda la lista de nombres de zona se revelará a todos. Como se indica en el RFC 4033,

DNSSEC introduce la posibilidad de que una parte hostil enumere todos los nombres en una zona, siguiendo la cadena de NSEC. Los RR de NSEC afirman que los nombres no existen en una zona mediante la vinculación del nombre existente a nombre existente a lo largo de un ordenamiento canónico de todos los nombres dentro de una zona. Por lo tanto, un atacante puede consultar estos RRs de NSEC en secuencia para obtener todos los nombres en una zona. Aunque esto no es un ataque contra el propio DNS, podría permitir a un atacante mapear los equipos de red u otros recursos mediante la enumeración de los contenidos de una zona.

Hay una "evidente" solución, llamada un DNS horizonte dividido, que es como los DNS sin DNSSEC es desplegado a veces - pero este enfoque no funciona bien con DNSSEC. En el enfoque "DNS horizonte dividido", el servidor DNS niega la existencia de nombres a algunos clientes, y proporciona la información correcta a otros clientes. Sin embargo, dado que la información DNSSEC está firmada criptográficamente como autoridad, un atacante podría solicitar el registro "no existe" firmado, y luego retransmitir el registro para causar una denegación de servicio. DNSSEC cambia fundamentalmente el DNS para que pueda proporcionar información fidedigna, por lo que no funciona bien con los métodos basados en el suministro de información falsa para algunos usuarios. La investigación ha producido recomendaciones para combinar adecuadamente estas dos características de DNS.^[21]​

DNSSEC presentó este problema, ya que debe ser capaz de informar cuando un nombre "no" es encontrado. Los servidores DNS con soporte DNSSEC deben ser capaces de firmar ese reporte "no encontrado" de lo contrario un informe de no encontrado podrían ser fácilmente falsificados. Sin embargo, por razones de seguridad la clave de firma no debe estar en línea. Como resultado, DNSSEC fue diseñado para reportar un mensaje firmado que informa que un determinado rango de nombres no existe, que puede ser firmado por delante-de-tiempo fuera de línea. Desafortunadamente, esta información es suficiente para un atacante para ganar mucha más información, de lo que hubiera estado disponible para ellos de otra manera - es suficiente para permitir a un atacante obtener rápidamente todos los nombres en una zona, y luego a través de consultas específicas en los nombres para la reconstrucción de la totalidad o la mayor parte de los datos de una zona.

Como se señaló anteriormente, DNSSEC podría ser utilizado como la base de una infraestructura de clave pública mundial para direcciones de correo electrónico, mediante el uso de DNS para servir los certificados de correo electrónico y DNSSEC para validarlos. Sin embargo, este problema de DNSSEC hace esto poco probable para la mayoría de las organizaciones, al menos si se utiliza directamente. Como dice el RFC 4398, "Si una organización opta por emitir certificados para sus empleados, la colocación de CERT RR en el DNS por el nombre del propietario, y si DNSSEC (con NSEC) está en uso, es posible para alguien que enumere todos los empleados de la organización . Esto generalmente no se considera deseable, por la misma razón que los listados de las empresas telefónicas no están publicados a menudo en público e incluso están marcados como confidenciales."

Reacciones iniciales

Muchos de los participantes del grupo de trabajo de las extensiones DNS del IETF originalmente declaró que la enumeración de zona no era un problema importante, con el argumento de que los datos de los DNS era-o debería ser-pública. Sin embargo, los registradores y muchas organizaciones grandes dijeron a los miembros del grupo de trabajo que DNSSEC como se definía actualmente era inaceptable y que no haría o legalmente no podrían utilizarlo.

Firmado en línea

Un enfoque para prevenir la enumeración de zona fue codificado en el RFC 4470. En lugar de firmar las respuestas no-encontrado por adelantado, una respuesta de no-encontrado se genera para cada consulta. Por ejemplo, si se recibe una consulta para 'b.example.com', en lugar de servir una respuesta previamente firmada diciendo que no hay nombres entre 'a.example.com "y" mail.example.com ", que revela la existencia de "mail.example.com", la respuesta podría ser que "no hay nombres entre b.example.com y ba.example.com '. Si la consulta siguiente se refiere a 'ba.example.com', la respuesta podría ser "no hay nombres entre ba.example.com y baa.example.com '. Esto hace que la enumeración de toda la zona impracticable.

Este método tiene algunas desventajas. Se requiere una clave de firma que se mantenga en línea y accesible a todos los servidores DNS. Muchas claves de firma de zona se mantienen en línea de todos modos para apoyar a re firmado de zona o actualizaciones automáticas dinámicas, pero estas funciones sólo son necesarios en un único servidor DNS principal, mientras que para soportar la firma en línea de la de zona la clave de firma se debe mantener en cada servidor DNS autorizados. Algunos servidores autorizados deben ser accesibles desde Internet y, preferiblemente, éstas estarán muy dispersas, haciendo difícil mantener las claves bajo control. También se requiere atención para evitar que un atacante inunde el servidor DNS con solicitudes de nombres falsos, denegando el servicio a los usuarios legítimos.

NSEC3

Después de deliberar, se desarrolló una extensión: "DNSSEC Hashed Authenticated Denial of Existence" (informalmente llamado "NSEC3"). En este enfoque, los servidores conscientes de DNSSEC pueden optar por enviar un registro "NSEC3" en lugar de un registro NSEC cuando un registro no se encuentra. El registro NSEC3 está firmado, pero en lugar de incluir el nombre directamente (lo que permitiría la enumeración de zona), el registro NSEC3 incluye un valor criptográficamente hashed del nombre. El registro NSEC3 incluye tanto un hash después de un número de iteraciones y un salteado opcional, los cuales reducen la efectividad de los ataques de diccionario pre-calculados. El salteado aumenta el número de diccionarios necesarios para un ataque, mientras adicionales iteraciones de hash aumentan el costo de calcular cada diccionario.

En marzo de 2008, NSEC3 fue formalmente definida en el RFC 5155.

Despliegue

Internet es infraestructura crítica, sin embargo, su funcionamiento depende del DNS que es fundamentalmente inseguro. Por lo tanto, hay un fuerte incentivo para asegurar DNS y el despliegue de DNSSEC se considera generalmente que es una parte fundamental de ese esfuerzo. Por ejemplo, la Estrategia Nacional para Asegurar el Ciberespacio identifica específicamente la necesidad de securitizar el DNS.^[22]​ El despliegue a gran escala de DNSSEC podría resolver muchos otros problemas de seguridad, así como la distribución segura de claves para las direcciones de correo electrónico.

El despliegue de DNSSEC en redes de gran escala también es un reto. Ozment y Schechter observan que DNSSEC (y otras tecnologías) tiene un "problema de arranque": los usuarios normalmente sólo implementar una tecnología si reciben un beneficio inmediato, pero si se requiere un nivel mínimo de implementación antes de que los usuarios reciben un beneficio mayor que sus costos (como es cierto para DNSSEC), es difícil de implementar. DNSSEC se puede implementar en cualquier nivel de la jerarquía DNS, pero debe ser ampliamente disponible en una zona antes que muchos otros van a querer adoptarlo. Los servidores DNS deben actualizarse con el software que soporta DNSSEC, y los datos DNSSEC se deben crear y añaden a los datos de la zona DNS. Un cliente TCP / IP que utilizan deben tener su resolución de DNS (cliente) actualizado antes de que pueda utilizar las capacidades de DNSSEC. Lo que es más, cualquier resolver debe tener, o tener un modo de adquirir, al menos una clave pública que pueda confiar antes de que pueda empezar a utilizar DNSSEC.

La implementación de DNSSEC puede añadir una carga significativa para algunos servidores DNS. Las respuestas DNSSEC firmadas comunes son mucho más grandes que el tamaño por defecto UDP de 512 bytes. En teoría, esto puede ser manejado a través de múltiples fragmentos IP, pero muchos "middleboxes" en el campo no manejan esto correctamente. Esto conduce a la utilización de TCP en su lugar. Sin embargo, muchas implementaciones de TCP actuales almacenan una gran cantidad de datos para cada conexión TCP; servidores fuertemente cargados pueden quedarse sin recursos simplemente tratando de responder a un mayor número de (posiblemente falsas) peticiones DNSSEC. Algunas extensiones de protocolo, como TCP Cookie Transactions, han sido desarrollados para reducir esta carga.^[23]​ Para hacer frente a estos desafíos, el esfuerzo significativo está en curso para implementar DNSSEC, debido a que el Internet es tan importante para tantas organizaciones.

Despliegue inicial

Los primeros en adoptar incluyen a Brasil (.br), Bulgaria (.bg), República Checa (.cz), Puerto Rico (.pr) y Suecia (.se), que utilizan DNSSEC para los dominios de nivel superior de sus países;^[24]​ RIPE NCC, que han firmado todos los registros de búsqueda inversa (in-addr.arpa) que son delegados desde la Autoridad de Números Asignados de Internet (IANA).^[25]​ ARIN también está firmando sus zonas inversas.^[26]​ en febrero de 2007 TDC se convirtió en el primer ISP sueco para comenzar a ofrecer esta característica para sus clientes.^[27]​

IANA probó públicamente una raíz firmada muestra desde junio de 2007. Durante este período previo a la firma de producción de la raíz, también hubo varias anclas de confianza alternativos. El IKS Jena introdujo uno el 19 de enero de 2006,^[28]​ el Internet Systems Consortium presentó otra el 27 de marzo del mismo año,^[29]​ mientras que ICANN anunció una tercera el 17 de febrero de 2009.^[30]​

Se han llevado a cabo una amplia variedad de proyectos piloto y experimentos.dnssec.net mantiene una lista de este tipo de proyectos.

El 2 de junio de 2009, el Public Interest Registry (PIR) firmó la zona .org. El PIR también detalló el 26 de septiembre de 2008, que la primera fase, que implica grandes registrars que tiene una fuerte relación de trabajo con ("amigos y familiares") será el primero en ser capaz de firmar sus dominios, a partir de "principios de 2009".^[31]​ El 23 de junio de 2010, 13 registrars estaban listados como que ofrecían registros DNSSEC para dominios .ORG.^[32]​

VeriSign hizo un proyecto piloto para permitir que los dominios .com y .net para inscribirse con el fin de experimentar con NSEC3. El 24 de febrero de 2009, anunciaron que iban a implementar DNSSEC en todos sus dominios de nivel superior (.com, .net, etc) dentro de 24 meses,^[33]​ y el 16 de noviembre del mismo año, dijeron que los dominios .com y .net serían firmadas el primer trimestre de 2011, después de retrasos causados por aspectos técnicos de la aplicación.^[34]​ Este objetivo se logró en el plazo fijado^[35]​ y el VP de DNSSEC de Verisign, Matt Larson, ganó el Premio de Liderazgo en Tecnología de InfoWorld en 2011 por su papel en la promoción de DNSSEC.^[36]​^[37]​

Despliegue en la raíz DNS

DNSSEC se desplegó por primera vez en el nivel de la raíz, el 15 de julio de 2010.^[38]​ Se espera que esto simplifique en gran medida el despliegue de resolvers DNSSEC, ya que el ancla de confianza raíz se puede utilizar para validar cualquier zona DNSSEC que tiene una cadena completa de la confianza de la raíz. Puesto que la cadena de confianza se debe remontar a una raíz de confianza sin interrupción con el fin de validar, anclas de confianza aún deben configurarse para las zonas seguras, si cualquiera de las zonas por encima de ellos no son seguros. Por ejemplo, si la zona "signed.example.org" estaba asegurada pero la zona "example.org" no lo fue, entonces, a pesar de que la zona ".org" y la raíz se firmó, hay que tener un ancla de confianza para validar la zona.

Las cuestiones políticas que rodean la firma de la raíz han sido una preocupación continua, principalmente sobre algunas cuestiones centrales:

• Otros países están preocupados por el control de Estados Unidos sobre el Internet, y pueden rechazar cualquier esquema centralizada de claves por esta razón.
• Algunos gobiernos podrían tratar de prohibir la distribución de claves de encriptación respaldadas por DNSSEC.

Planificación

En septiembre de 2008, la ICANN y VeriSign publicaron cada uno propuestas de implementación^[39]​ y, en octubre, la Administración Nacional de Telecomunicaciones e Información (NTIA) pidió los comentarios del público.^[40]​ No está claro si los comentarios recibidos afectaron el diseño final del plan de implementación.

El 3 de junio de 2009, el Instituto Nacional de Estándares y Tecnología (NIST) anunció planes de firmar la raíz a finales de 2009, conjuntamente con ICANN, VeriSign y la NTIA.^[41]​

El 6 de octubre de 2009, en la 59a reunión de la Conferencia RIPE, ICANN y VeriSign anunciaron el calendario de despliegue previsto de DNSSEC en la zona raíz.^[42]​ En la reunión se anunció que sería gradualmente desplegado a un servidor de nombres raíz al mes, comenzando el 1 de diciembre de 2009, con el último servidor de nombres raíz ofreciendo una zona firmada DNSSEC el 1 de julio de 2010, y la zona de la raíz se firmará con una DNSKEY RSA/SHA256.^[42]​ Durante el período de puesta en marcha gradual la zona de las raíces servirá una Deliberately Unvalidatable Root Zone (DURZ) que utiliza llaves falsas, con el registro DNSKEY final sin ser distribuido hasta el 1 de julio de 2010.^[43]​ Esto significa que las claves que usadas para firmar el uso de zona son deliberadamente no verificables; la razón de este despliegue era para monitorear los cambios en los patrones de tráfico causados por las mayores respuestas a las consultas que soliciten los registros de recursos DNSSEC.

El dominio .org de nivel superior ha sido firmado con DNSSEC en junio de 2010, seguido por .com, .net y .edu más tarde en 2010 y 2011.^[44]​^[45]​ Los dominios de código de país de primer nivel fueron capaces de depositar las llaves a partir de mayo de 2010.^[46]​ A noviembre de 2011, más de 25% de los dominios de nivel superior están firmados con DNSSEC.^[47]​

Implementación

El 25 de enero de 2010, el servidor raíz L (ele) comenzó a ofrecer una Deliberately Unvalidatable Root Zone (DURZ). La zona utiliza firmas de hash SHA-2 (SHA-256) creado usando el algoritmo RSA, según se define en el RFC 5702.^[48]​^[49]​^[50]​ A mayo de 2010, todos los trece servidores raíz han comenzado a ofrecer la DURZ.^[43]​ El 15 de julio de 2010, se firmó la primera zona raíz DNSSEC para producción, con el serial SOA 2010071501. Las anclas de confianza raíz están disponibles en IANA.^[38]​

Despliegue a nivel de TLD

Debajo de la raíz hay un gran conjunto de dominios de nivel superior que debe ser firmado con el fin de lograr un despliegue de DNSSEC completo. La lista de dominios de nivel superior de Internet proporciona detalles acerca de cuáles de los dominios de nivel superior existentes han sido firmados y ligados a la raíz.

Validación DNSSEC Lookaside

En marzo de 2006, el Internet Systems Consortium introdujo el registro de validación DNSSEC Lookaside (DLV).^[51]​ DLV fue pensado para hacer más fácil de implementar DNSSEC en ausencia de un ancla de confianza raíz. En el momento en que fue imaginado que un validador podría tener que mantener un gran número de anclas de confianza correspondientes a subárboles firmadas del DNS.^[52]​ El propósito de DLV era permitir que los validadores para descargar el esfuerzo de la gestión de un repositorio de confianza de anclaje a una confianza tercero. El registro DLV mantiene una lista central de anclas de confianza, en lugar de cada validador repetir el trabajo de mantener su propia lista.

Para utilizar DLV, se necesita un validador que lo soporte, como BIND o Unbound, configurado con un ancla de confianza para una zona DLV. Esta zona contiene los registros DLV;^[53]​ éstos tienen exactamente el mismo formato que los registros DS, pero en lugar de referirse a una sub-zona delegada, se refieren a una zona en otro lugar en el árbol DNS. Cuando el validador no puede encontrar una cadena de confianza desde la raíz hasta la RRset que está tratando de comprobar, busca un registro DLV que puede proporcionar una cadena alternativa de confianza.^[54]​

DLV sigue siendo útil después de la raíz se ha firmado. Mientras que existen lagunas en la cadena de confianza, tales como dominios de nivel superior sin firmar, o registradores que no admitan delegaciones de DNSSEC, hostmasters de dominios de nivel inferior pueden utilizar DLV para que sea más fácil para sus usuarios validen sus datos DNS.

Iniciativa de despliegue de DNSSEC del gobierno de EE.UU

La Dirección de Ciencia y Tecnología del Departamento de Seguridad Nacional (DHS) patrocina la "Iniciativa de implementación de DNSSEC". Esta iniciativa anima a "todos los sectores para adoptar voluntariamente medidas de seguridad que mejoren la seguridad de la infraestructura de nombres de Internet, como parte de un esfuerzo global, cooperativo que involucra a muchas naciones y organizaciones de los sectores público y privado." DHS también financia esfuerzos para madurar DNSSEC y conseguir que se despliegue dentro del gobierno federal de Estados Unidos.

Se informó^[55]​ que el 30 de marzo de 2007, el Departamento de Seguridad Nacional de Estados Unidos propuso "tener la clave para firmar la zona raíz del DNS sólidamente en manos del gobierno de Estados Unidos." Sin embargo no había funcionarios del gobierno de Estados Unidos presentes en la sala de reuniones y el comentario que desató el artículo fue hecho por un tercero. DHS comentó más adelante^[56]​^[57]​ sobre por qué creían que los demás saltaron a la falsa conclusión de que el Gobierno de Estados Unidos había hecho una propuesta de este tipo: "El Departamento de Seguridad Nacional de Estados Unidos está financiando el desarrollo de un plan técnico para la implementación de DNSSEC, y el pasado octubre distribuyó un primer borrador de la misma a una larga lista de expertos internacionales para que formulen observaciones. el proyecto establece una serie de opciones para el que podría ser el titular, u "operador" de la Zona clave raíz, esencialmente llegando a una agencia gubernamental o un contratista. "en ninguna parte del documento hacemos que cualquier propuesta sobre la identidad de la Raíz del operador principal," dijo Maughan, el gerente de investigación y desarrollo de la seguridad cibernética para la Seguridad de la Patria ".

Despliegue de DNSSEC en el gobierno de EE.UU

El NIST produjo una publicación especial, la NIST Special Publication 800-81 Guía de Implementación de Domain Name System (DNS) seguro el 16 de mayo de 2006, con orientación sobre cómo implementar DNSSEC. NIST pretendía liberar requisitos nuevos para la nueva Ley de Gestión de Seguridad de la Información DNSSEC Federal (FISMA) en NIST SP800-53-R1, haciendo referencia a esta guía de implementación. Las agencias estadounidenses podrían entonces haber tenido un año después de la publicación final del NIST SP800-53-R1 para cumplir con estos nuevos requisitos de FISMA.^[58]​ Sin embargo, en ese momento NSEC3 no se había completado. 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 mencionados anteriormente. El 22 de agosto de 2008, la Oficina de Administración y Presupuesto (OMB) dio a conocer un memorando que requieren las agencias federales de Estados Unidos para implementar DNSSEC en todos los sitios .gov; la raíz .gov debía ser firmada en enero de 2009, y todos los subdominios bajo .gov debían ser firmados en diciembre de 2009.^[59]​ Si bien la nota se centra en los sitios .gov, la Agencia de Sistemas de Información de Defensa de Estados Unidos dice que tiene la intención de cumplir con los requisitos de la DNSSEC de la OMB en el dominio .mil (militar EE.UU.) también. Carolyn Duffy Marsan de NetworkWorld declaró que DNSSEC "no ha sido desplegado ampliamente, ya que sufre de un clásico dilema del huevo y la gallina ... con el mandato de la OMB, parece que el huevo se está resquebrajando".^[60]​

Despliegue en resolvers

Varios proveedores de Internet han comenzado a implementar resolvers recursivas DNS con validación DNSSEC. Comcast se convirtió en el primer ISP importante hacerlo en los Estados Unidos, anunciando sus intenciones el 18 de octubre de 2010 [62] [63] y completando el despliegue el 11 de enero de 2012.^[61]​^[62]​

Según el estudio de CircleID, la proporción de clientes que utilizan exclusivamente resolución de DNS que realizan la validación DNSSEC se ha elevado hasta el 8,3% en mayo de 2013.^[63]​ Cerca de la mitad de estos clientes estaba usando resolución del DNS público de Google.

DNS Público de Google

Google Public DNS es un servicio de DNS público, proporcionado libremente, que permite usar DNSSEC plenamente.

En su lanzamiento en 2009, Google Public DNS no permitía DNSSEC. Los registros RRSIG por supuesto podían ser consultados, pero el flag AD (Datos Autenticados, lo que significa que el servidor fue capaz de validar las firmas de todos los datos) nunca fue marcada.

El 28 de enero de 2013, los servidores DNS de Google comenzaron silenciosamente a proporcionar información de validación DNSSEC,^[64]​ pero solo si el cliente establece de manera explícita el flag DNSSEC OK (DO) en su consulta.^[63]​

El 6 de mayo de 2013, Google Public DNS habilita la validación DNSSEC de forma predeterminada; es decir todas las consultas serán validados a menos que los clientes optan explícitamente.^[65]​

Problemas

Se ha sabido que Exchange 2013 y versiones anteriores tienen un problema, donde la búsqueda de registros MX causa errores #550 4.4.7 QUEUE.Expired.^[66]​

Herramientas

El despliegue de DNSSEC requiere software tanto en el servidor como en el cliente. Algunas de las herramientas que soportan DNSSEC incluyen:

• Windows 7 y Windows Server 2008 R2 incluyen un stub resolver "consciente de la seguridad" que es capaz de diferenciar entre las respuestas seguras y no seguras de un servidor de nombres recursivo.^[67]​^[68]​
• BIND, el servidor DNS nombre más popular (que incluye dig). La versión 9.3 implementó el nuevo DNSSEC-bis (registros DS), aunque no soporta los registros NSEC3. BIND 9.6 fue lanzado en diciembre de 2008 y tiene soporte completo para los registros NSEC3.
• drill es una herramienta como dig habilitada para DNSSEC incluida en el paquete ldns.
• agrega a Mozilla Firefox la capacidad de determinar si un dominio se puede verificar usando DNSSEC.
• DNSSEC-Tools tiene como objetivo proporcionar herramientas fáciles de usar para ayudar a todo tipo de administradores y usuarios a hacer uso de DNSSEC. Ofrece herramientas para administradores de las zonas , , y , así como una biblioteca y herramientas para y parches para extender .
• Zone Key Tool es un software diseñado para facilitar el mantenimiento de las zonas conscientes de DNSSEC. Está diseñado principalmente para entornos con un número pequeño o mediano de zonas y ofrece un despliegue totalmente automático de firmado de clave, así como su refirmado automático.
• Unbound es un servidor de nombres DNS que se ha escrito desde cero diseñado en torno a los conceptos de DNSSEC.
• es un servidor de nombres para Microsoft Windows compacto y fácil de instalar.
• UnxsBind es un software de gestión de DNS GPL para ASPs de DNS que ahora es compatible con DNSSEC.
• OpenDNSSEC es una herramienta para firmar DNSSEC usando PKCS#11 para ser interfaz con módulos de seguridad de hardware.
• rastrea el despliegue de DNSSEC, monitorea zonas y proporciona una lista de claves públicas observadas.
• DNSViz y DNSSEC Analyzer son herramientas basadas en Web para visualizar la cadena de autenticación de DNSSEC de un dominio.
• DNSSEC Validator es un complemento de Mozilla Firefox para la visualización del estado de DNSSEC del nombre de dominio visitado.
• DNSSHIM o maestro DNS seguro oculto (DNS Secure Hidden Master) es una herramienta de código abierto para automatizar las zonas de apoyo DNSSEC el proceso de aprovisionamiento.
• Net::DNS::SEC es un resolver DNS implementado en Perl.

Véase también

• Mecanismos de extensión de DNS permiten los paquetes más grandes que DNSSEC utiliza y el bit de señalización DO
• DNSCurve

Referencias

1. (html). Cloudflare (en inglés). Archivado desde el original el 17 de enero de 2017. Consultado el 4 de abril de 2020. «DNSSEC creates a secure domain name system by adding cryptographic signatures to existing DNS records. These digital signatures are stored in DNS name servers alongside common record types like A, AAAA, MX, CNAME, etc. By checking its associated signature, you can verify that a requested DNS record comes from its authoritative name server and wasn’t altered en-route, opposed to a fake record injected in a man-in-the-middle attack.» 
2. «Threat Analysis of the Domain Name System (DNS)» [Análisis de Amenazas del Sistema de Nombres de Dominio (DNS)] (html). IETF (en inglés). agosto de 2004. Consultado el 28 de abril de 2020. «Among other drawbacks, this cart-before-the-horse situation has made it difficult to determine whether DNSSEC meets its design goals, since its design goals are not well specified.» 
3. Mimoso, Michael S. (25 de junio de 2009). (html). TechTarget (en inglés). Archivado desde el original el 3 de enero de 2012. Consultado el 4 de abril de 2020. «DNSSEC is interesting not because it fixes DNS. DNSSEC is interesting because it allows us to start addressing core problems we have on the Internet in a systematic and scalable way.» 
4. (xhtml). IANA (en inglés). 14 de abril de 2020. Archivado desde el original el 28 de abril de 2020. Consultado el 28 de abril de 2020. 
5. «Entendiendo DNSSEC en Windows». Microsoft. 7 de octubre de 2009. «El cliente DNS de Windows es un resolver stub...» 
6. «Extensiones de seguridad DNS (DNSSEC)». Microsoft. 21 de octubre de 2009. «El cliente DNS en Windows Server 2008 R2 y Windows ® 7 es un resolver capaz de detectar seguridad, pero no de validar.» 
7. http://www.root-dnssec.org/
8. http://www.v3.co.uk/v3-uk/news/2039287/verisign-adds-dnssec-com-domain-boost-online-security/
9. RFC 4033: DNS Security Introduction and Requirements. Internet Society. March 2005. p. 11. «Stub resolvers, by definition, are minimal DNS resolvers that use recursive query mode to offload most of the work of DNS resolution to a recursive name server.»  Una definición anterior fue dada en un anterior RFC: Robert Braden (October 1989). RFC 1123 - Requirements for Internet Hosts -- Application and Support. IETF (Internet Engineering Task Force). p. 74. «A "stub resolver" relies on the services of a recursive name server [...]». 
10. RFC 4033: DNS Security Introduction and Requirements. Internet Society. March 2005. p. 12. 
11. Muñoz Merino, Pedro J.; García-Martínez, Alberto; Organero, Mario Muñoz; Kloos, Carlos Delgado (2006). Meersman; Tari, Zahir; Herrero, Herrero Martín, eds. . On the Move to Meaningful Internet Systems 2006: OTM 2006 Workshops (en inglés) 1. Springer. pp. nombre-editor= Robert. Archivado desde el original el 26 de abril de 2012. Consultado el 13 de mayo de 2012. 
12. anclas en la raíz
13. IETF: autenticación de entidades con nombre basado en DNS (DANE)
14. Grepular: DNSSEC Will Kill Comercial CA
15. «ImperialViolet». Consultado el 26 de noviembre de 2011. 
16. «Extended Validator DNSSEC». 
17. Bugzilla @ Mozilla: Bug 672600 - El uso de DNSSEC / DANE cadena de grapas en el protocolo de enlace TLS en la validación de certificados de la cadena
18. "Using the Domain Name System for System Break-Ins" por Steve Bellovin, 1995
19. Breaking DNSSEC Daniel J. Bernstein, 2009
20. Albitz, Pablo; Cricket Liu (abril de 2001). O'Reilly Media, Inc., ed. DNS and BIND (4e. edición). ISBN 978-0-596-00158-2.  La referencia utiliza el parámetro obsoleto |mes= (ayuda); La referencia utiliza el parámetro obsoleto |coautores= (ayuda)
21. Split-View DNSSEC Operational Practices
22. U.S. National Strategy to Secure Cyberspace (enlace roto disponible en Internet Archive; véase el historial, la primera versión y la última)., p. 30 February 2003
23. Metzger, Perry, William Allen Simpson, and Paul Vixie. «Improving TCP security with robust cookies». Usenix. Consultado el 17 de diciembre de 2009. 
24. Electronic Privacy Information Center (EPIC) (May 27, 2008). DNSSEC
26. ARIN DNSSEC Deployment Plan
27. Eklund-Löwinder, Anne-Marie (12 de febrero de 2012). «[dns-wg] Swedish ISP TCD Song Adopts DNSSEC». dns-wg mailing list. RIPE NCC. Consultado el 2 de diciembre de 2012. 
30. Interim Trust Anchor Repository
31. Sean Michael Kerner. «.ORG the Most Secure Domain?». www.internetnews.com. Consultado el 27 de septiembre de 2008. 
32. . Archivado desde el original el 12 de junio de 2010. Consultado el 23 de junio de 2010. 
33. VeriSign: We will support DNS security in 2011 el 3 de marzo de 2009 en Wayback Machine.
34. . Archivado desde el original el 19 de noviembre de 2009. Consultado el 18 de septiembre de 2014. 
35. «.com Domain Finally Safe». Archivado desde el original el 23 de enero de 2013. Consultado el 27 de junio de 2011. 
36. Verisign's Matt Larson Wins 2011 InfoWorld Technology Leadership Award
37. The InfoWorld 2011 Technology Leadership Awards
38. «Root DNSSEC Status Update, 2010-07-16». 16 de julio de 2010. 
39. Singel, Ryan (8 de octubre de 2006). «Feds Start Moving on Net Security Hole». Wired News (CondéNet). Consultado el 9 de octubre de 2008. 
40. «Press Release: NTIA Seeks Public Comments for the Deployment of Security Technology Within the Internet Domain Name System». National Telecommunications and Information Administration, U.S. Department of Commerce. 9 de octubre de 2008. Consultado el 9 de octubre de 2008. 
41. . National Institute of Standards and Technology. 3 de junio de 2009. Archivado desde el original el 7 de junio de 2009. 
42. «DNSSEC for the Root Zone». 
43. Hutchinson, James (6 de mayo de 2010). ICANN, Verisign place last puzzle pieces in DNSSEC saga. NetworkWorld. 
44. . Archivado desde el original el 15 de marzo de 2010. Consultado el 24 de marzo de 2010. 
45. The Inquirer: Verisign deploys DNSSEC on .com TLD
46. More security for root DNS servers Heise Online, 24 March 2010
47. CircleID: DNSSEC Update from ICANN 42 in Dakar
48. «DNSSEC Root Zone High Level Technical Architecture». 
49. RFC 5702, §2.1. "RSA public keys for use with RSA/SHA-256 are stored in DNSKEY resource records (RRs) with the algorithm number 8."
50. RFC 5702, §3.1. "RSA/SHA-256 signatures are stored in the DNS using RRSIG resource records (RRs) with algorithm number 8."
52. RFC 5011, "Automated Updates of DNS Security (DNSSEC) Trust Anchors"
53. RFC 4431, "The DNSSEC Lookaside Validation (DLV) DNS Resource Record"
54. RFC 5074, "DNSSEC Lookaside Validation (DLV)"
55. Department of Homeland and Security wants master key for DNS el 6 de abril de 2007 en Wayback Machine. Heise News, 30 March 2007
56. Analysis: of Owning the keys to the Internet UPI, April 21, 2007
57. UPI Analysis: Owning the keys to the Internet March 24, 2011 - First link is dead, this is believed to be the same content
58. , June 2006
59. Memorandum For Chief Information Officers el 16 de septiembre de 2008 en Wayback Machine. Executive Office Of The President — Office Of Management And Budget, 22 August 2008
60. Feds tighten security on .gov el 25 de septiembre de 2008 en Wayback Machine. Network World, 22 September 2008
61. Comcast Blog - DNS Security Rollout Begins, October 18, 2010
62. Comcast DNSSEC Public Service Announcement Video el 21 de octubre de 2010 en Wayback Machine., October 18, 2010
63. Geoff Huston: DNS, DNSSEC and Google's Public DNS Service (CircleID)
64. Google's Public DNS does DNSSEC validation nanog mailing list archives, 29 January 2013
65. Google Public DNS Now Supports DNSSEC Validation Google Code Blog, 1 June 2013
66. . Archivado desde el original el 24 de octubre de 2014. Consultado el 18 de septiembre de 2014. 
67. Seshadri, Shyam (11 de noviembre de 2008). . Puerto 53. Microsoft. Archivado desde technet.com/sseshad/archive/2008/11/11/dnssec-on-windows-7-dns-client.aspx~~HEAD=NNS el original el 1 de septiembre de 2015. 
68. DNSSEC en Windows Server

Enlaces externos

Organizaciones / sitios web

• Sitio web de información de DNSSEC
• Noticias y opiniones sobre temas relacionados con DNSSEC
• Proyecto DNSSEC-Tools
• Iniciativa de coordinación de despliegue de DNSSEC
• Equipo de despliegue de DNSSEC
• Equipo de operaciones de DNS de ICANN
• DNSSEC (FAQ) LACNIC

Otros documentos

• Una Mirada Fundamental de DNSSEC, despliegue, y Extensiones de seguridad DNS de Geoff Huston
• "Uso del Sistema de Nombres de Dominio para el sistema de Robos" por Steve Bellovin, 1995
• por Miek Gieben
• Habilitando la resolución de nombres segura usando DNSSEC para diversas aplicaciones
• por Olaf Kolkman (RIPE NCC / NLnet Labs)
• Cómo garantizar su (inversa) de zona por Holger Zuleger
• seguridad para el correo electrónico más fácil en camino?
• "DNSSEC y la enumeración de zona" por Marcos Sanz (DENIC)
• NIST Special Publication (SP) 800-81, Guía de implementación de Sistema de Nombres de Dominio (DNS) Seguro, de mayo de 2006
• Bootstrapping la adopción de los protocolos de seguridad de Internet, Andy Ozment y Stuart E. Schechter, 26 a 28 junio, 2006
• explicación de DNSSEC y firma de la Zona Raíz (Parte I), documento sobre DNSSEC por ccNSO, febrero de 2008
• Estrategia Nacional de EEUU para asegurar el ciberespacio (enlace roto disponible en Internet Archive; véase el historial, la primera versión y la última)., febrero de 2003
• Cybertelecom:: Seguridad de DNS y Política de gobierno de Estados Unidos
• (PDF-Datei, 315 kB)
• la implementación de DNSSEC Cisco Internet Protocol Journal
• Informe de ICANN de DNSSEC en TLDs (generado diariamente)

•   Datos: Q41609