Complejidades y consideraciones del protocolo DNSSEC

DNS is split into smaller pieces called zones. A zone typically starts at a domain name, and contains all records pertaining to the subdomains. Each zone is managed by a single manager. For example, cloudflare.com is a zone containing all DNS records for cloudflare.com and its subdomains (e.g. www.cloudflare.com, api.cloudflare.com).

There is no directory service for subdomains in DNS so if you want to know if api.cloudflare.com exists, you have to ask a DNS server and that DNS server will end up asking cloudflare.com whether api.cloudflare.com exists. This is not true with DNSSEC. In some cases, enabling DNSSEC may expose otherwise obscured zone content. Not everyone cares about the secrecy of subdomains, and zone content may already be easily guessable because most sites have a ‘www’ subdomain; however, subdomains are sometimes used as login portals or other services that the site owner wants to keep private. A site owner may not want to reveal that “secretbackdoor.example.com” exists in order to protect that site from attackers.

The reason DNSSEC can expose subdomains has to do with how zones are signed. Historically, DNSSEC is used to sign static zones. A static zone is a complete set of records for a given domain. The DNSSEC signature records are created using the Key Signing Key (KSK) and Zone Signing Key (ZSK) in a central location and sent to the authoritative server to be published. This set of records allows an authoritative server to answer any question it is asked, including questions about subdomains that don’t exist.

Unlike standard DNS, where the server returns an unsigned NXDOMAIN (Non-Existent Domain) response when a subdomain does not exist, DNSSEC guarantees that every answer is signed. This is done with a special record that serves as a proof of non-existence called the NextSECure (NSEC) record. An NSEC record can be used to say: “there are no subdomains between subdomains X and subdomain Y.” By filling the gap between every domain in the zone, NSEC provides a way to answer any query with a static record. The NSEC record also lists what Resource Record types exist at each name.

For statically signed zones, there are, by definition, a fixed number of records. Since each NSEC record points to the next, this results in a finite ‘ring’ of NSEC records that covers all the subdomains. Anyone can ‘walk’ a zone by following one NSEC record to the next until they know all subdomains. This method can be used to reveal all of the names in that zone---possibly exposing internal information.

Suppose there is a DNSSEC-enabled zone called example.com, with subdomains public.example.com and secret.example.com. Adding NSEC records will reveal the existence of all subdomains.

Asking for the NSEC record of example.com gives the following:

example.com. NSEC public.example.com. A NS SOA TXT AAAA RRSIG NSEC DNSKEY

Asking for public.example.com gives the following NSEC record:

public.example.com. NSEC secret.example.com. A TXT AAAA RRSIG NSEC

Asking for secret.example.com gives the following NSEC record:

secret.example.com. NSEC example.com. A TXT AAAA RRSIG NSEC

The first one is for the zone top/apex, and says that the name “example.com” exists and the next name is “public.example.com”. The public.example.com record says that the next name is “secret.example.com” revealing the existence of a private subdomain. The “secret.example.com” says the next record is “example.com” completing the chain of subdomains. Therefore, with a few queries anybody can know the complete set of records in the zone.

Technically, DNS records are not supposed to be secret, but in practice they are sometimes considered so. Subdomains have been used to keep things (such as a corporate login page) private for a while, and suddenly revealing the contents of the zone file may be unexpected and unappreciated.

Before DNSSEC the only way to discover the contents of names in a zone was to either query for them, or attempt to perform a transfer of the zone from one of the authoritative servers. Zone Transfers (AXFR) are frequently blocked. NSEC’s alternatative, NSEC3, was introduced to fight zone enumeration concerns, but even NSEC3 can be used to reveal the existence of subdomains.

Most domains under .ch use NSEC3

The NSEC3 record is like an NSEC record, but, rather than a signed gap of domain names for which there are no answers to the question, NSEC3 provides a signed gap of hashes of domain names. This was intended to prevent zone enumeration. Thus, the NSEC3 chain for a zone containing “example.com” and “www.example.com” could be (each NSEC3 record is on 3 lines for clarity):

231SPNAMH63428R68U7BV359PFPJI2FC.example.com. NSEC3 1 0 3 ABCDEF
NKDO8UKT2STOL6EJRD1EKVD1BQ2688DM
A NS SOA TXT AAAA RRSIG DNSKEY NSEC3PARAM

NKDO8UKT2STOL6EJRD1EKVD1BQ2688DM.example.com. NSEC3 1 0 3 ABCDEF
231SPNAMH63428R68U7BV359PFPJI2FC
A TXT AAAA RRSIG

Where

231SPNAMH63428R68U7BV359PFPJI2FC

example.com

NKDO8UKT2STOL6EJRD1EKVD1BQ2688DM

www.example.com

The first line of the NSEC3 record contains the “name” of the zone after it has been hashed, the number of hash rounds and salt used in the hashing are the two last parameters on the first line “3 ABCDEF”. The “1 0” stands for digest algorithm (1 means SHA-1) and if the zone uses Opt-out (0 means no). The second line is the “next hashed name in the zone”, the third line lists the types at the name. You can see the “next name” at the first NSEC3 record matches the name on the second NSEC3 record and the “next name” on that one completes the chain.

For NSEC enumeration, you can create the full list of domains by starting to guess at possible names in the domain. If the zone has around 100 domain names, it will take around 100 requests to enumerate the entire zone. With NSEC3, when you request a record that does not exist, a signed NSEC3 record is returned with the next zone present ordered alphabetically by hash. Checking if the next query name candidate fits in one of the known gaps allows anyone to discover the full chain in around 100 queries. There are many tools that can do this computation for you, including a plug-in to nmap

With the hashes that correspond to all the valid names in the zone, a dictionary attack can be used to figure out the real names. Short names are easily guessed, and by using a dictionary, longer names can be revealed as existing without having to flood the authoritative nameservers with guesses. Tools like HashCat make this easy to do in software, and the popularity of bitcoin has dramatically lowered the price of hashing-specific hardware. There is a burgeoning cottage industry of devices built to compute cryptographic hashes. The Tesla Password cracker (below) is just one example of these off-the shelf devices.

The Teslsa Cracker

Because hashing is cheap, zone privacy is only slightly improved when using NSEC3 as designed; the amount of protection a name gets is proportional to its unguessability.

In short, NSEC is like revealing plaintext passwords, and NSEC3 is like revealing a Unix-style passwords file. Neither technique is very secure. With NSEC3 a subdomain is only as private as it is hard to guess.

This vulnerability can be mitigated by a techniques introduced in RFCs 4470 and 4471 (https://tools.ietf.org/html/rfc4470 and https://tools.ietf.org/html/rfc4471) called “DNSSEC white lies”; this was implemented by Dan Kaminsky for demonstration purposes. When a request comes in for a domain that is not present, instead of providing an NSEC3 record of the next real domain, an NSEC3 record of the next hash alphabetically is presented. This does not break the NSEC3 guarantee that there are no domains whose hash fits lexicographically between the NSEC3 response and the question.

You can only implement NSEC3 or NSEC “white lies” if signatures can be computed in real-time in response to questions. Traditionally, static zone records for DNS resolution are created offline, and all the records with signatures stored in a zone file. This file is then read by a live DNS server allowing it to answer questions about the zone.

Cloudflare’s DNSSEC implementation leverages ECDSA’s efficient signature generation to sign DNSSEC records on-the-fly.

El DNSSEC se diseñó para funcionar en varios modos, cada uno de los cuales ofrece diferentes desventajas de seguridad, rendimiento y facilidad. La firma en directo resuelve el problema de la exposición del contenido de la zona a cambio de una gestión de claves menos segura.

El modo más común de DNSSEC es la firma sin conexión de zonas estáticas. Esto permite que el sistema de firma esté muy protegido de las amenazas externas al mantener las claves privadas en un equipo que no está conectado a la red. Este modelo operativo funciona bien cuando la información del DNS no cambia con frecuencia.

Otro modo de funcionamiento habitual es la firma en línea centralizada. La firma de datos en sistemas de firma DNS de acceso restringido permite que los datos DNS cambien y se publiquen rápidamente. Algunos operadores ejecutan la firma DNS en sus servidores DNS principales. Al igual que la firma fuera de línea de zonas estáticas, este modo sigue el modelo de firma central, es decir, un único firmante central (o replicado) realiza toda la firma y los datos se propagan desde este a los servidores DNS autoritativos reales.

Un modo más radical es permitir que los propios servidores DNS autoritativos firmen los datos sobre la marcha cuando sea necesario, lo que permite una serie de nuevas funciones, como la información dependiente de la geografía que se firma en el lugar donde se genera la respuesta. El inconveniente es que ahora el material para claves está en muchos equipos diferentes que tienen acceso directo a Internet. El proceso de firma en directo en el perímetro plantea nuevos problemas, como la distribución de la clave, y supone requisitos informáticos adicionales para los nodos.

Recientemente, se encontró un error conocido como Heartbleed que abrió una importante vulnerabilidad de seguridad en las aplicaciones de los servidores. Su origen fue error de codificación en OpenSSL que creó una vulnerabilidad de divulgación de memoria remota. Este fallo permitía a los atacantes remotos extraer claves criptográficas de los servidores accesibles desde Internet. Los fallos de exposición a la memoria remota son solo una de las muchas amenazas a la seguridad de la clave privada cuando esta se utiliza en un proceso activo como la firma en directo de DNSSEC. Cuanto más expuesto esté un equipo a Internet, más vectores de ataque habrá. Las máquinas de firma fuera de línea tienen una ventana de exposición mucho menor a tales amenazas.

Una forma de mantener las claves seguras es utilizar una solución basada en hardware, como un módulo de seguridad de hardware (HSM). El mayor inconveniente es el coste. Los HSM son muy caros (y lentos). Este es uno de los puntos más conflictivos para la gestión de los servidores DNS que están repartidos geográficamente para estar cerca de sus clientes. Instalar un HSM en cada ubicación del servidor no solo puede ser caro, sino que también puede haber complicaciones desde el punto de vista legal.

Otra solución para proteger las claves del riesgo de revelación remota es descargar las operaciones criptográficas en un componente de confianza del sistema. Aquí es donde resulta útil tener un servidor DNS personalizado que pueda descargar la criptografía.

La gestión de claves para DNSSEC es similar a la gestión de claves para el protocolo TLS y tiene retos similares. A principios de este año, presentamos SSL sin clave para ayudar a mejorar la seguridad de las claves para el protocolo TLS. Estamos estudiando la posibilidad de ampliar SSL sin clave para que ofrezca las ventajas de los servidores de claves remotos para la firma en directo de DNSSEC.

A los operadores que gestionan un servidor DNS autoritativo les suele inquietar que su servidor se utilice como vía para ataques maliciosos de denegación de servicio distribuido (DDoS). Esto se debe a que el DNS utiliza UDP, un protocolo sin estado.

En el protocolo TCP, cada conexión comienza con un protocolo de enlace de tres vías. Esto garantiza que la dirección IP de ambas partes es conocida y correcta antes de iniciar una conexión. En un protocolo UDP, no existe ese protocolo de enlace. Los mensajes se envían directamente a una dirección IP con una dirección IP "de" no verificada. Si un ciberdelincuente puede crear un paquete UDP que diga "hola, desde la IP X" a un servidor, este suele responder enviando un paquete UDP a X. Elegir X como dirección IP de la víctima en lugar de la del remitente se denomina "suplantación" de UDP. Al suplantar a una víctima, un ciberdelincuente puede hacer que un servidor que responda a solicitudes UDP inunde a la víctima con tráfico "reflejado". Esto se aplica tanto a los servidores autoritativos como a los solucionadores recursivos abiertos.

DNSSEC también funciona a través del protocolo UDP, y las respuestas a las consultas DNS pueden ser muy largas, e incluir varios registros DNSKEY y RRSIG. Es un objetivo atractivo para los ciberdelincuentes, ya que les permite "amplificar" sus ataques de reflexión. Si se envía un pequeño volumen de solicitudes DNSSEC UDP falsas a los servidores de nombres, la víctima recibirá un gran volumen de tráfico reflejado. A veces esto es suficiente para sobrecargar el servidor de la víctima y provocar una denegación de servicio.

Preguntar por un protocolo TLD que no existe a un servidor raíz devuelve una respuesta de unos 100 bytes, la respuesta firmada para la misma pregunta es de unos 650 bytes o un factor de amplificación de 6,5. La raíz está firmada con una clave RSA de 1 024 bits y utiliza NSEC para las respuestas negativas. Solicitar un dominio que no existe en un protocolo TLD utilizando NSEC3 firmado con una clave de 1 024 bits dará un factor de amplificación de alrededor de 10. Hay otras consultas que pueden generar factores de amplificación aún mayores, siendo la más eficaz la consulta de tipo "ANY".

Como muchos servicios, el DNS también puede funcionar a través de TCP. Hay una marca de "truncamiento" que se puede enviar a un solucionador para indicar que se necesita el protocolo TCP. Esto solucionaría el problema de la reflexión del DNS a costa de que las solicitudes de DNS sean más lentas. Esta solución no es práctica por el momento, ya que el 16 % de los solucionadores no respetan la marca de truncamiento TCP, y el 4 % no intentan un segundo servidor.

Otra opción para reducir el tamaño de las respuestas es utilizar claves de algoritmo de firma digital de curva elíptica (ECDSA) en lugar de las tradicionales RSA. Las claves ECDSA son mucho más cortas que las claves RSA de seguridad equivalente, y producen firmas más reducidas haciendo que las respuestas DNSSEC sean mucho más breves, reduciendo así el factor de amplificación. El DNS público de Google añadió la compatibilidad para ECDSA a finales de 2014, y otros han seguido su ejemplo desde entonces.

La compatibilidad con TCP y ECDSA sigue estando por detrás de la compatibilidad general con DNSSEC, por lo que se pueden utilizar en su lugar los métodos tradicionales contra el abuso. Esto incluye limitación de velocidad de respuesta (RRL) y otras heurísticas.

Para ofrecer protección contra los ataques de reflexión, Cloudflare está trabajando en un enfoque multidimensional. En primer lugar, utilizando la heurística de identificación de ataques y las técnicas contra abuso que actualmente utilizamos en nuestro servidor DNS, y en segundo lugar, reduciendo el factor de amplificación de las respuestas DNSSEC. Entre las formas de reducir el factor de amplificación máximo se incluyen la respuesta solo a las solicitudes del tipo "ANY" a través del protocolo TCP, el uso de claves ECDSA más cortas cuando sea posible y la reducción de la frecuencia de las renovaciones de claves.

Cloudflare es consciente de la complejidad que plantea el DNSSEC con respecto a la privacidad de la zona, la gestión de claves y el riesgo de ataques de reflexión/amplificación. Con decisiones inteligentes de ingeniería y controles operativos, se pueden prevenir los peligros del protocolo DNSSEC.