Komplexe DNSSEC-Faktoren und Überlegungen

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.

DNSSEC wurde für den Betrieb in verschiedenen Modi konzipiert, die jeweils unterschiedliche Kompromisse in Bezug auf Sicherheit, Performance und Komfort bieten. Die Live-Signierung löst das Problem der Offenlegung von Zoneninhalten im Austausch für eine weniger sichere Schlüsselverwaltung.

Der häufigste DNSSEC-Modus ist die Offline-Signierung statischer Zonen. Auf diese Weise kann das Signiersystem in hohem Maße vor externen Bedrohungen geschützt werden, da sich die privaten Schlüssel auf einem Rechner befinden, der nicht mit dem Netz verbunden ist. Dieses Betriebsmodell funktioniert gut, wenn sich die DNS-Informationen nicht oft ändern.

Eine weitere gängige Betriebsart ist die zentralisierte Online-Signatur. Wenn Sie Daten in speziellen DNS-Signatursystemen mit beschränktem Zugang signieren, können DNS-Daten schnell geändert und veröffentlicht werden. Einige Betreiber führen die DNS-Signierung auf ihren Haupt-DNS-Servern durch. Genau wie bei der Offline-Signierung statischer Zonen folgt dieser Modus dem Modell der zentralen Signierung, d. h. ein einziger (oder replizierter) zentraler Unterzeichner (Signer) führt die gesamte Signierung durch, und die Daten werden von ihm an die tatsächlichen autoritativen DNS-Server verteilt.

Ein radikalerer Modus besteht darin, den eigentlichen autoritativen DNS-Servern die Möglichkeit zu geben, Daten bei Bedarf zu signieren, was eine Reihe neuer Funktionen ermöglicht, einschließlich geografisch abhängiger Informationen, die dort signiert werden, wo die Antwort generiert wird. Der Nachteil ist, dass sich das Schlüsselmaterial jetzt auf vielen verschiedenen Rechnern befindet, die direkten Zugang zum Internet haben. Die Live-Signierung an der Edge führt zu neuen Problemen wie der Schlüsselverteilung und stellt zusätzliche Rechenanforderungen an die Knoten.

Vor kurzem wurde ein Fehler gefunden, der als Heartbleed bekannt ist und eine große Sicherheitslücke in Serveranwendungen öffnet. Er wurde durch einen Programmierfehler in OpenSSL verursacht, der eine Sicherheitslücke für die Offenlegung von Remote-Speicherplatz geschaffen hat. Dieser Fehler ermöglichte Angreifern aus der Ferne die Extraktion von kryptographischen Schlüsseln von Servern, die mit dem Internet verbunden sind. Bugs hinsichtlich der Offenlegung von Remote-Speicherplatz sind nur eine der vielen Bedrohungen für die Sicherheit privater Schlüssel, wenn der Schlüssel in einem aktiven Prozess wie der DNSSEC-Live-Signierung verwendet wird. Je mehr ein Rechner dem Internet ausgesetzt ist, desto mehr Angriffsmöglichkeiten gibt es. Offline signierende Rechner sind solchen Bedrohungen in einem viel kleineren Zeitfenster ausgesetzt.

Eine Möglichkeit, Schlüssel sicher zu halten, ist die Verwendung einer hardwaregestützten Lösung wie einem Hardware-Sicherheitsmodul (HSM). Der größte Nachteil dabei sind die Kosten – HSMs sind sehr teuer (und langsam). Dies ist eines der größten Probleme beim Betrieb von DNS-Servern, die geografisch verstreut sind, um in der Nähe ihrer Kunden zu sein. Der Betrieb eines HSM an jedem Serverstandort kann nicht nur teuer sein, sondern auch zu rechtlichen Komplikationen führen.

Eine weitere Lösung, mit der man verhindert, dass Schlüssel aus der Ferne offengelegt werden können, besteht darin, kryptografische Vorgänge in vertrauenswürdige Komponenten des Systems auszulagern. Hier kann ein benutzerdefinierter DNS-Server, der die Kryptographie auslagern kann, sehr hilfreich sein.

Die Schlüsselverwaltung für DNSSEC ähnelt der Schlüsselverwaltung für TLS und bringt ähnliche Probleme mit sich. Anfang des Jahres haben wir Keyless SSL eingeführt, um die Schlüsselsicherheit für TLS zu verbessern. Wir prüfen die Möglichkeit, Keyless SSL zu erweitern, um die Vorteile von entfernten Schlüsselservern für die DNSSEC-Live-Signierung zu nutzen.

Betreiber, die einen autoritativen DNS-Server betreiben, befürchten oft, dass ihr Server als Kanal für böswillige Distributed-Denial-of-Service-Angriffe (DDoS) genutzt wird. Dies ist darauf zurückzuführen, dass DNS UDP, ein zustandsloses Protokoll, verwendet.

Bei TCP beginnt jede Verbindung mit einem dreifachen Handshake. Dadurch wird sichergestellt, dass die IP-Adresse beider Parteien bekannt und korrekt ist, bevor eine Verbindung hergestellt wird. Bei UDP gibt es keinen solchen Handshake: Die Nachrichten werden einfach direkt an eine IP-Adresse mit einer nicht verifizierten „from“-IP-Adresse gesendet. Wenn ein Angreifer ein UDP-Paket mit den Worten „Hallo, von IP X“ an einen Server senden kann, antwortet der Server in der Regel mit einem UDP-Paket an X. Die Wahl von X als IP-Adresse des Opfers anstelle der des Absenders wird als UDP-„Spoofing“ bezeichnet. Durch Spoofing eines Opfers kann ein Angreifer einen Server, der auf UDP-Anfragen antwortet, dazu bringen, das Opfer mit „reflektiertem“ Datenverkehr zu überfluten. Dies gilt sowohl für autoritative Server als auch für offene rekursive Resolver.

DNSSEC funktioniert auch über UDP, und die Antworten auf DNS-Anfragen können sehr lang sein und mehrere DNSKEY- und RRSIG-Einträge enthalten. Dies ist ein attraktives Ziel für Angreifer, da sie damit ihre Reflection-Angriffe „verstärken“ können. Wenn eine kleine Menge an gefälschten UDP DNSSEC-Anfragen an Nameserver gesendet wird, erhält das Opfer eine große Menge an reflektiertem Traffic. Manchmal reicht dies aus, um den Server des Opfers zu überlasten und eine Dienstverweigerung (Denial of Service) auszulösen.

Eine von einem Root-Server ausgehende Anfrage nach einer TLD, die nicht existiert, ergibt eine Antwort von etwa 100 Byte. Die signierte Antwort für dieselbe Frage beträgt etwa 650 Byte oder einen Amplification-Faktor von 6,5. Das Stammverzeichnis wird mit einem 1.024-Bit-RSA-Schlüssel signiert und verwendet NSEC für negative Antworten. Eine mit NSEC3 signierte und mit einem 1.024-Bit-Schlüssel signierte Anfrage nach einer Domain, die nicht in einer TLD existiert, ergibt einen Amplification-Faktor von etwa 10. Es gibt andere Abfragen, die noch höhere Amplification-Faktoren ergeben können, wobei die Abfrage „ANY“ am effektivsten ist.

Wie viele andere Dienste kann auch DNS über TCP funktionieren. Es gibt ein „Truncation“-Flag, das an einen Resolver zurückgeschickt werden kann, um anzuzeigen, dass TCP erforderlich ist. Dies würde das Problem der DNS-Reflection auf Kosten langsamerer DNS-Anfragen lösen. Diese Lösung ist derzeit nicht praktikabel, da 16 % der Resolver das TCP-„Truncation“-Flag nicht beachten und 4 % keinen zweiten Server versuchen.

Eine weitere Möglichkeit, die Größe der Antworten zu reduzieren, ist die Verwendung von Elliptic Curve Digital Signature Algorithm (ECDSA) Schlüsseln anstelle von herkömmlichen RSA-Schlüsseln. ECDSA-Schlüssel sind viel kleiner als RSA-Schlüssel gleicher Stärke und erzeugen kleinere Signaturen, wodurch DNSSEC-Antworten viel kleiner ausfallen und der Amplification-Faktor reduziert wird. Google Public DNS fügte Ende 2014 Unterstützung für ECDSA hinzu, und mehrere andere Anbieter haben seitdem nachgezogen.

Die Unterstützung für TCP und ECDSA hinkt der allgemeinen Unterstützung von DNSSEC noch hinterher, so dass stattdessen herkömmliche Methoden zum Schutz vor Missbrauch verwendet werden können. Dazu gehören Resource Rate Limiting (RRL) und andere Heuristiken.

Um sich gegen Reflection-Angriffe zu schützen, arbeitet Cloudflare an einem mehrgleisigen Ansatz. Erstens durch die Verwendung von Heuristiken zur Identifizierung von Angriffen und Techniken zur Missbrauchsbekämpfung, die wir derzeit in unserem DNS-Server einsetzen, und zweitens durch die Reduzierung des Amplification-Faktor von DNSSEC-Antworten. Zu den Möglichkeiten, den maximalen Amplification-Faktor zu verringern, gehören die ausschließliche Beantwortung von „ANY“-Anfragen über TCP, die Verwendung kleinerer ECDSA-Schlüssel, wenn dies möglich ist, und die Verringerung der Häufigkeit von Schlüsselwechseln.

Cloudflare ist sich der Komplexität bewusst, die DNSSEC in Bezug auf Datenschutz von Zonen, Schlüsselverwaltung und Reflection/Amplification-Risiko mit sich bringt. Mit klugen technischen Entscheidungen und betrieblichen Kontrollen können die Gefahren von DNSSEC verhindert werden.