How DNSSEC Works

The domain name system (DNS) is the phone book of the Internet: it tells computers where to send and retrieve information. Unfortunately, it also accepts any address given to it, no questions asked.

Email servers use DNS to route their messages, which means they’re vulnerable to security issues in the DNS infrastructure. In September 2014 researchers at CMU found email supposed to be sent through Yahoo!, Hotmail, and Gmail servers routing instead through rogue mail servers. Attackers were exploiting a decades-old vulnerability in the Domain Name System (DNS)—it doesn’t check for credentials before accepting an answer.

The solution is a protocol called DNSSEC; it adds a layer of trust on top of DNS by providing authentication. When a DNS resolver is looking for blog.cloudflare.com, the .com name servers help the resolver verify the records returned for cloudflare, and cloudflare helps verify the records returned for blog. The root DNS name servers help verify .com, and information published by the root is vetted by a thorough security procedure, including the Root Signing Ceremony.

Eine einfache Einführung in DNSSEC

DNSSEC schafft ein sicheres Domain Name System mit einer zusätzlichen Sicherheitsebene, indem kryptografische Signaturen zu bestehenden DNS-Einträgen hinzugefügt werden. Diese digitalen Signaturen werden in DNS-Nameservern neben den üblichen Eintragstypen wie A, AAAA, MX, CNAME usw. gespeichert. Durch Überprüfung der zugehörigen Signatur können Sie verifizieren, ob ein angefragter DNS-Eintrag von seinem autorisierenden Nameserver stammt und unterwegs nicht verändert wurde – im Gegensatz zu einem gefälschten Eintrag, der bei einem Man-in-the-Middle-Angriff injiziert wurde.

Um die Signaturvalidierung zu erleichtern, fügt DNSSEC ein paar neue DNS-Eintragstypen hinzu:

  • RRSIG: enthält eine kryptographische Signatur
  • DNSKEY: enthält einen öffentlichen Signierschlüssel
  • DS: enthält den Hash eines DNSKEY-Eintrags
  • NSEC und NSEC3: für die explizite Anerkennung der Nicht-Existenz eines DNS-Eintrags
  • CDNSKEY und CDS: für eine untergeordnete Zone zur Anfrage von Aktualisierungen des DS-Eintrags/der DS-Einträge in der übergeordneten Zone.

In diesem Artikel erklären wir die Interaktionen zwischen RRSIG-, DNSKEY- und DS-Einträgen sowie die Art und Weise, wie sie dem DNS eine Vertrauensebene hinzufügen.

RRsets

Der erste Schritt zur Sicherung einer Zone mit DNSSEC besteht darin, alle Einträge des gleichen Typs in einem Ressourcen-Eintrag (Resource Record Set oder RRset) zu gruppieren. Wenn Sie zum Beispiel drei AAAA-Einträge in Ihrer Zone auf demselben Label haben (d. h. label.beispiel.com), würden diese drei Einträge in einem einzigen AAAA RRset gebündelt werden.

Diagramm RRsets

Es ist dieses vollständige RRset, das digital signiert wird, nicht die einzelnen DNS-Einträge. Das bedeutet natürlich auch, dass Sie alle AAAA-Einträge aus einer Zone mit demselben Label anfragen und validieren müssen, nicht nur einen einzigen Eintrag.

Zone-Signing Keys

Jede Zone in DNSSEC verfügt über ein Zone-Signing Key-Paar (ZSK): der private Teil des Schlüssels führt eine digitale Signatur für jedes RRset in der Zone durch, während der öffentliche Teil die Signatur verifiziert. Um DNSSEC zu ermöglichen, erstellt ein Zonenbetreiber mit Hilfe des privaten ZSK digitale Signaturen für jedes RRset und speichert sie in seinem Nameserver als RRSIG-Einträge. Das ist so, als würde man sagen: „Das sind meine DNS-Einträge, sie kommen von meinem Server und so haben sie auszusehen.“

Diagramm Zone-Signing Keys 1

Diese RRSIG-Einträge sind jedoch nutzlos, wenn DNS-Resolver keine Möglichkeit haben, die Signaturen zu verifizieren. Der Zonenbetreiber muss auch seinen öffentlichen ZSK verfügbar machen, indem er ihn in einem DNSKEY-Eintrag zu seinem Nameserver hinzufügt.

Wenn ein DNSSEC-Resolver einen bestimmten Eintragstyp (z. B. AAAA) anfragt, gibt der Nameserver auch den entsprechenden RRSIG zurück. Der Resolver kann dann den DNSKEY-Eintrag mit dem öffentlichen ZSK aus dem Nameserver ziehen. Gemeinsam können das RRset, der RRSIG und der öffentliche ZSK die Antwort validieren.

Diagramm Zone-Signing Keys 2

Wenn wir dem Zone-Signing Key im DNSKEY-Eintrag vertrauen, können wir allen Einträgen in der Zone vertrauen. Was passiert aber, wenn der Zone-Signing Key kompromittiert wurde? Wir brauchen eine Möglichkeit, den öffentlichen ZSK zu validieren.

Key-Signing Keys

Zusätzlich zu einem Zone-Signing Key verfügen DNSSEC-Nameserver auch über einen Key-Signing Key (KSK). Der KSK validiert den DNSKEY-Eintrag auf die gleiche Weise, wie unser ZSK im vorigen Abschnitt den Rest unserer RRSets gesichert hat: Er signiert den öffentlichen ZSK (der in einem DNSKEY-Eintrag gespeichert ist) und erstellt einen RRSIG für den DNSKEY.

Diagramm Key-Signing Keys 1

Genau wie beim öffentlichen ZSK veröffentlicht der Nameserver den öffentlichen KSK in einem weiteren DNSKEY-Eintrag, der uns den oben gezeigten DNSKEY RRset liefert. Sowohl der öffentliche KSK als auch der öffentliche ZSK werden vom privaten KSK signiert. Die Resolver können dann den öffentlichen KSK nutzen, um den öffentlichen ZSK zu validieren.

Die Validierung für Resolver sieht nun wie folgt aus:

  • Das gewünschte RRset anfragen, das auch den entsprechenden RRSIG-Eintrag zurückgibt.
  • Die DNSKEY-Einträge anfragen, die den öffentlichen ZSK und den öffentlichen KSK enthalten, was auch den RRSIG für das DNSKEY RRset zurückgibt.
  • Den RRSIG des angefragten RRset mit dem öffentlichen ZSK verifizieren.
  • Den RRSIG des DNSKEY RRset mit dem öffentlichen KSK verifizieren.
Diagramm Key-Signing Keys 2

Natürlich kann man das DNSKEY RRset und die entsprechenden RRSIG-Einträge im Cache zwischenspeichern, sodass die DNS-Nameserver nicht ständig mit unnötigen Anfragen bombardiert werden.

Warum verwenden wir separate Zone-Signing und Key-Signing Keys? Wie wir im nächsten Abschnitt erklären werden, ist es schwierig, einen alten oder kompromittierten KSK auszutauschen. Ein Wechsel des ZSK ist dagegen viel einfacher. Dadurch können wir einen kleineren ZSK verwenden, ohne die Sicherheit des Servers zu kompromittieren, wodurch wir die Datenmenge minimieren, die der Server bei jeder Antwort senden muss.

Wir haben jetzt Vertrauen innerhalb unserer Zone aufgebaut, aber DNS ist ein hierarchisches System und Zonen arbeiten selten unabhängig von einander. Erschwerend kommt hinzu, dass der Key-Signing Key von sich selbst signiert wird, und das schafft kein zusätzliches Vertrauen. Wir brauchen einen Weg, um das Vertrauen in unserer Zone mit der übergeordneten Zone zu verbinden.

Delegation Signer-Einträge

DNSSEC führt einen Delegation Signer-Eintrag (DS) ein, um die Übertragung von Vertrauen von einer übergeordneten (Parent Zone) auf eine untergeordnete Zone (Child Zone) zu ermöglichen. Ein Zonenbetreiber hasht den DNSKEY-Eintrag, der den öffentlichen KSK enthält, und gibt ihn an die übergeordnete Zone zur Veröffentlichung als DS-Eintrag weiter.

Diagramm Delegation Signer-Einträge

Jedes Mal, wenn ein Resolver auf eine untergeordnete Zone verwiesen wird, liefert die übergeordnete Zone auch einen DS-Eintrag. Durch diesen DS-Eintrag wissen die Resolver, dass die untergeordnete Zone DNSSEC-fähig ist. Um zu überprüfen, ob der öffentliche KSK der untergeordneten Zone gültig ist, wird er vom Resolver gehasht und mit dem DS-Eintrag der übergeordneten Zone verglichen. Wenn beide übereinstimmen, kann der Resolver davon ausgehen, dass der öffentliche KSK nicht manipuliert wurde, was wiederum bedeutet, dass er allen Einträgen in der untergeordneten Zone vertrauen kann. Auf diese Weise wird eine Vertrauenskette in DNSSEC aufgebaut.

Beachten Sie, dass jede Änderung im KSK auch eine Änderung des DS-Eintrags der übergeordneten Zone erfordert. Das Ändern des DS-Eintrags ist ein mehrstufiger Prozess; falsch durchgeführt kann er zum Bruch der Zone führen. Zuerst muss die übergeordnete Zone den neuen DS-Eintrag hinzufügen. Aber bevor der ursprüngliche DS-Eintrag entfernt werden kann, muss sie warten, bis seine TTL abgelaufen ist. Aus diesem Grund lassen sich Zone-Signing Keys viel einfacher austauschen als Key-Signing Keys.

Explicit Denial of Existence

Wenn Sie das DNS nach der IP-Adresse einer Domain fragen, die nicht existiert, gibt es eine leere Antwort zurück – es gibt keine Möglichkeit, ausdrücklich zu sagen: „Entschuldigen Sie, die von Ihnen angefragte Zone existiert nicht.“ Für das Authentifizieren einer Antwort ist es ein Problem, da es keine Nachricht zum Unterzeichnen gibt. DNSSEC behebt dieses Problem, indem es NSEC- und NSEC3-Eintragstypen hinzufügt. Beide erlauben eine authentifizierte Anerkennung der Nicht-Existenz (authenticated denial of existence).

NSEC funktioniert so, dass es den „nächsten sicheren“ Eintrag zurückgibt. Denken Sie zum Beispiel an einen Nameserver, der AAAA-Einträge für „api“, „blog“ und „www“ definiert. Wenn Sie einen Eintrag für „store“ anfragen, würde er einen NSEC-Eintrag zurückgeben, der „www“ enthält, d. h. es gibt keine AAAA-Einträge zwischen „store“ und „www,“ wenn die Einträge alphabetisch sortiert sind. Dies sagt Ihnen effektiv, dass „store“ nicht existiert. Und da der NSEC-Eintrag signiert ist, können Sie das entsprechende RRSIG wie jedes andere RRset validieren.

Leider erlaubt es diese Lösung jedem, sich durch die Zone zu arbeiten und jeden einzelnen Eintrag zu sammeln, ohne zu wissen, nach welchen er sucht. Wenn der Zonenverwalter davon ausgeht, dass der Inhalt der Zone privat bleibt, kann dieser Umstand eine Sicherheitsbedrohung darstellen. Weitere Informationen zu diesem Problem finden Sie in dem Artikel DNSSEC: Komplexität und Erwägungen und über Cloudflares einzigartige Lösung in dem Artikel DNSSEC Done Right.

Die Vertrauenskette

Wir haben also eine Möglichkeit gefunden, Vertrauen innerhalb einer Zone aufzubauen und sie mit ihrer übergeordneten Zone zu verbinden. Aber woher wissen wir, dass wir dem DS-Eintrag vertrauen können? Nun, der DS-Eintrag ist genau wie jedes andere RRset signiert, was bedeutet, dass er ein entsprechendes RRSIG in der übergeordneten Zone besitzt. Der gesamte Validierungsprozess wiederholt sich, bis wir zum öffentlichen KSK der übergeordneten Zone gelangen. Um diesen KSK zu überprüfen, müssen wir auf den DS-Eintrag dieser übergeordneten Zone zurückgreifen – und dann gehen wir in der Vertrauenskette immer weiter nach oben.

Diagramm der Vertrauenskette

Aber sobald wir schließlich zur Root-DNS-Zone gelangen, stoßen wir auf ein Problem: Es gibt keinen übergeordneten DS-Eintrag mehr, gegen den wir validieren können. Hier zeigt das globale Internet sein menschliches Gesicht.

In der Root Signing Ceremony kommen mehrere ausgewählte Personen aus der ganzen Welt zusammen und signieren das Root DNSKEY RRset in einer sehr öffentlichen und stark kontrollierten Weise. Bei der Ceremony wird ein RRSIG-Eintrag erstellt, der zur Überprüfung der öffentlichen KSK und ZSK des Root-Nameservers verwendet werden kann. Anstatt dem öffentlichen KSK wegen des übergeordneten DS-Eintrags zu vertrauen, nehmen wir an, dass er gültig ist, weil wir den Sicherheitsverfahren rund um den Zugriff des privaten KSK vertrauen.

Es ist ein integraler Aspekt von DNSSEC, Vertrauen zwischen übergeordneten und untergeordneten Zonen aufbauen zu können. Wenn ein beliebiger Teil der Kette gebrochen ist, können wir den angefragten Einträgen nicht mehr vertrauen, weil ein Man-in-the-Middle die Einträge verändern und uns zu jeder beliebigen IP-Adresse leiten könnte.

Zusammenfassung

Ähnlich wie HTTPS bietet DNSSEC eine zusätzliche Sicherheitsebene, indem es authentifizierte Antworten auf einem ansonsten unsicheren Protokoll ermöglicht. HTTPS verschlüsselt den Traffic, sodass niemand, der sich in der Leitung befindet, Ihre Internet-Aktivitäten ausspionieren kann. DNSSEC signiert lediglich die Antworten, sodass Fälschungen erkannt werden können. DNSSEC löst ein reales Problem, ohne eine Verschlüsselung einbauen zu müssen.

Cloudflare hat es sich zum Ziel erklärt, die Aktivierung von DNSSEC so einfach wie möglich zu gestalten. Im Moment müssen Kunden kostenpflichtiger Cloudflare-Tarife einfach nur einen Schalter umlegen, um DNSSEC zu ihren Websites hinzuzufügen. Das aktiviert DNSSEC und lädt einen DS-Eintrag (den wir automatisch generieren werden) zu ihrem Registrar hoch. Erfahren Sie mehr darüber, wie Sie DNSSEC erhalten.

Wir haben auch einen Internet Draft veröffentlicht, der einen automatisierten Weg für die Registries und Registrare vorsieht, DS-Einträge im Namen unserer Kunden hochzuladen. Dies wird Cloudflare in die Lage versetzen, DNSSEC automatisch für unsere gesamte Community zu aktivieren. Updates folgen, bleiben Sie also auf dem Laufenden.

Die Einrichtung von Cloudflare ist ganz leicht



Richten Sie eine Domain in weniger als 5 Minuten ein. Behalten Sie Ihren Hosting-Anbieter. Keine Codeänderungen erforderlich.

Cloudflare-Tarife

Jede Internetanwendung kann von Cloudflare profitieren. Wählen Sie die Tarifoption, die Ihren Bedürfnissen entspricht.


Free

Für persönliche Websites, Blogs und jeden Benutzer, der Cloudflare testen möchte.



Learn More


Pro

Für professionelle Websites, Blogs und Portfolios, die grundlegende Sicherheit und Performance benötigen.


20 $ / Monat

pro Domain


Learn More


Business

Für kleine E-Commerce-Websites und -Unternehmen, die erweiterte Sicherheit und Performance, PCI-Compliance und Prioritätssupport per E-Mail benötigen.


200 $ / Monat

pro Domain


Learn More


Enterprise

Für Unternehmen, die Sicherheit und Performance auf Enterprise-Niveau, priorisierten Rund-um-die-Uhr-Support per Telefon, E-Mail oder Chat und garantierte Betriebszeit benötigen.



Learn More

Diese Kunden verlassen sich auf uns

Mehr als 25,000,000 Internetwebsites