Extensiones de seguridad del sistema de nombres de dominio

DNSSEC en la pila de protocolos TCP / IP :
solicitud DNSSEC
transporte UDP TCP
Internet IP ( IPv4 , IPv6 )
Acceso a la red Ethernet
Bus simbólico
Anillo simbólico 		FDDI ...

Las Nombre de Dominio de Seguridad Extensions del sistema ( DNSSEC ) son una serie de Internet estándares que los mecanismos de seguridad complemento a la Sistema de nombres de dominio (DNS) para garantizar la autenticidad e integridad de los datos. Un participante de DNS puede usar esto para verificar que los datos de la zona DNS recibidos sean realmente idénticos a los autorizados por el creador de la zona. DNSSEC se desarrolló como un remedio contra el envenenamiento de la caché . Asegura la transmisión de registros de recursos mediante firmas digitales . No hay autenticación de servidores o clientes.

DNSSEC no proporciona confidencialidad , por lo que los datos de DNS no están encriptados .

Información general

DNSSEC utiliza un criptosistema asimétrico . El "propietario" de la información, generalmente el servidor maestro en el que se encuentra la zona de cobertura , firmó todos los registros con su clave secreta ( clave privada en inglés ). Los clientes DNS pueden utilizar esta firma con la clave pública (Engl. Public key ) que el propietario valida y verifica la autenticidad e integridad. DNSSEC requiere la extensión DNS extendida , que se puede utilizar para transferir parámetros adicionales en mensajes DNS. EDNS también elimina el límite de tamaño de 512 bytes para los mensajes DNS sobre UDP . Se requieren mensajes DNS significativamente más largos para transmitir claves y firmas.

La versión original de DNSSEC, definida en RFC 2535 en marzo de 1999 , resultó ser inadecuada en la práctica porque la administración de claves era demasiado compleja. La difusión de DNSSEC se retrasó varios años hasta que se publicó una nueva versión completa en 2005. Para descartar incompatibilidades con el software existente, se han introducido nuevos tipos de registros de recursos ( RRSIG reemplaza a SIG , DNSKEY reemplaza a KEY , NSEC reemplaza a NXT). En octubre de 2005, se firmó digitalmente por primera vez un dominio de nivel superior con el dominio .se sueco . Desde mayo de 2011, DNSSEC también ha estado disponible para dominios .de en principio, después de que la caminata de zona se hizo más difícil por la introducción del Registro de recursos NSEC3 en marzo de 2008.

El 5 de mayo de 2010, se introdujo DNSSEC en los 13 servidores raíz ; el 15 de julio se publicó la clave de la zona raíz y, por lo tanto, se puede validar el DNS desde la zona raíz. El 90% de los dominios de nivel superior ahora están firmados con DNSSEC y marcados como firmados en la zona raíz. Algunos todavía están probando DNSSEC sin una entrada en la zona raíz. La propagación de DNSSEC a nivel de dominio es ahora del 50% o más para algunos TLD. En promedio, alrededor del 10% de los dominios se validan.

funcionalidad

La información se proporciona en los registros de recursos (RR) en DNS . DNSSEC asegura la autenticidad de esta información mediante una firma digital . El propietario de la información de DNS es el servidor maestro que tiene autoridad para la zona en la que se encuentra la información. Es una zona separada para cada zona cubierta se generan claves (engl.: Clave de firma de zona ) (un par que consta de la clave pública y privada). La parte pública de la clave de zona se incluye en el archivo de zona como un registro de recursos DNSKEY . Cada RR individual en esta zona está firmado digitalmente con la clave privada. Se proporciona un nuevo tipo de RR para este propósito, el Registro de recursos RRSIG , que contiene la firma de la entrada DNS asociada. Ejemplo de un registro A firmado: 

nsf.example.org. A       172.27.182.17
                     RRSIG   A 1 3 1000 20060616062444 (
                                        20060517062444 9927 example.org.
                                        mMBIXxXU6buN53GWHTPpwEbse4aR2gNI8rgs
                                        g9/x1We23K3gkO5DBjFdty27Fj4FMbQzg0uB
                                        uv9aFcPaMyILJg== )

Además del registro de recursos real , el RRSIG-RR asociado también se proporciona con cada transacción . Los esclavos lo reciben durante la transferencia de zona , se almacena en el caché con resolución recursiva. Finalmente, termina con el resolutor solicitante. Esto luego puede validar la firma usando la clave de zona pública.

Un registro de recursos (más precisamente: un conjunto de registros de recursos, es decir, un conjunto de RR del mismo tipo y nombre) también se puede firmar varias veces (con claves diferentes). Esto tiene sentido si la validez de una clave está a punto de expirar y desea publicar un sucesor en una etapa temprana. Las llaves se identifican con un número, la etiqueta de la llave . En DNSSEC, una firma digital también contiene la fecha a partir de la cual es válida y una fecha de finalización a partir de la cual deja de ser válida. También se especifica el algoritmo utilizado.

Gestión de claves

Para facilitar Keymanagement era además de la clave para la firma de la (zona de la tecla de zona de firma , ZSK) un sintácticamente idéntica Armadura Key (engl:. Clave de firma clave , KSK) se definen. El bit 7 se establece en el campo de banderas del registro DNSKEY si la clave que contiene se utiliza para firmar conjuntos de registros de recursos en la zona. Esto se aplica a las KSK y ZSK: los registros DNSKEY se firman con las KSK y todos los demás registros se firman con las ZSK. El bit 15 (Punto de entrada seguro) se establece si la clave es el punto de partida para validar la zona; esto se aplica a las KSK. Dado que todavía no se han utilizado otros bits, el campo de banderas tiene el valor 256 para las ZSK y 257 para las KSK.

Solo los registros DNSKEY que contienen las claves de zona reales están firmados con esta KSK. Dicha clave de Firma Clave es para la formación de cadenas de confianza (ger .: cadenas de confianza utilizadas). Un valor hash de la KSK se almacena en un registro DNS en la zona de nivel superior, lo que garantiza la autenticidad de las claves de zona en el registro DNSKEY firmado. A diferencia de la clave de zona que se renueva con frecuencia, una KSK tiene una larga vida útil.

Evaluación por resolutor

Los resolutores de DNS en dispositivos finales como estaciones de trabajo o teléfonos inteligentes ( llamados resolutores de stub en terminología DNS ) generalmente no pueden validar registros DNS firmados digitalmente. De acuerdo con la filosofía de DNS actualmente dominante, los solucionadores de stub son programas estructurados de manera muy simple que se basan en un servidor de nombres recursivo para una resolución de nombres completa . Un solucionador de stub que quiere resolver un nombre envía una solicitud correspondiente a un servidor de nombres en la red local o en la red del proveedor de servicios de Internet . Al establecer el bit DO ( DNSSEC OK ) en el encabezado DNS, el resolutor puede informar al servidor de nombres que se debe realizar la validación. Para hacer esto, el solucionador de stub debe admitir la extensión DNS extendida , ya que allí se especificó el bit DO. Sin embargo, el servidor de nombres recursivo también se puede configurar para que siempre lleve a cabo la validación, independientemente de la presencia o el contenido del bit DO. Si la autenticación es exitosa, el servidor establece el bit AD ( datos autenticados ) en la respuesta . Si la autenticación falla, el servidor devuelve un error general. El solucionador de stub no puede decir si el error fue provocado por una validación fallida o por otra causa, por ejemplo, falla de la red o falla del servidor de nombres del nombre de dominio solicitado.

Nombres inexistentes

También puede utilizar DNSSEC para demostrar que un nombre determinado no existe. Para este propósito, cuando se firma un archivo de zona, todas las entradas se ordenan alfabéticamente y se vinculan a través de un registro de recursos NSEC . El apellido apunta al primero, de modo que se crea una cadena en forma de anillo. Ejemplo: nombre1 → nombre2, nombre2 → nombre5, nombre5 → nombre1. Para cada nombre hay exactamente un registro NSEC, que también está firmado. Si, por ejemplo, un resolutor solicita ahora el nombre inexistente3 , el servidor de nombres entrega una respuesta negativa y también el registro NSEC nombre2 → nombre5 . Desde la firma del presente NSEC, la resolución puede estar seguro de que no hay ninguna otra entrada entre nombre2 y NAME5 y que nombre3 no existe. Ejemplo: 

   name2       A       172.27.182.17
               RRSIG   A 1 3    1000 20060616062444 (
                                20060517062444 9927 example.org.
                                mMBIXxXU6buN53GWHTPpwEbse4aR2gNI8rgs
                                g9/x1We23K3gkO5DBjFdty27Fj4FMbQzg0uB
                                uv9aFcPaMyILJg== )
               NSEC    name5  A RRSIG NSEC
               RRSIG   NSEC 1 3 10000 20060616062444 (
                                20060517062444 9927 example.org.
                                vlDpyqQF8b6VEtRRt5dZd+R2IVonLaJvpr6n
                                5flYJ90JYtaiwhPIQGsp44BH0pvcBCt9e/eD
                                QoBh4eGjbW49Yw== )

El encadenamiento de todos los registros de una zona permite leer todo el contenido de forma iterativa caminando por la zona . Esto puede revelar información confidencial o relevante para la seguridad a un atacante, como una lista de todos los dominios de los clientes. En marzo de 2008, la entrada NSEC3 se definió con RFC5155 , que en lugar de nombres de dominio de texto sin formato devuelve los valores hash de los nombres de dominio y, por lo tanto, dificulta la caminata por zonas. Un atacante tendría que llevar a cabo un ataque de diccionario computacionalmente intensivo para obtener los nombres de dominio a partir de los valores hash. Para hacer esto aún más difícil, se planea una aplicación repetida de la función hash, así como el uso de sal . BIND es compatible con NSEC3 desde la versión 9.6 y NSD desde la versión 3.1.

Cadena de confianza

Para garantizar una autenticación segura, la clave pública de una zona (o su hash ) debe ingresarse manualmente en el servidor central que debe resolver el nombre. Dado que cada zona normalmente tiene una clave diferente, que también cambia con regularidad, la administración de claves puede ser muy compleja.

La formación de cadenas de confianza (ger.: Chains of Trust ) facilita la gestión de claves de forma espectacular. Una zona ubicada lo más alto posible en el árbol de DNS contiene las claves públicas de sus subzonas delegadas y las firma digitalmente. Las subzonas pueden, a su vez, contener las claves públicas firmadas de sus zonas subordinadas, etc. Para tal cadena de confianza, sólo la clave pública de la zona superior necesita ser conocida en el resolutor de un servidor de nombres central. El monto total de las zonas protegidas por un solo conjunto clave de zonas como isla de seguridad (ger .: Islandia de seguridad llamada). Idealmente, solo hay una isla de seguridad para todo el espacio de nombres y, por lo tanto, solo una clave confiable . Los registros de recursos de DS se utilizan para crear cadenas de confianza . Un hash de una clave definida en el registro de recursos de DS corresponde a la clave del firmante de la clave de la zona subordinada.

La formación de cadenas de confianza simplifica considerablemente la gestión de claves, pero en el peor de los casos los resolutores tienen que recorrer la cadena desde la zona inferior a la superior y realizar una gran cantidad de operaciones criptográficas. Ejemplo:

Hay dos zonas: la zona principal example.org. y la subzona delegada filiale1.example.org. . Ambas zonas están conectadas a una cadena de confianza a través de un registro DS, de modo que solo la clave de la zona superior example.org. debe conocerse como una clave de confianza.

La zona principal example.org. tiene la clave de firma de clave: 

  example.org. IN DNSKEY 257 3 1 AQOW4333ZLdOHLRk+3Xe...           (gekürzt)

y la tecla de zona 

  example.org. IN DNSKEY 256 3 1 AQO+/cFBgAR4HbTlBSoP...           (gekürzt)

En example.org hay un punto de delegación a la subzona filiale1.example.org. con la clave de zona de example.org. está firmado: 

 filiale1   DS      52037 1 1 ( 378929E92D7DA04267EE87E802D75C5CA1B5D280 )
            RRSIG   DS 1 3 1000 20060615115919 (
                                20060516115919 9927 example.org.
                                AnMxvfH64hbf3OsPzTXz4B7w3vZ9ZCto/ugw
                                AeKpbd0uijPe8Q== )                     (gekürzt)

El registro DS contiene un hash de la clave de firma de la zona subordinada filiale1.example.org. .

La zona secundaria filiale1.example.org. tiene la clave de firma de clave: 

 filiale1.example.org. DNSKEY 257 3 1 AQOtPCW58VdBIOnKJaOzd...   (gekürzt)

En los resolutores, la clave de firma de claves de la zona de nivel superior example.org. ingresado manualmente como clave de confianza : 

 trusted-keys { "example.org." 257 3 1 "AQOW4333ZLdOH+..."; };  (gekürzt)

Un ejemplo concreto en el TLD .de

Los servidores de nombres raíz han admitido DNSSEC desde 2010. Se han implementado las siguientes medidas para proteger un dominio .de con una cadena de confianza:

  • Los servidores raíz entregan un registro DS para la zona de. Contiene un hash de la clave de firma de clave alemana :

Delaware. IN DS 24220 8 2 FFE926ACA67ED94089390250F1F294AC84A6D84F9121DF73A79E439F 42E820C2 . El registro DS está firmado con la clave de zona de la zona raíz.

  • La clave de firma de claves (reconocible por el número 257) de la zona alemana (cuyo hash está en el registro DS en los servidores raíz) es

Delaware. IN DNSKEY 257 3 8 AwEAAYbcKo2IA8l6arSIiSC + l97v2vgNXrxjBJ ... (abreviado)

  • Con esta clave de firma de clave , se firma el registro DNSKEY de la zona alemana (vía RRSIG), que contiene la clave de zona (reconocible por el número 256). Un solucionador ahora sabe que la clave de zona alemana es genuina, ya que está protegida con una clave que los servidores raíz confirman como genuina.

Delaware. IN DNSKEY 256 3 8 AwEAAZ4e4Nf1SpBWMhSK6ha + YeJyq ... (abreviado)

  • Para proteger un dominio alemán a través de DNSSEC, se crea un registro DS con el hash de la clave de firma del dominio en la zona de. Además del registro de delegación habitual (NS) . Ahora, un resolutor puede reconocer la autenticidad de la clave de zona del dominio, ya que el registro DNSKEY que contiene la clave de zona fue firmado por una clave (¡RRSIG!) Cuyo hash está en manos de DENIC .

Límites de DNSSEC

Solo las consultas del servidor de nombres están protegidas por DNSSEC. Esto es principalmente útil en conexión con protocolos de transmisión de cifrado como TLS . Sin embargo, la combinación de DNSSEC con TLS todavía tiene puntos débiles. El enrutamiento corrupto podría, por ejemplo, entregar paquetes que se envían a una dirección IP de destino determinada correctamente con DNSSEC a la computadora incorrecta. Si esta computadora puede identificarse a través de un certificado comprometido o emitido accidentalmente, esto no se notará. Aquí es donde entra DANE , por ejemplo , para asegurar la interacción entre DNSSEC y TLS.

Vulnerabilidades relevantes para la seguridad de DNSSEC

  • DNSSEC no previene los ataques de denegación de servicio en los servidores de nombres, pero en realidad se facilitan debido a la mayor carga en los servidores.
  • Los ataques de amplificación de DNS que utilizan la infraestructura pública de DNS se vuelven más eficaces, ya que las respuestas de DNS con DNSSEC son significativamente más largas.
  • Las claves públicas para verificación también se distribuyen a través del sistema DNS. Esto crea oportunidades para atacar las cadenas de la confianza. Esto se puede evitar si la clave pública del origen de la confianza (Trust Anchor) se distribuye de una forma distinta a la infraestructura DNS (por ejemplo, con el sistema operativo o el servidor o software cliente).
  • Con DNSSEC Walking, el contenido de las zonas se puede leer completamente (lo que dificulta más NSEC3 ).
  • Dado que los solucionadores de stub a menudo no validan las respuestas de DNS por sí mismos, se puede producir un ataque en la ruta de comunicación a su servidor de nombres recursivo. El propio servidor de nombres recursivo también puede verse comprometido.

Gestión de la clave de la zona raíz

Por el momento, la clave DNSSEC para la zona raíz solo se administra en dos ubicaciones de EE. UU. Según muchos expertos de RIPE , una ubicación fuera de los EE. UU. Es esencial. Los críticos acusan a la ICANN de poner en peligro la independencia de Internet a través de la administración de claves DNSSEC en los EE. UU. ICANN había previsto a la empresa estadounidense Verisign como el único socio firmante. En 2007, el estadounidense Departamento de Seguridad Nacional solicitó que la gestión de claves estar completamente en manos del gobierno de Estados Unidos. También se discutió si el subgrupo de la Autoridad de Números Asignados de Internet (IANA) de la ICANN debería tener la tarea de administrar la clave raíz. El gobierno de los Estados Unidos prohibió inicialmente la publicación de una propuesta de ICANN correspondiente. La ICANN es formalmente independiente, pero el gobierno de EE. UU. Mantuvo la supervisión hasta septiembre de 2016.

Ver también

literatura

  • Christoph Sorge, Nils Gruschka, Luigi Lo Iacono: Seguridad en las redes de comunicación. Oldenbourg Wissenschaftsverlag, Múnich 2013, ISBN 978-3-486-72016-7 .

Normas y estándares

enlaces web

Evidencia individual

  1. ↑ DNSSEC: www.denic.de. En: DENIC . 12 de mayo de 2014, consultado el 12 de mayo de 2014 .
  2. ↑ DNSSEC se inició en la zona raíz . Heise noticias
  3. ^ Informe TLD DNSSEC. En: ICANN . 21 de noviembre de 2017, consultado el 21 de noviembre de 2017 .
  4. ↑ Estadísticas y datos de .nl: información sobre el uso de .nl. En: SIDN . 21 de noviembre de 2017, consultado el 21 de noviembre de 2017 .
  5. ↑ Tablero - CZ. Estadísticas. En: CZ.NIC . 21 de noviembre de 2017, consultado el 21 de noviembre de 2017 .
  6. ↑ Eurid en 2016 - Informe anual 2016. En: EURid . 3 de abril de 2017, consultado el 21 de noviembre de 2017 .
  7. ↑ Métricas de capacidad de validación de DNSSEC: uso de la validación de DNSSEC para el mundo (XA). En: APNIC . 21 de noviembre de 2017, consultado el 21 de noviembre de 2017 .
  8. ↑ Números de algoritmo de seguridad de DNS
  9. ↑ DNSSEC en todos los servidores raíz . Heise News, 6 de mayo de 2010
  10. ↑ Cuestión de poder: ¿Quién controla Internet? En: c't , 5/2010
  11. ^ IGF: Problemas políticos y técnicos con DNSSEC . Heise News, 14 de noviembre de 2007
  12. ↑ El Departamento de Seguridad Nacional quiere la clave maestra para el DNS . Heise News, 29 de marzo de 2007
  13. ↑ VeriSign quiere compartir claves DNSSEC (un poco) . Heise News, 3 de octubre de 2008
  14. ↑ Monika Ermert: Se corta el último vínculo formal con el control histórico de Internet de EE. UU. En: Vigilancia de la propiedad intelectual. 1 de octubre de 2016, consultado el 28 de noviembre de 2016 .