Complexités et considérations relatives au 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.

Le DNSSEC a été conçu pour fonctionner dans différents modes, chacun associé à des compromis différents en matière de sécurité, de performances et de commodité. La signature en direct résout le problème de l'exposition du contenu de la zone en contrepartie d'une gestion des clés moins sûre.

Le mode DNSSEC le plus courant est la signature hors ligne des zones statiques. Le système de signature est ainsi hautement protégé contre les menaces externes en conservant les clés privées sur une machine qui n'est pas connectée au réseau. Ce modèle de fonctionnement fonctionne bien lorsque les informations DNS ne changent pas souvent.

Un autre mode de fonctionnement est couramment appliqué, il s'agit de la signature centralisée en ligne. Si vous signez les données dans des systèmes de signature DNS dédiés à accès restreint, les données DNS peuvent être modifiées et publiées rapidement. Certains opérateurs exécutent la signature DNS sur leurs serveurs DNS principaux. À l'instar de la signature hors ligne des zones statiques, ce mode suit le modèle de signature centrale, c'est-à-dire qu'un signataire central unique (ou répliqué) procède à toutes les signatures et les données sont propagées depuis celui-ci vers les serveurs DNS de référence.

Un mode plus radical consiste à permettre aux serveurs DNS de référence de signer les données à la volée lorsque c'est nécessaire, ce qui permet le recours à un certain nombre de nouvelles fonctionnalités, notamment la signature, à l'endroit même où la réponse est générée, d'informations liées à des variables géographiques. Cette méthode comporte un inconvénient, à savoir que les données de clé se trouvent maintenant sur de nombreuses machines différentes qui ont un accès direct à l'internet. La signature en direct à la périphérie introduit de nouveaux problèmes tels que la répartition des clés et impose des exigences informatiques supplémentaires sur les nœuds.

Récemment, un bogue connu sous le nom de Heartbleed a été découvert et a ouvert une faille de sécurité majeure dans les applications de niveau serveur. Cela venait d'une erreur de codage dans OpenSSL qui créait une vulnérabilité de divulgation de mémoire à distance. Ce bogue permettait à des attaquants à distance d'extraire des clés cryptographiques de serveurs connectés à internet. Les bogues d'exposition de la mémoire distante ne sont qu'une des nombreuses menaces qui pèsent sur la sécurité des clés privées lorsque celles-ci sont utilisées dans un processus actif tel que la signature en direct de DNSSEC. Plus une machine est exposée à internet, plus les vecteurs d'attaque sont nombreux. Les machines de signature hors ligne sont beaucoup moins exposées à de telles menaces.

Il existe plusieurs façons de sécuriser les clés, l'une d'elle consiste à utiliser une solution matérielle telle qu'un module de sécurité matériel (HSM). Le principal inconvénient est le coût ; les HSM sont très chers (et lents). C'est l'un des points les plus délicats lorsqu'il s'agit d'exécuter des serveurs DNS vastement répartis géographiquement afin d'être au plus près de leurs clients. L'installation d'un HSM dans chaque emplacement de serveur peut non seulement être coûteuse, mais aussi s'avérer complexe d'un point de vue juridique.

Une autre solution pour protéger les clés contre la divulgation à distance consiste à transférer les opérations cryptographiques vers des composants de confiance du système. C'est là qu'il peut s'avérer utile de disposer d'un serveur DNS personnalisé vers lequel il est possible de se décharger de la cryptographie.

La gestion des clés pour les DNSSEC est similaire à la gestion des clés pour TLS et présente les mêmes difficultés. Au début de cette année, nous avons présenté la fonctionnalité SSL sans clé, l'objectif était d'améliorer la sécurité des clés pour TLS. Nous envisageons d'étendre le SSL sans clé pour mettre les avantages des serveurs de clés distants au service de la signature en direct des DNSSEC.

Les opérateurs qui gèrent un serveur DNS de référence sont souvent inquiets à l'idée que leur serveur soit utilisé comme un passage pour des attaques malveillantes par déni de service distribué (DDoS). Cela vient du fait que le DNS utilise UDP, un protocole sans état.

Dans le protocole TCP, chaque connexion commence par une négociation en trois temps. Cela permet de vérifier que l'adresse IP des deux parties est connue et correcte avant de lancer une connexion. Dans le protocole UDP, il n'y a pas de négociation :  les messages sont envoyés directement à une adresse IP sans que l'adresse IP d'origine ne soit vérifiée. Si un attaquant peut créer un paquet UDP disant « Bonjour, de l'IP X » à un serveur, le serveur répond généralement en envoyant un paquet UDP à X. Le fait d'indiquer l'adresse IP de la victime comme X au lieu de celle de l'expéditeur est appelé l'« usurpation » UDP. En usurpant l'identité d'une victime, un attaquant peut faire en sorte qu'un serveur, en répondant aux demandes UDP, inonde la victime de trafic « réfléchi ». Cela s'applique aussi bien aux serveurs de référence qu'aux résolveurs récursifs ouverts.

DNSSEC fonctionne également sur UDP, et les réponses aux requêtes DNS peuvent être très longues, contenant plusieurs enregistrements DNSKEY et RRSIG. Il s'agit d'une cible intéressante pour les attaquants, car elle leur permet d'« amplifier » leurs attaques par réflexion. Si un petit volume de requêtes DNSSEC UDP usurpées est envoyé aux serveurs de noms, la victime recevra un grand volume de trafic réfléchi. Cela suffit parfois à submerger le serveur de la victime et à provoquer un déni de service.

Demander un TLD qui n'existe pas à un serveur racine donne lieu à une réponse d'environ 100 octets, la réponse signée pour la même question est d'environ 650 octets, soit un facteur d'amplification de 6,5. La racine est signée à l'aide d'une clé RSA de 1 024 bits et utilise NSEC pour les réponses négatives. En domandant un domaine qui n'existe pas dans un TLD en utilisant NSEC3 signé avec une clé de 1 024 bits vous obtiendrez un facteur d'amplification d'environ 10. Il existe d'autres requêtes qui peuvent donner lieu à des facteurs d'amplification encore plus élevés, la plus efficace étant la requête « ANY ».

À l'instar de nombreux services, le DNS peut également fonctionner sur TCP. Il existe un indicateur « troncature » qui peut être renvoyé à un résolveur pour indiquer que le protocole TCP est nécessaire. Cela permettrait de résoudre le problème de la réflexion DNS au prix d'un ralentissement des requêtes DNS. Cette solution n'est pas commode pour le moment puisque 16 % des résolveurs ne respectent pas l'indicateur de troncature TCP, et 4 % n'essaient pas de deuxième serveur.

Une autre option pour réduire la taille des réponses consiste à utiliser des clés Elliptic Curve Digital Signature Algorithm (ECDSA) au lieu des clés RSA traditionnelles. Les clés ECDSA sont beaucoup plus petites que les clés RSA de force équivalente, et elles produisent des signatures plus petites, ce qui rend les réponses DNSSEC beaucoup plus petites et réduit le facteur d'amplification. Google Public DNS a ajouté la prise en charge de l'algorithme ECDSA fin 2014, et plusieurs autres ont suivi depuis.

La prise en charge de TCP et ECDSA reste à la traîne par rapport à la prise en charge générale de DNSSEC, les méthodes traditionnelles de lutte contre les abus peuvent donc être utilisées à la place. Cela comprend la limitation du débit de réponse et d'autres méthodes heuristiques.

Pour garantir la protection contre les attaques par réflexion, Cloudflare travaille à l'élaboration d'une stratégie pluridimensionnelle. Premièrement, en utilisant les heuristiques d'identification des attaques et les techniques anti-abus que nous utilisons actuellement dans notre serveur DNS, et deuxièmement en réduisant le facteur d'amplification des réponses DNSSEC. Les moyens de réduire le facteur d'amplification maximal consistent à ne répondre qu'aux requêtes « ANY » sur TCP, à utiliser des clés ECDSA plus petites lorsque cela est possible et à réduire la fréquence des renouvellements de clés.

Cloudflare est conscient de la complexité introduite par le protocole DNSSEC en matière de confidentialité de la zone, de gestion des clés et de risque de réflexion/amplification. Il est possible d'écarter les risques liés à DNSSEC avec des décisions techniques judicieuses, et la mise en place de contrôles opérationnels.