Extensiones de seguridad de sistema de nombres de dominio

Seguridad en Internet protocolos
Gestión de claves
Kerberos· PKIX· X.509· XKMS
Capa de aplicación
S/MIME· PGP· ID de remitente DKIM· PP %· PEM1· MUSGO1
Capa de transporte
SSL· TLS· PCT1
Capa de señalización
DNSSEC
Capa de red
IPsec

El Extensiones de seguridad de sistema de nombres de dominio (DNSSEC) es un conjunto de Internet Engineering Task Force Especificaciones (IETF) para fijar ciertos tipos de información proporcionada por el Sistema de nombres de dominio (DNS) como se utiliza en Protocolo de Internet Redes (IP). Se trata de un conjunto de extensiones al DNS que proporcionan a la autenticación de origen de clientes (resoluciones) DNS de datos DNS, autenticado negación de la existencia e integridad de datos, pero no la disponibilidad o confidencialidad.

Resumen

El diseño original de la Sistema de nombres de dominio (DNS) no incluyó la seguridad; en su lugar fue diseñado para ser un sistema escalable distribuido. Las extensiones de seguridad de sistema de nombre de dominio (DNSSEC) intenta añadir seguridad, mientras que mantiene la compatibilidad hacia atrás. RFC 3833 documentos de algunas de las amenazas conocidas para el DNS y cómo DNSSEC responde a esas amenazas.

DNSSEC fue diseñado para proteger las aplicaciones (y almacenamiento en caché las resoluciones que sirven esas aplicaciones) del uso de los datos DNS falsos o manipulados, como el creado por Envenenamiento de caché DNS. Todas las respuestas de las zonas protegida de DNSSEC son firmado digitalmente. Comprobando la firma digital, una resolución DNS es capaz de verificar si la información es idéntica (es decir, sin modificar y completar) a la información publicada por el dueño de la zona y servido en un servidor DNS autorizado. Mientras que proteger direcciones IP es la preocupación inmediata para muchos usuarios, DNSSEC puede proteger los datos publicados en el DNS, incluyendo texto (TXT) registra, correo exchange registros (MX) y puede utilizarse para arranque de otros sistemas de seguridad que publican las referencias a criptográficos certificados almacenados en el DNS como certificado Records (Registros de CERT, RFC 4398), SSH huellas dactilares (SSHFP, RFC 4255), IPSec claves públicas (IPSECKEY, RFC 4025), y TLS Confiar en anclajes (TLSA, RFC 6698).

DNSSEC No lo hace proporcionar confidencialidad de los datos; en particular, todas las respuestas DNSSEC autenticadas pero no cifradas. DNSSEC No lo hace proteger contra DoS ataca directamente, aunque indirectamente proporciona algún beneficio (porque firma control permite el uso de partes potencialmente poco confiables; esto es cierto sólo si el servidor DNS está utilizando un certificado autofirmado, no se recomienda para los servidores DNS de conexión a Internet).

Otras normas (no DNSSEC) se utilizan para asegurar datos a granel (tales como un Transferencia de zona DNS) enviados entre servidores DNS. Como se documenta en IETF RFC 4367, algunos usuarios y desarrolladores de hacen falsas suposiciones acerca de los nombres DNS, como suponiendo que una empresa es común nombre plus ".com" es siempre su nombre de dominio. DNSSEC no puede proteger contra falsas suposiciones; Sólo pueden autenticar que los datos son verdaderamente de o no están disponibles con el propietario del dominio.

Las especificaciones de DNSSEC (llamadas DNSSEC-bis) describir el actual Protocolo DNSSEC en gran detalle. Ver RFC 4033, RFC 4034, y RFC 4035. Con la publicación de estos nuevos RFCs (marzo de 2005), una RFC anterior, RFC 2535 se ha vuelto obsoleta.

Se cree ampliamente asegurar el DNS es críticamente importante para asegurar el Internet como un todo, pero específicamente ha sido obstaculizado la implantación de DNSSEC (a partir del 22 de enero de 2010) por varias dificultades:

• La necesidad de diseñar un al revés-compatible estándar que puede escalar el tamaño de Internet
• Prevención de la "enumeración de zona" (véase abajo) donde desee
• Despliegue de las implementaciones de DNSSEC en una amplia variedad de servidores DNS y resoluciones (clientes)
• Desacuerdo entre los ejecutores sobre quién debe poseer el dominio de nivel superior claves de la raíz
• Superar la aparente complejidad de DNSSEC y DNSSEC despliegue

Microsoft Windows utiliza un resolución del trozoy Windows 7 y más allá en particular utilice un sin validación (pero consciente de DNSSEC) trozo discernidor de imágenes. Para que la validación no trozo discernidor de imágenes colocar cualquier dependencia real servicios DNSSEC, el resolutor trozo debe confiar en ambos el servidores de nombre recursivos en cuestión (que normalmente es controlada por el Proveedor de servicios Internet) y los canales de comunicación entre sí mismo y los servidores de nombre, usando métodos tales como IPsec, SIG(0), o TSIG. El uso de IPsec No generalizada.

Operación

DNSSEC obras de firmar digitalmente registros de DNS lookup usando criptografía de clave pública. El registro DNSKEY correcto está autenticado mediante un cadena de confianza, a partir de un conjunto de verificado las claves públicas para el Zona de raíz DNS cual es el terceros de confianza. Los propietarios de dominio generar sus propias llaves y subirlas mediante su panel de control DNS en su registrador de nombres de dominio, que a su vez empuja las llaves vía secDNS al operador de la zona (por ejemplo: Verisign para .com) que firma y publica en DNS.

Registros

DNS se implementa mediante el uso de varios registros de recursos. Implementar DNSSEC, varios nuevos Tipos de registros DNS fueron creados o adaptados para usar con DNSSEC:

• RRSIG - contiene la firma DNSSEC para un conjunto de registros. Resoluciones DNS verificar la firma con una clave pública, almacenado en un registro DNSKEY.
• DNSKEY - contiene la clave pública que utiliza una resolución DNS para verificar las firmas DNSSEC en registros RRSIG.
• DS - contiene el nombre de una zona delegada. Colocas el registro DS en la zona de los padres junto con los registros NS delegante. referencias DNSKEY-antecedentes en la zona sub delegada.
• NS - contiene un enlace al nombre del registro siguiente en la zona y enumera los tipos de registro que existen para el nombre del disco. Resoluciones DNS utilice registros NSEC para verificar la inexistencia de un nombre de registro y tipo como parte de la validación de DNSSEC.
• NSEC3 - contiene enlaces con el nombre del registro siguiente en la zona (de nombre hasheado orden de clasificación) y enumera los tipos de registro que existen para el nombre cubierto por el valor de hash en el primer sello de la NSEC3-nombre del disco.Estos registros pueden utilizarse por resoluciones para verificar la inexistencia de un nombre de registro y tipo como parte de la validación de DNSSEC. NSEC3 registros son similares a los registros NS, pero NSEC3 utiliza hash criptográficamente registrar nombres para evitar la enumeración de los nombres en una zona de registro.
• NSEC3PARAM - servidores DNS autoritativo utilizan este registro para calcular y determinar qué registros NSEC3 para incluir en las respuestas a las solicitudes DNSSEC para inexistente nombres y tipos.

Cuando se utiliza el DNSSEC, cada respuesta a una consulta DNS contiene un registro DNS RRSIG, además el tipo de registro que fue solicitado. El registro RRSIG es una firma digital de la respuesta DNS registro de recursos conjunto. La firma digital es verificada por localizar la clave pública correcta en un registro DNSKEY. Los registros NS y NSEC3 se utilizan para proporcionar evidencia criptográfica de la inexistencia de cualquier RR. El registro DS se utiliza la autenticación de DNSKEYs en el procedimiento de búsqueda mediante la cadena de confianza. Registros NSEC y NSEC3 se utilizan para robusta resistencia contra la suplantación de identidad.

Algoritmos

DNSSEC fue diseñado para ser extensible así como se descubren los ataques contra los algoritmos existentes, nuevos pueden introducirse en un al revés-compatible moda. La siguiente tabla define, a partir de abril del de 2013, los algoritmos de seguridad que se utilizan más a menudo:

Campo de algoritmo	Algoritmo	Fuente	Estado de implementación
1	RSA/MD5		DESAPROBADO
3	DSA/SHA-1		opcional
5	RSA/SHA-1		Obligatorio
7	RSASHA1-NSEC3-SHA1	RFC 5155	se recomienda
8	RSA /SHA-256	RFC 5702	se recomienda
10	RSA /SHA-512		se recomienda
12	GOST R 34.10-2001	RFC 5933	opcional
13	ECDSA/SHA-256	RFC 6605	se recomienda
14	ECDSA /SHA-384		se recomienda

El procedimiento de búsqueda

De los resultados de una búsqueda de DNS, una conciencia de seguridad Resolución de DNS puede determinar si el servidor de nombres autorizado para el dominio que se consulta apoya DNSSEC, si la respuesta que recibe es segura, y si hay algún tipo de error. El procedimiento de búsqueda es diferente para servidores de nombre recursivos como las de muchos ISPy para resoluciones del trozo como los que se incluyen de forma predeterminada en los sistemas operativos. Microsoft Windows utiliza un trozo resolutor y Windows Server 2008 R2 y Windows 7 en particular utilizar un no-validar pero resolutor trozo DNSSEC-consciente.

Servidores de nombre recursivos

Usando el cadena de confianza modelo, un registro de delegación firmante (DS) en una matriz dominio (Zona DNS) puede utilizarse para verificar un registro DNSKEY en un subdominio, que luego pueden contener otros registros DS para verificar otros subdominios. Dicen que un resolutor recursivo tales como un servidor de nombre de ISP quiere que la IP direcciones)Un registro o Registros AAAA) del dominio "www.Example.com".

1. El proceso comienza cuando una resolución consciente de seguridad establece el bit de bandera "DO" en una consulta DNS. Puesto que la broca es en la marca extendida de bits definidos por EDNS, todas las transacciones de DNSSEC deben soportar EDNS. EDNS apoyo también es necesario para permitir que los tamaños de paquetes mucho más grandes que requieren las transacciones DNSSEC.
2. Cuando el resolutor recibe una respuesta mediante el proceso normal de búsqueda DNS, entonces comprueba para asegurarse de que la respuesta es correcta. Idealmente, la resolución de conciencia de seguridad empezaría con verificar los registros DS y DNSKEY en la Raíz DNS. Luego utilizaría los registros DS para el "com" dominio de nivel superior encontrados en la raíz para verificar los registros DNSKEY en la zona de "com". Desde allí, vería si hay un registro de DS para el subdominio "ejemplo.com" en la zona de "com", y si fuera así, entonces utilizaría el registro DS para verificar un registro DNSKEY encontrado en la zona "ejemplo.com". Finalmente, verificaría el registro RRSIG hallado en la respuesta para los registros de "www.example.com".

Hay varias excepciones para el ejemplo anterior.

En primer lugar, si "ejemplo.com" no admite DNSSEC, no habrá ningún registro RRSIG en la respuesta y no habrá un récord de DS para "ejemplo.com" en la zona de "com". Si hay un registro de DS para "ejemplo.com", pero ningún registro RRSIG en la respuesta, algo está mal y quizás un hombre en el medio del ataque está pasando, Desnudando la información DNSSEC y modificar los registros. O, podría ser un servidor de nombres ajenos-seguridad roto en el camino que despojó de la bandera de hacer un poco de la consulta o el registro del RRSIG de la respuesta. O, podría ser un error en la configuración.

A continuación, puede ser que no hay un nombre de dominio llamado "www.example.com", en cuyo caso en lugar de devolver un registro RRSIG en la respuesta, habrá un registro de Nanosegundos o un registro de NSEC3. Estos son los registros "al asegurar" que permiten la resolución demostrar que no existe un nombre de dominio. Los registros NS/NSEC3 tienen registros RRSIG, que se pueden comprobar que el anterior.

Por último, puede ser que la zona "ejemplo.com" implementa DNSSEC, pero no la zona de "com" o zona de la raíz, creando una "isla de seguridad" que debe ser validado de alguna otra manera. A partir del 15 de julio de 2010, despliegue de DNSSEC a raíz se haya completado. El dominio .com fue firmado con claves de seguridad válida y la delegación segura ha sido añadida a la zona radicular en 01 de abril de 2011.

Resoluciones del trozo

Resoluciones del trozo son "mínimas DNS resoluciones que utilizan el modo de consulta recursiva para descargar la mayor parte del trabajo de resolución de DNS a un servidor de nombres recursivos." Un resolutor trozo simplemente enviar una solicitud a un servidor de nombres recursivos y utilizar la autentica datos (AD) en la respuesta un poco como una "pista para averiguar si era capaz de validar las firmas de todos los datos en las secciones de respuesta y la autoridad de la respuesta del servidor de nombres recursivos". Microsoft Windows utiliza un trozo resolutor y Windows Server 2008 R2 y Windows 7 en particular utilizar un no-validar pero poco-AD-aware resolutor trozo.

A validar resolutor trozo también potencialmente puede realizar la validación de su propia firma estableciendo el bit de control deshabilitado (CD) en sus mensajes de consulta. Un resolutor trozo validación utiliza el bit de CD para llevar a cabo su propia autenticación recursivo. Utilizando a tal un resolutor trozo validación da al cliente seguridad DNS-to-end para dominios implementación DNSSEC, incluso si el proveedor de Internet o la conexión de ellas no es de confianza.

Para que la validación no trozo discernidor de imágenes colocar cualquier dependencia real servicios DNSSEC, el resolutor trozo debe confiar en ambos los recursivos servidores de nombres en cuestión (que normalmente es controlada por el Proveedor de servicios Internet) y los canales de comunicación entre sí mismo y los servidores de nombre, usando métodos tales como IPsec, SIG(0), o TSIG. El uso de IPsec no es generalizado.

Confianza anclas y cadenas de autenticación

Para ser capaces de demostrar que una respuesta DNS es correcta, tienes que saber al menos una clave o registro DS que proviene de fuentes que no sean el DNS correcto. Estos puntos de partida son conocidos como anclajes de confianza y se obtienen normalmente con la Sistema operativo o mediante alguna otra fuente de confianza. Cuando DNSSEC fue diseñado originalmente, se pensó que era el única ancla de confianza que sería necesario para el Raíz DNS. Los anclajes de raíz fueron inicialmente publicados el 15 de julio de 2010.

Un autenticación cadena es una serie de registros DS y DNSKEY vinculados, a partir de un ancla de confianza para el 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 puede ser autenticada firmemente.

Firmas y zona firma

Para limitar los ataques de repetición, no son sólo los valores normales de DNS TTL para almacenar en caché los propósitos, pero las marcas de tiempo adicional en los registros RRSIG para limitar la validez de una firma. A diferencia de valores TTL se encuentran relativo a cuando fueron enviados los registros, las marcas de hora son absolutas. Esto significa que todas las resoluciones DNS consciente de seguridad deben tener relojes que son bastante cerca en sincronía, decir que en pocos minutos.

Estas marcas de tiempo implican que una zona regularmente debe volver a firmar y redistribuida a servidores secundarios, o las firmas serán rechazadas por validar las resoluciones.

Gestión de claves

DNSSEC implica muchas claves diferentes, almacenadas en registros DNSKEY tanto de otras fuentes para formar anclajes de confianza.

Para permitir las llaves de repuesto, un rollover clave esquema es necesaria. Típicamente, esto implica primero desplegando nuevas llaves en nuevos registros DNSKEY, además de las llaves viejas existentes. Entonces, Cuándo es seguro asumir que el tiempo para vivir los valores han causado el almacenamiento en caché de llaves viejas que han pasado, pueden utilizar estas nuevas llaves. Finalmente, cuando es seguro asumir que el almacenamiento en caché de registros utilizando las llaves viejas han caducado, los viejos registros DNSKEY pueden ser eliminados. Este proceso es más complicado para las cosas tales como las llaves que confiar en anclajes, tales como la raíz, que puede requerir una actualización del sistema operativo.

Llaves en registros DNSKEY pueden utilizarse para dos cosas diferentes y normalmente se utilizan diferentes registros DNSKEY para cada uno. En primer lugar, hay Clave de firma de claves (KSK) que se utilizan para firmar otros registros DNSKEY. En segundo lugar, hay Zona firma llaves (ZSK) que se utilizan para firmar otros registros. Puesto que el ZSKs bajo el completo control y usan particular Zona DNS, puede cambiar más fácilmente y más a menudo. Como resultado, ZSKs puede ser mucho más cortos que KSKs y todavía ofrecen el mismo nivel de protección mientras que reduce el tamaño de los registros RRSIG/DNSKEY.

Cuando se crea un nuevo KSK, el registro DS debe ser trasladado a la zona principal y publicó allí. El DS registra uso un Resumen de mensaje del KSK en lugar de la llave completa para mantener el tamaño de los archivos pequeños. Esto es útil para zonas tales como la .com dominio, que son muy grandes. El procedimiento para actualizar las llaves DS en la zona principal también es más simple que las versiones anteriores de DNSSEC que requieren registros DNSKEY a estar en la zona principal.

Grupo de trabajo de DANE

Autenticación basada en DNS de entidades nombradas (DANE) es un grupo de trabajo IETF con el objetivo de desarrollar protocolos y técnicas que permiten Internet aplicaciones establecer criptográficamente aseguraron las comunicaciones con TLS, DTLS, SMTP, y S/MIME basado en DNSSEC.

Los nuevos protocolos permitirá garantías adicionales y restricciones para el modelo tradicional basado en Infraestructura de clave pública. También permitirán afirmar certificados por sí mismos, sin hacer referencia a terceros los titulares de dominio autoridades de certificación.

Soporte para certificados de DNSSEC grapado fue habilitado en Google Chrome 14, Pero más tarde fue eliminado. Para Mozilla Firefox, la ayuda es proporcionada por un complemento mientras que soporte nativo está llevando a cabo.

Historia

DNS es un servicio de Internet crítico y fundamental, todavía en 1990 Steve Bellovin descubierto fallos de seguridad graves en él. Investigación sobre fijación comenzó y aumentó dramáticamente cuando su papel se hizo pública en 1995. La inicial RFC 2065 fue publicado por la IETF en 1997 e iniciales intentos de implementar esa especificación conducido a una revisada (y creía totalmente realizable) especificación en 1999 como IETF RFC 2535. Se hicieron planes para implementar DNSSEC basado en RFC 2535.

Desafortunadamente, el IETF RFC 2535 Especificación tenía problemas muy importantes escalado a Internet completo; en 2001 se hizo evidente que esta especificación era inutilizable para redes grandes. En funcionamiento normal DNS servidores a menudo conseguir fuera de sincronía con sus padres. Esto no es generalmente un problema, pero cuando DNSSEC está habilitada, esta fuera de sincronización datos podrían tener el efecto de un grave auto-creada de denegación de servicio. La DNSSEC original requiere un protocolo de mensajes de seis complejo y un montón de las transferencias de datos para realizar cambios clave para un niño (DNS zonas tuvieron que enviar todos sus datos a los padres, que el padre firme cada registro y luego enviar esas firmas al niño por el niño almacenar en un registro SIG). Además, los cambios de clave públicos podrían tener efectos absurdos; por ejemplo, si la zona de ".com" cambió su clave pública, tendría que enviar registros 22 millones (porque sería necesario actualizar todas las firmas de todos sus hijos). Por lo tanto, DNSSEC como se define en RFC 2535 No podría escalar a la Internet.

El IETF modificado fundamentalmente DNSSEC, que se llama DNSSEC-bis Cuando sea necesario para distinguirla del enfoque original de DNSSEC RFC 2535. Esta nueva versión utiliza "registros de recursos de delegación firmante (DS)" para proporcionar un nivel adicional de direccionamiento indirecto en los puntos de la delegación entre una zona de padres e hijos. En el nuevo enfoque, cuando cambia de clave pública maestro de un niño, en lugar de tener que tener seis mensajes por cada registro en el niño, hay un mensaje simple: el niño envía la nueva clave pública a sus padres (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 unos pocos datos es empujados a los padres, en lugar de enormes cantidades de datos que se intercambian entre los padres e hijos. Esto significa que los clientes tienen que trabajar un poco más al verificar las llaves. Más específicamente, verificación clave RRset de una zona DNS requiere dos operaciones de verificación de firma en lugar del requerido por RFC 2535 (no es ningún 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 más práctico implementación DNSSEC.

Zona enumeración emisión, controversia y NSEC3

Aunque la meta de DNSSEC es aumentar la seguridad, DNSSEC definida en RFC 4033 mediante 4035 presenta un nuevo problema que muchos creen es una nueva vulnerabilidad de seguridad: la enumeración de zona (aka zona caminando) tema. DNSSEC obliga a la exposición de información que por práctica mejor DNS normal se mantiene como privado. NSEC3)RFC 5155) fue desarrollado para tratar este tema; fue lanzado en marzo de 2008. NSEC3 mitiga, pero no eliminar, enumeración de la zona, ya que es posible buscar exhaustivamente el conjunto de todos los nombres posibles en una zona.

¿Por qué los datos de zona DNS normalmente se mantienen privados

Cuando se diseñó el protocolo DNS, no se pretende ser un repositorio de información oculta. Sin embargo, desde el DNS casa información sobre el funcionamiento interno de una red relacionada con un dominio dado, muchos ven el contenido de su base de datos DNS como privado. En particular, los sistemas DNS típicamente están configurados para que la mayoría de usuarios no pueden descargar la lista completa de nombres u otra información en una zona. Dicha lista facilitaría trabajo de un atacante, ya que de lo contrario tendrían que manualmente recopilar información acerca de qué máquinas existen. Algunos administradores de publican información sensible en sus bases de datos DNS que es aún más valiosa para un atacante. El libro ampliamente utilizado DNS y BIND (4ª edición) por Albitz y Liu lo explica así:

Podría decirse que aún más importante que controlar quién puede consultar nuestro servidor de nombres es asegurar que sólo los servidores de nombre verdadero esclavo pueden transferir las zonas desde el servidor de nombre. Los usuarios en los hosts remotos sólo pueden buscar registros (por ejemplo, las direcciones) para nombres de dominio que ya saben, uno a la vez. Es la diferencia entre dejar al azar la gente llame centralita de su compañía y pregunte por el número de teléfono de John Q. Cubicle [frente] enviándoles una copia de su directorio telefónico corporativo.

Además, puede utilizarse la información de una zona enumerada como una clave para múltiples WHOIS consultas; Esto podría revelar datos de Registrante que muchos registros están bajo estrictas obligaciones jurídicas para proteger varios contratos.

No está claro si DNSSEC es legal para implementar en absoluto en muchos países, a menos que tales listas pueden mantenerse en privado. DENIC ha declarado que tema de DNSSEC zona enumeración viola la Ley Federal de protección de datos de Alemania y otros países europeos tienen leyes de privacidad similares prohibiendo el lanzamiento público de ciertos tipos de información.

DNSSEC revela datos de la zona

Diseño original de DNSSEC Obligatorio que toda la lista de nombres de zona se revela a todos. Como se indica en RFC 4033,

DNSSEC presenta la capacidad de una parte enemiga a enumerar todos los nombres en una zona siguiendo la cadena de Nanosegundos. NSEC RRs afirman que los nombres no existen en una zona mediante la vinculación de nombre existente con 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 NS en secuencia para obtener todos los nombres en una zona. Aunque esto no es un ataque contra el DNS sí mismo, podría permitir que un atacante mapa hosts de la red u otros recursos mediante la enumeración de los contenidos de una zona.

Hay una solución "obvia", llamada un horizonte dividido DNS, que es cómo se implementa a veces DNS sin DNSSEC — pero este enfoque no funciona bien con DNSSEC. En el planteamiento de "DNS de horizonte dividido", el servidor DNS niega la existencia de nombres a algunos clientes y proporciona la información correcta a otros clientes. Sin embargo, desde información de DNSSEC criptográficamente firmado como autoritativo, un atacante podría solicitar el registro firmado "no existe", entonces retransmitir el registro para provocar una denegación de servicio. DNSSEC cambia fundamentalmente DNS así puede proporcionar información autorizada; por lo tanto, no funciona bien con métodos basados en información falsa para algunos usuarios. Las investigaciones han producido recomendaciones para combinar correctamente estas dos características DNS.

DNSSEC presentó este problema porque debe ser capaz de informar cuando un nombre es No encontrado. Los servidores DNS soporte DNSSEC deben ser capaces de firmar ese informe no-encontró — de lo contrario podría ser falsificado fácilmente un informe no-encontró. Sin embargo por razones de seguridad la clave de firma no debe ser en línea. Como resultado, DNSSEC fue diseñado para informar sobre un mensaje firmado que informa que no existe una determinada gama de nombres, que puede ser firmado antes de tiempo sin conexión. Desafortunadamente, esta información es suficiente para un atacante ganar mucho más información de otra manera hubiera sido disponibles para ellos, es suficiente para permitir a un atacante reunir rápidamente todos los nombres en una zona y luego a través de consultas específicas sobre los nombres para reconstruir todas o la mayoría de los datos de una zona.

Como se señaló anteriormente, DNSSEC podría utilizarse como base para un mundial infraestructura de clave pública para direcciones de correo electrónico, mediante el uso de DNS para servir a los certificados de correo electrónico y DNSSEC para validarlas. Sin embargo, esta cuestión DNSSEC hace poco probable para la mayoría de las organizaciones, por lo menos si se utiliza directamente. Como RFC 4398 dice, "Si una organización decide emitir certificados para sus empleados, colocando CERT RRs en el DNS por nombre del propietario, y si DNSSEC (con NSEC) está en uso, es posible que alguien pueda enumerar a todos los empleados de la organización. Esto generalmente no se considera deseable, por la misma razón que empresa teléfono listados no se publican a menudo públicamente y ni siquiera están marcados confidenciales."

Reacción inicial

Muchos de los participantes en el grupo de trabajo IETF DNS Extensions originalmente afirmó que la enumeración de la zona no era un problema significativo, argumentando que los datos DNS eran — o debería — público. Sin embargo, registradores y muchas grandes organizaciones dijo que a los miembros del grupo de trabajo que DNSSEC como actualmente definido era inaceptable, y que lo hicieran no o legalmente no puede desplegar.

Firma on-line

Una estrategia para la prevención de la enumeración de la zona se codificó en RFC 4470. En lugar de firmar por adelantado las respuestas no-encontró, no encontraron respuesta 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 'correo.ejemplo.com', que revela la existencia de 'correo.ejemplo.com', la respuesta podría ser que 'no hay nombres entre b.example.com y ba.example.com'. Si la consulta siguiente pregunta sobre 'ba.example.com', la respuesta podría ser 'no hay nada de nombres entre ba.example.com y baa.example.com'. Esto hace que enumerar impráctica toda la zona.

Este enfoque tiene algunas desventajas. Se requiere una firma clave para mantenerse en línea y accesible para cada servidor DNS. Muchas claves de firma de zona se mantienen en línea de todos modos apoyo automático a firmar o actualizaciones dinámicas de la zona, pero estas funciones son necesarios sólo en un único servidor DNS principal, mientras que soporte on-line firma la zona clave de firma debe mantenerse en cada servidor DNS autoritativo. Algunos servidores autoritativos deben ser accesibles desde Internet e idealmente estos serán ampliamente dispersados, haciéndolo difícil de mantener bajo control las llaves. También se requiere cuidado para evitar que un atacante inundar el servidor DNS con las solicitudes de nombres falsos, negar el servicio a los usuarios legítimos.

NSEC3

Después de deliberar, se desarrolló una extensión: "DNSSEC hash autenticado la negación de la existencia" (informalmente llamado "NSEC3"). En este enfoque, servidores DNSSEC-consciente pueden elegir enviar un registro "NSEC3" en lugar de un registro NS cuando no se encuentra un registro. El registro NSEC3 está firmado, pero en lugar de incluir el nombre directamente (que permitiría enumeración zona), el registro de NSEC3 incluye un valor hash criptográficamente del nombre. El disco de NSEC3 incluye tanto un hash después de un número de iteraciones y una sal opcional, los cuales reducen la efectividad de los ataques de diccionario pre computado. Salazón aumenta el número de diccionarios necesarios para un ataque, mientras que iteraciones hash adicional aumentan el costo de cada Diccionario de computación.

Los partidarios de la DNSCurve sostienen que todavía es fácil enumerar una zona protegida por NSEC3 y presente un prueba de concepto implementación. Este ataque podría mitigarse mediante el uso de funciones hash más cálculo intensivo.

RFC 5155 formalmente definido NSEC3 en marzo de 2008.

Despliegue

Internet es la infraestructura crítica, sin embargo, su funcionamiento depende el DNS fundamentalmente inseguro. Por lo tanto, hay fuertes incentivos para garantizar DNS e implementación DNSSEC es considerada una parte crítica de ese esfuerzo. Por ejemplo, Estados Unidos Estrategia nacional para garantizar el ciberespacio identificados específicamente la necesidad de asegurar el DNS. Despliegue de gran escala de DNSSEC podría resolver muchos otros problemas de seguridad, así como la distribución segura de claves para direcciones de correo electrónico.

También es difícil implementación DNSSEC en redes de gran escala. Ozment y Schechter observan que DNSSEC (y otras tecnologías) tienen un "problema de arranque": los usuarios normalmente sólo implementación una tecnología si reciben un beneficio inmediato, pero si un nivel mínimo de implementación es necesaria antes de cualquier los usuarios reciben un beneficio mayor que sus costos (como sucede con DNSSEC), es difícil de implementar. DNSSEC puede implementarse en cualquier nivel de una jerarquía DNS, pero debe estar ampliamente disponible en una zona antes muchos otros querrán adoptarlo. Los servidores DNS deben ser actualizados con el software que soporta DNSSEC y DNSSEC datos deben ser creados y añadidos a los datos de zona DNS. Un cliente TCP/IP-uso debe tener su resolución DNS (cliente) actualizado antes de que se pueden utilizar las capacidades de DNSSEC. Por otra parte, cualquier resolución debe tener, o tener un modo de adquirir, por lo menos una clave pública que puede confiar antes de que pueda comenzar a utilizar DNSSEC.

Implementación DNSSEC puede agregar carga significativa a algunos servidores DNS. Respuestas comunes firmado DNSSEC son mucho más grandes que el tamaño predeterminado 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 manejas 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 TCP; servidores muy cargados pueden quedarse sin recursos simplemente tratando de responder a un mayor número de solicitudes DNSSEC (posiblemente falsos). Algunos protocolo extensiones, tales como TCP Cookie transacciones, se han desarrollado para reducir esta carga. Para enfrentar estos desafíos, significativo esfuerzo está en curso para implementar DNSSEC, dado que Internet es tan vital para muchas organizaciones.

Primeras implementaciones

Adoptadores tempranos incluyen Brasil (.br), Bulgaria (.bg), República Checa (.cz), Puerto Rico (PR) y Suecia (.se), que utilizan DNSSEC para su Dominios de nivel superior de código de país; RIPE NCC, que han suscrito todos los búsqueda inversa registros (in-addr.arpa) que se delegan a él de la Autoridad de números asignados de Internet (IANA). ARIN también se está firmando sus zonas de marcha atrás. En febrero de 2007 TDC se convirtió en el primer ISP sueco para empezar a ofrecer esta función a sus clientes.

IANA probado públicamente un muestra de raíz firmado desde junio de 2007. Durante este periodo previo a la firma de producción de la raíz, también hubo varias alternativas confianza anclas. La Jena IKS introducido uno el 19 de enero de 2006, el Internet Systems Consortium otro presentó el 27 de marzo del mismo año, al mismo tiempo ICANN se anunció una tercera el 17 de febrero de 2009.

Una amplia variedad de proyectos piloto y los experimentos son y han sido realizadas. DNSSEC.net mantiene una lista de dichos proyectos. También hay un mapa de Google de Mundo DNSSEC amplio despliegue.

En 02 de junio de 2009, el Registro de interés público firmó la zona org. El registro público de Internet también detalló el 26 de septiembre de 2008, que la primera fase, que implica a grandes registradores tiene una fuerte relación de trabajo con ("amigos y familiares") será el primero en ser capaz de firmar sus dominios, empezando "principios de 2009". El 23 de junio de 2010, 13 secretarios fueron catalogados como ofreciendo los registros de dominios .ORG DNSSEC.

VeriSign fue un proyecto piloto para permitir que los dominios .com y. net a registrarse con el propósito de experimentación NSEC3. El 24 de febrero de 2009, anunciaron que desplegaría DNSSEC en todos sus dominios de primer nivel (.com,. net, etc.) dentro de 24 meses, y el 16 de noviembre del mismo año, dijeron que los dominios .com y. net sería firmados por el primer trimestre de 2011, después de retrasos provocados por los aspectos técnicos de la aplicación. Esta meta fue alcanzada en calendario y VP de Verisign DNSSEC, Matt Larson, ganó InfoWorld Technology Leadership Award 2011 por su papel en el avance de DNSSEC.

Despliegue en la raíz DNS

DNSSEC primero fue desplegado en el nivel raíz de 15 de julio de 2010. Se espera que simplificar enormemente la implementación de resoluciones DNSSEC, puesto que el ancla de confianza raíz puede utilizarse para validar cualquier zona DNSSEC que cuenta con una completa cadena de confianza desde la raíz. Puesto que la cadena de confianza que se remonta a una raíz de confianza sin interrupción para validar, anclajes de confianza deben todavía ser configurados para zonas seguras si cualquiera de las zonas por encima de ellos no son segura. Por ejemplo, si la zona de "signed.example.org" estaba asegurada pero el "ejemplo.org" - zona no era, entonces, aunque el ".org" - zona y la raíz se firman un ancla de confianza tiene que implementarse a fin de validar la zona.

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

• Otros países están preocupados sobre el control de Estados Unidos sobre el Internet y pueden rechazar cualquier incrustación centralizado por este motivo.
• Algunos gobiernos podrían intentar prohibir la distribución de claves de cifrado respaldados por DNSSEC.

Planificación

En septiembre de 2008, ICANN y VeriSign cada publican propuestas de implementación y en octubre, la Nacional de telecomunicaciones y administración de la información (NTIA) pidió al público para comentarios. No está claro si los comentarios recibidos afectaron el diseño del plan de implementación final.

El 03 de junio de 2009, el National Institute of Standards and Technology (NIST) anunció que planea firmar la raíz para finales de 2009, en conjunto con ICANN, VeriSign y la NTIA.

En 06 de octubre de 2009, en el 59 MADURO Conferencia, ICANN y VeriSign anunció el cronograma de implementación prevista para implementación DNSSEC dentro de la zona raíz. En la reunión se anunció que podría desplegarse progresivamente a un servidor de nombres raíz un mes, a partir de 01 de diciembre de 2009, con el servidor de nombres raíz final sirviendo un DNSSEC firmado zona el 01 de julio de 2010, y la zona de la raíz se firmará con una DNSKEY RSA/SHA256. Durante el período de despliegue incremental la zona radicular servirá un Unvalidatable deliberadamente la zona raíz (DURRËS) que utiliza llaves ficticia, con el registro DNSKEY final no siendo distribuido hasta el 01 de julio de 2010. Esto significa que las claves que se utilizaron para firmar el uso de la zona son deliberadamente no verificables; el motivo de este despliegue era monitorizar los cambios en los patrones de tráfico causados por las grandes respuestas a consultas solicitando registros de recursos de DNSSEC.

El .org dominio de nivel superior se ha firmado con DNSSEC en junio de 2010, seguido por .com, .net, y .edu más tarde en 2010 y 2011. Dominios de nivel superior de código de país fueron capaces de depositar las llaves a partir de mayo de 2010. A partir de noviembre de 2011 más del 25% de dominios de nivel superior están firmado con DNSSEC.

Implementación

El 25 de enero de 2010, el servidor raíz L (ell) comenzó a servir una Unvalidatable deliberadamente la zona raíz (DURRËS). La zona utiliza firmas de un SHA-2 Hash (SHA-256) creado mediante el RSA algoritmo, como se define en RFC 5702. A partir de mayo de 2010, todos los servidores raíz trece han empezado a servir el DURRËS. El 15 de julio de 2010, la primera producción de raíz completa zona raíz DNSSEC se firmó, con el SOA serial 2010071501. Raíz confianza anclajes disponible de IANA.

Implementación a nivel TLD

Debajo de la raíz hay una gran cantidad de dominios de nivel superior que debe ser firmado con el fin de lograr la plena implementación DNSSEC. El Lista de dominios de nivel superior de Internet proporciona detalles sobre cuál de los dominios de nivel superior existentes han sido firmados y vinculado a la raíz.

DNSSEC Lookaside validación

En marzo de 2006, la Internet Systems Consortium introdujo el registro DNSSEC Lookaside validación. DLV fue pensada para hacer más fácil de desplegar en la ausencia de un anclaje de confianza raíz DNSSEC. En ese momento se fue imaginado que podría tener un validador mantener grandes cantidades de confianza anclajes correspondientes a firmado subárboles del DNS. El propósito de DLV era permitir validadores descargar el esfuerzo de la administración de un repositorio de anclaje de confianza a un tercero de confianza. El registro de DLV mantiene una lista central de anclas de confianza, en lugar de cada validador repitiendo el trabajo de mantener su propia lista.

Para utilizar DLV, es necesario un validador que lo sostiene, tales como BIND o Independiente, configurado con un ancla de confianza para una zona DLV. Esta zona contiene registros DLV; Estas 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 de DNS. Cuando el validador no puede encontrar una cadena de confianza desde la raíz a la RRset está tratando de comprobar, busca un récord DLV que puede proporcionar una cadena alternativa de confianza.

DLV sigue siendo útil después de la raíz se ha firmado. Mientras que hay vacíos en la cadena de confianza, tales como dominios de nivel superior sin firmar, o los registradores que no soportan las delegaciones DNSSEC, hostmasters de dominios de nivel inferior puede utilizar DLV para facilitar a sus usuarios validar sus datos DNS.

Iniciativa de implementación DNSSEC por el gobierno federal de Estados Unidos

La ciencia y la dirección de tecnología de la Estados Unidos Departamento de seguridad nacional (DHS) patrocina la "iniciativa de implementación DNSSEC". Esta iniciativa alienta a "todos los sectores a adoptar voluntariamente las medidas de seguridad que mejorarán la seguridad de la infraestructura nombres de Internet, como parte de un esfuerzo cooperativo global que involucra a muchas naciones y organizaciones en los sectores público y privado". DHS también financia los esfuerzos que maduran DNSSEC y desplegado dentro del gobierno federal de Estados Unidos.

Se informó de que el 30 de marzo de 2007, el Estados Unidos Departamento de seguridad nacional propuso "que"tiene la llave para firmar la zona raíz DNS sólidamente en manos del gobierno estadounidense. Sin embargo no hay funcionarios del gobierno de Estados Unidos estuvieron presentes en la sala de reuniones y el comentario que provocó el artículo fue hecho por otro partido. Más adelante comentó DHS en por qué creen que otros saltaron a la conclusión falsa de que el gobierno estadounidense había hecho una propuesta: "el Departamento de seguridad nacional de Estados Unidos está financiando el desarrollo de un plan técnico de implementación DNSSec y octubre pasado distribuyó un borrador inicial de a la larga lista de expertos internacionales para comentarios. El proyecto establece una serie de opciones para quién podría ser el titular, u "operador" de la clave de zona raíz, esencialmente hirviendo a una agencia gubernamental o un contratista. "Ninguna parte del documento hacemos cualquier propuesta sobre la identidad del operador clave raíz," dijo Maughan, la seguridad cibernética Gerente de investigación y desarrollo para la seguridad nacional.

Implementación DNSSEC en el gobierno federal de Estados Unidos

El National Institute of Standards and Technology (NIST) publicado NIST Special Publication 800-81 Secure Domain Name System (DNS) Deployment Guide el 16 de mayo de 2006, con orientación sobre cómo implementar DNSSEC. NIST pretende lanzar nuevos requisitos de DNSSEC Federal información Security Management Act (FISMA) en la NIST SP800-53-R1, hace referencia a esta guía de implementación. Agencias de Estados Unidos entonces habría tenido un año después de la publicación final del NIST SP800-53-R1 para satisfacer estos nuevos requerimientos de FISMA. Sin embargo, en el momento que nsec3 no habían concluido. NIST había sugerido utilizar dominios de split, una técnica que se sabe que es posible, pero es difícil de implementar correctamente y tiene las debilidades de seguridad mencionadas.

22 de agosto de 2008, la oficina de gerencia y presupuesto (OMB) publicaron un memorando que requiere Estados Unidos las agencias federales para implementar DNSSEC en .gov sitios; la raíz .gov debe ser firmada en enero de 2009, y todos los subdominios bajo .gov deben ser firmados en diciembre de 2009. Mientras que el memo se concentra en sitios .gov, la Agencia de sistemas de información de Estados Unidos Defensa dice que pretende cumplir requisitos OMB DNSSEC en el dominio .mil (militar EEUU) así como. Carolyn Duffy Marsan de NetworkWorld declaró que DNSSEC "no ha sido ampliamente desplegado porque sufre un dilema clásico del huevo y la gallina, con el mandato de la OMB, parece que el huevo se está agrietando."

Implementación DNSSEC en resoluciones

Varios ISPs han comenzado a implementar a resoluciones validación de DNSSEC DNS recursivos. Comcast se convirtió en el primer ISP principal en los Estados Unidos, anunciando sus intenciones el 18 de octubre de 2010 y completar el despliegue el 11 de enero de 2012.

Según estudio de CircleID, ha aumentado la proporción de clientes que utilizan exclusivamente las resoluciones DNS que realicen la validación de DNSSEC a 8,3% en mayo de 2013. Aproximadamente la mitad de estos clientes estaban usando Resolución de DNS público de Google.

Google Public DNS

Google Public DNS es un servicio DNS proporcionado libremente, público, totalmente soporte DNSSEC.

En su lanzamiento en 2009, Google Public DNS no apoyó DNSSEC. Por supuesto podrían consultar los registros RRSIG, pero nunca se creó la bandera de AD (datos autenticados, significa que el servidor fue capaz de validar las firmas de todos los datos).

El 28 de enero de 2013, los servidores DNS de Google silenciosamente comenzaron a proporcionar información de validación de DNSSEC, Pero sólo si el cliente establece explícitamente la bandera DNSSEC OK (DO) en su consulta.

En 06 de mayo de 2013, Google Public DNS habilita la validación de DNSSEC por defecto; significa que todas las consultas será validado a menos que los clientes optan explícitamente.

Temas

Ha sido conocido por descanso adecuado MX record búsqueda en Microsoft Exchange 2013 y mayores causando #550 4.4.7 cola.Errores caducados.

Herramientas

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

• Windows 7 y Windows Server 2008 R2 incluyen a un resolutor trozo ""seguridad-consciente que es capaz de distinguir entre las respuestas seguras y no seguras por un servidor de nombres recursivos. Windows Server 2012 DNSSEC es compatible con las actualizaciones dinámicas seguras con las zonas integradas en Active Directory, además de replicación de Active Directory de teclas de anclaje para otros dichos servidores.
• BIND, el más popular servidor de nombres DNS (que incluye Cave), incorpora las más recientes DNSSEC-bis Protocolo (registros DS) así como soporte para registros de NSEC3.
• Taladro es un DNSSEC habilitado Cave-como herramienta liado con ldns.
• Taladro extensión para Firefox agrega a Mozilla Firefox la capacidad de determinar si un dominio puede ser verificado mediante DNSSEC.
• DNSSEC-Tools tiene como objetivo proporcionar herramientas fáciles de usar para ayudar a todos los tipos de los administradores y usuarios hace uso de DNSSEC. Ofrece herramientas para administradores de Zonas autorizadas, Servidor autorizado, y Servidores recursivos así como una biblioteca y herramientas para Desarrolladores de aplicaciones parches existentes para la ampliación y usos comunes.
• Phreebird es un proxy DNS que puede añadir soporte DNSSEC encima de cualquier otro servidor DNS.
• Zona clave herramienta es un software diseñado para facilitar el mantenimiento de las zonas conscientes de DNSSEC. Está diseñado principalmente para entornos con un pequeño número medio de zonas y proporciona una zona completamente automática firma rollover clave, así como la dimisión automática de la zona.
• Independiente es un servidor de nombres DNS que fue escrito desde el suelo hasta ser diseñado en torno a conceptos DNSSEC.
• GbDns es un servidor de nombre DNSSEC, compacto, fácil de instalar, para Microsoft Windows.
• UnxsBind La GPL Software de administración de DNS para DNS ASPs ahora soporta DNSSEC.
• OpenDNSSEC está utilizando una herramienta de firmante DNSSEC designada PKCS #11 para conectar con Módulos de seguridad de hardware.
• SecSpider pistas de implementación DNSSEC, monitorea las zonas y proporciona una lista de claves públicas observadas.
• DNSViz y Analizador de DNSSEC son herramientas basadas en Web para visualizar la cadena DNSSEC de autenticación de un dominio.
• DNSSEC/TLSA Validator es un Mozilla Firefox addon para la visualización del estado de DNSSEC del nombre de dominio visitado, el DNSSEC/TLSA validador 2.1 ha añadido soporte para comprobar y visualizar el estado de los registros TLSA (DANE).
• DNSSHIM o DNS Secure oculta Master es una herramienta de código abierto para automatizar DNSSEC respaldado por zonas de proceso de aprovisionamiento.
• Net::DNS::sec es una resolución DNS implementada en Perl.
• Nudo DNS ha añadido soporte para DNSSEC automático firma en versión 1.4.0.
• PowerDNS totalmente compatible con DNSSEC desde la versión 3.0 en modos previamente firmadas y firmado por vivir.

Véase también

• EDNS -extensión a DNS para permitir que los paquetes más grandes utiliza DNSSEC y la bandera un poco
• TSIG -utiliza para autenticar correctamente las transacciones entre los servidores de nombre y resolución
• DNSCurve -peso ligero cifrado y autenticación entre servidores de nombres y resoluciones.
• DNSCrypt -implementación de DNSCurve utilizado por OpenDNS.
• RPKI -una tecnología similar aplicada a registro enrutamiento de Internet

Lectura adicional

• Hao Yang; Osterweil, E.; Massey, D.; Songwu Lu, Lixia Zhang, (01 de septiembre de 2011). "Implementación de criptografía en Internet-Scale Systems: A Case Study on DNSSEC". IEEE Transactions on computación confiable y segura 8 (5): 656 – 669. Doi:10.1109/TDSC.2010.10.

Enlaces externos

Organizaciones/sitios web

• DNSSEC -Sitio de DNSSEC información: DNSSEC.net
• DNSEXT Extensiones DNS Grupo de trabajo IETF
• CircleID - noticias y opiniones sobre DNSSEC todos temas relacionados con
• Proyecto DNSSEC-Tools
• Iniciativa de coordinación de implementación DNSSEC
• Equipo de implementación DNSSEC
• Equipo de operaciones de ICANN DNS

Estándares

• RFC 2535 Extensiones de seguridad de sistema de nombres de dominio
• RFC 3833 Un análisis de las amenazas del sistema de nombres de dominio
• RFC 4033 (Introducción de seguridad DNS y requisitosDNSSEC-bis)
• RFC 4034 Los registros de recursos para la seguridad DNS (extensionesDNSSEC-bis)
• RFC 4035 Protocolo de modificaciones para la seguridad DNS (extensionesDNSSEC-bis)
• RFC 4398 Almacenamiento de certificados en el Domain Name System (DNS)
• RFC 4470 Cubriendo mínimamente registros NSEC y DNSSEC firma on-line
• RFC 4509 Uso de SHA-256 en DNSSEC delegación firmante (DS) registros de recursos (RR)
• RFC 5155 DNSSEC hash autenticado la negación de la existencia
• RFC 6781 DNSSEC prácticas operacionales, versión 2

Otros documentos

• Una mirada Fundamental en DNSSEC, despliegue y DNS Security Extensions por Geoff Huston
• "Utilizando el sistema de nombres de dominio para sistema robos" por Steve Bellovin, 1995
• Una breve cronología de DNSSEC por Miek Gieben
• Lo que permite la resolución de nombres seguros usando DNSSEC para diversas aplicaciones
• DNSSEC Howto por Olaf Kolkman (RIPE NCC/NLnet Labs)
• Cómo asegurar su zona (inversa) por Holger Zuleger
• ¿Seguridad de correo electrónico más fácil es el camino?
• "DNSSEC y la enumeración de zona" por Marcos Sanz
• Publicación especial de NIST (SP) 800-81, asegure la guía de implementación de sistema (DNS) de nombre de dominio, De mayo de 2006
• La adopción de protocolos de seguridad de Internet de arranque, Andy Ozment y Stuart E. Schechter, 26 – 28 de junio de 2006
• DNSSEC BRIEFING y firma de la zona de la raíz (parte I), papel de ccTLD en DNSSEC por ccNSO, febrero de 2008
• U.S. Estrategia nacional para garantizar el ciberespacio, Febrero de 2003
• Cybertelecom:: Seguridad DNS & USG política
• SecSpider herramienta para el seguimiento de implementación DNSSEC
• Clegg, Alan (2008). "DNSSEC en 6 minutos". Internet Systems Consortium. Archivado de el original el 10 de mayo de 2013.
• Implementación DNSSEC Cisco Internet Protocol Journal
• Informe de ICANN TLD DNSSEC (generados diariamente)

Otras Páginas

• Motor Ferrari Colombo
• Quiropractica americana Junta de medicos deportivos
• WebApp.Net
• Esquema del software
• Mariposa botnet
• Dani Sanchez (futbolista)
• Coacoyula De Alvarez
• Erupcion