So funktioniert DNSSEC

Das Domain Name System (DNS) ist das Telefonbuch des Internets. Es teilt Computern mit, wohin sie Informationen senden und wo Sie Informationen abrufen können. Leider akzeptiert es aber auch jede Adresse, die ihm gegeben wird, ohne Fragen zu stellen.

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.

DNSSec-Symbol

Die Lösung ist ein Protokoll namens DNSSEC; es fügt dem DNS eine Vertrauensebene hinzu, indem es eine Authentifizierung bereitstellt. Wenn ein DNS-Resolver nach blog.cloudflare.com sucht, helfen die „.com“ Nameserver dem Resolver 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.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 Domäne in weniger als 5 Minuten ein. Behalten Sie Ihren Hosting-Anbieter. Keine Codeänderungen erforderlich.

Cloudflare Preisgestaltung

Jede Internetanwendung kann von Cloudflare profitieren.
Wählen Sie den Tarif, der Ihren Bedürfnissen entspricht.

Free $ 0 /Monat, pro Website
Einblenden, um weitere Informationen anzuzeigen Ausblenden
Für persönliche Websites, Blogs und jeden Benutzer, der Cloudflare testen möchte.

Mehr dazu

Der Free Plan umfasst alle der folgenden Features:
  • Zeitlich unbeschränkte Abwehr von DDoS-Angriffen
  • Globales CDN
  • Geteiltes SSL-Zertifikat
  • Zugriff auf Konto-Überwachungsprotokolle
  • 3 Page Rules
Alle Funktionen vergleichen
Pro $ 20 /Monat pro Website
Einblenden, um weitere Informationen anzuzeigen Ausblenden
Für professionelle Websites, Blogs und Portfolios, die grundlegende Sicherheit und Performance benötigen.

Mehr dazu

Der Pro Plan enthält alle Leistungen des Free Plans und zusätzlich:
  • Web Application Firewall (WAF) mit Cloudflare-Rulesets
  • Bildoptimierungen mit Polish™
  • Optimierungen für mobile Geräte mit Mirage™
  • I'm Under Attack™-Modus bei Angriffen
  • Zugriff auf Konto-Überwachungsprotokolle
  • 20 Page Rules
Alle Funktionen vergleichen
Business $ 200 /Monat pro Website
Einblenden, um weitere Informationen anzuzeigen Ausblenden
Für kleine E-Commerce-Websites und -Unternehmen, die erweiterte Sicherheit und Performance, PCI-Compliance und Prioritätssupport per E-Mail benötigen.

Mehr dazu

Der Business Plan enthält alle Leistungen des Pro Plans und zusätzlich:
  • Web Application Firewall (WAF) mit 25 benutzerdefinierten Rulesets
  • Upload von benutzerdefiniertem SSL-Zertifikat
  • PCI-Konformität dank Modus für Modern TLS Only und WAF
  • Bypass Cache on Cookie
  • Beschleunigte Bereitstellung dynamischer Inhalte mit Railgun™
  • Prioritätssupport per E-Mail
  • Zugriff auf Konto-Überwachungsprotokolle
  • 50 Page Rules
Alle Funktionen vergleichen
Enterprise Kontakt aufnehmen
Einblenden, um weitere Informationen anzuzeigen Ausblenden
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.

Mehr dazu

Der Enterprise Plan enthält alle Leistungen des Business Plans und zusätzlich:
  • Support auf Enterprise-Niveau per Telefon, E-Mail oder Chat, rund um die Uhr an 365 Tagen im Jahr
  • SLA mit Garantie für 100 % Verfügbarkeit und Erstattung des 25-fachen Betrags
  • DDoS-Schutz auf Enterprise-Niveau mit Netzwerkpriorisierung
  • Erweiterte Web Application Firewall (WAF) mit unbegrenzten benutzerdefinierten Rulesets
  • Rollenbasierter Kontozugriff für mehrere Benutzer
  • Upload von mehreren benutzerdefinierten SSL-Zertifikaten
  • Zugriff auf Raw Logs
  • Zugriff auf Konto-Überwachungsprotokolle
  • Zugeteilte Solution- und Customer Success Engineers
  • Zugriff auf chinesische CDN-Rechenzentren (zusätzliche Gebühren)
  • 100 Page Rules
Alle Funktionen vergleichen

Free

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

Pro

$ 20 / Monat
pro Domain
Für professionelle Websites, Blogs und Portfolios, die grundlegende Sicherheit und Performance benötigen.

Business

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

Enterprise

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

Diese Kunden verlassen sich auf uns

Mehr als 25.000.000 Internetwebsites

trustedby crunchbase black
trustedby ao com black
trustedby zendesk black
logo sofi gray 32px wrapper
trustedby log me in black
trustedby digital ocean black
trustedby okcupid black
trustedby montecito black
trustedby discord black
trustedby library of congress black
trustedby udacity black
trustedby marketo black