FANDOM


Las Extensiones de seguridad para el Sistema de Nombres de Dominio ( del inglés Domain Name System Security Extensions, o DNSSEC) es un conjunto de especificaciones de la Internet Engineering Task Force (IETF) para asegurar cierto tipo de información proporcionada por el sistema de nombre de dominio (DNS) que se usa en el protocolo de Internet (IP). Se trata de un conjunto de extensiones al DNS que proporcionan a los clientes DNS (o resolvers) la autenticación del origen de datos DNS, la negación autenticada de la existencia e integridad de datos, pero no disponibilidad o confidencialidad.

Contenido [ocultar]
1 Descripción
2 ¿Cómo funciona?
2.1 Registros
2.1.1 Algoritmos
2.2 El procedimiento de búsqueda
2.2.1 Servidores de nombres recursivos
2.2.2 Stub resolvers
2.3 Anclas de confianza y cadenas de autenticación
2.4 Firmas y firmas de zona
2.5 La gestión de claves
2.6 Grupo de Trabajo DANE
3 Historia
4 Véase También
5 Referencias
6 Enlaces externos
6.1 Organizaciones / sitios web
6.2 Normas
6.3 Otros documentos
Descripción: El diseño original del Domain Name System (DNS) no incluía la seguridad, sino que fue diseñado para 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. El RFC 3833 intenta documentar algunas amenazas conocidas en el DNS y cómo DNSSEC responde a esas amenazas.

DNSSEC fue diseñado para proteger a los resolvers de Internet (clientes) de datos de DNS 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 encriptan. 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 sólo 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 ampliamente1 que asegurar los DNS es de vital importancia para la seguridad en Internet como un todo, 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 resovers (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.

¿Cómo funciona?: DNSSEC trabaja firmando digitalmente estos registros para la búsqueda de DNS mediante criptografía de clave pública. El registro DNSKEY correcto se autentica 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:2Campo del Algoritmo Algoritmo Fuente
0 Reservado RFC 4034
1 RSA/MD5
3 DSA/SHA-1
5 RSA/SHA-1
7 RSASHA1-NSEC3-SHA1 RFC 5155
8 RSA/SHA-256 RFC 5702
10 RSA/SHA-512
12 GOST R 34.10-2001 RFC 5933
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.3 4

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".
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.
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 del 2010 se completó el despliegue de DNSSEC en la raíz5 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.6

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".7 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. "8 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.3 4

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.8 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.8 El uso de IPsec no está muy extendido9

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

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 de su envío, las marcas de tiempo son absolutas. Esto significa que todos los resolvers DNS conscientes de seguridad deben tener relojes que bastante sincronizados, tipo cercanos en pocos 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 IETF11 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.12

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

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