#main-nav-header { display:none; }

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.

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.

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

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.

Summary

Similar to HTTPS, DNSSEC adds a layer of security by enabling authenticated answers on top of an otherwise insecure protocol. Whereas HTTPS encrypts traffic so nobody on the wire can snoop on your Internet activities, DNSSEC merely signs responses so that forgeries are detectable. DNSSEC provides a solution to a real problem without the need to incorporate encryption.

Cloudflare’s goal is to make it as easy as possible to enable DNSSEC. All Cloudflare customers can add DNSSEC to their web properties by flipping a switch to enable DNSSEC and uploading a DS record (which we'll generate automatically) to their registrar.: Learn more about how to get DNSSEC.

We’ve also published an Internet Draft outlining an automated way for registries and registrars to upload DS records on behalf of our customers. This will enable Cloudflare to automatically enable DNSSEC for our entire community. Stay tuned for updates.

Millionen von Internetwebsites vertrauen auf uns

Kundenreferenzen anzeigen