Wie funktioniert DNSSEC?

E-Mail-Server verwenden DNS, um ihre Nachrichten zu routen. Das macht sie anfällig für Sicherheitsprobleme in der DNS-Infrastruktur. Im September 2014 fanden Forscher an der CMU heraus, dass E-Mails, die über Yahoo!-, Hotmail- und Gmail-Server verschickt werden sollten, stattdessen über nicht autorisierte Mail-Server geroutet wurden. Die Angreifer nutzten eine jahrzehntealte Schwachstelle im Domain Name System (DNS) aus: DNS prüft keine Zugangsdaten, bevor es eine Antwort akzeptiert.

Die Lösung ist ein Protokoll namens DNSSEC; es fügt dem DNS eine Vertrauensebene hinzu, indem es eine Authentifizierung bereitstellt. Wenn eine DNS-Auflösung nach blog.cloudflare.com sucht, helfen die „.com“ Nameserver der Auflösung bei der Überprüfung der für „cloudflare“ zurückgegebenen Einträge, und „cloudflare“ hilft bei der Überprüfung der für „blog“ zurückgegebenen Einträge. Die Root-DNS-Nameserver helfen bei der Verifizierung von „.com“ und die von der Root veröffentlichten Informationen werden durch ein gründliches Sicherheitsverfahren, einschließlich der Root Signing Ceremony, überprüft.

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.example.com), würden diese drei Einträge in einem einzigen AAAA RRset gebündelt werden. Veröffentlicht

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.“

Diese RRSIG-Einträge sind jedoch nutzlos, wenn die DNS-Auflösung keine Möglichkeit hat, 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 eine DNSSEC-Auflösung einen bestimmten Eintragstyp (z. B. AAAA) anfragt, gibt der Nameserver auch den entsprechenden RRSIG zurück. Die Auflösung 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.

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.

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 Auflösung kann dann den öffentlichen KSK nutzen, um den öffentlichen ZSK zu validieren.

Die Validierung für die Auflösung 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.

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.

Jedes Mal, wenn eine Auflösung auf eine untergeordnete Zone verwiesen wird, liefert die übergeordnete Zone auch einen DS-Eintrag. Durch diesen DS-Eintrag weiß die Auflösung, dass die untergeordnete Zone DNSSEC-fähig ist. Um zu überprüfen, ob der öffentliche KSK der untergeordneten Zone gültig ist, wird er von der Auflösung gehasht und mit dem DS-Eintrag der übergeordneten Zone verglichen. Wenn beide übereinstimmen, kann die Auflösung 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.

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.

DNSSEC für Registrare

Da das Vertrauen in DNSSEC von oben nach unten erfolgt (die Root-Zone verifiziert die .com-Zone, und die .com- Zone verifiziert die cloudflare.com-Zone usw.), muss der Eigentümer einer Website zur Aktivierung von DNSSEC den DS-Eintrag bei Ihnen, dem Registrar, aktualisieren.

Dieser Teil ist problematisch – das Kopieren und Einfügen des DS-Datensatzes birgt die Möglichkeit menschlicher Fehler und erhöht die Komplexität für weniger erfahrene Nutzer. Wir wollen DNSSEC so einfach wie möglich einführen.

Wenn Cloudflare direkt mit dem Registrar oder der Registrierungsstelle kommunizieren könnte, könnten wir DNSSEC für jede Website auf Cloudflare automatisch aktivieren und ihre Schlüssel ohne menschliches Zutun verwalten.

Im Rahmen unserer DNSSEC-Einführung haben wir gemeinsam mit der .ca-Registrierungsstelle CIRA einen Internet Draft veröffentlicht. Darin schlagen wir ein Protokoll für DNS-Betreiber wie Cloudflare vor, um genau das zu tun: mit Registrierstellen und Registern zu kommunizieren, um die DNSSEC-Verwaltung zu automatisieren.

Machen Sie mit – gemeinsam machen wir DNSSEC zugänglicher für alle

Mehrere Registrare planen bereits, diesen Standard künftig zu unterstützen, darunter etwa NIC Chile (.cl) und eNIC (.ee). Wenn Sie für einen Registrar oder eine Registry arbeiten und daran interessiert sind, mehr zu erfahren, sich an der Entwicklung des Protokolls zu beteiligen oder eine Integration mit Cloudflare vorzunehmen, wenden Sie sich bitte per E-Mail an dnssec-integration@cloudflare.com

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 gemacht, die Aktivierung von DNSSEC so einfach wie möglich zu gestalten. Alle Cloudflare-Kunden müssen 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.