DNSSEC
Um DNS abzusichern, müssen wir zuerst einmal ein grundsätzliches Vertrauen aufbauen, dass die DNS Auflösung wirklich stimmt.
„Wenn ich eine Website aufrufe, woher weiß ich eigentlich, dass die DNS-Antwort nicht manipuliert wurde?“
„Willst du eine ehrliche Antwort? Ohne DNSSEC kannst du das nie zu 100% wissen.“
DNS wurde ursprünglich ohne kryptografische Authentifizierung entwickelt. Deshalb kann ein Resolver, also der DNS-Client nicht sicher beweisen, dass eine passend aussehende Antwort wirklich vom zuständigen DNS-Server stammt. Schafft es ein Angreifer, eine passende gefälschte Antwort vor der echten Antwort zu senden, kann der Resolver sie akzeptieren. Das ist, als würdest du jemanden nach dem Weg fragen und könntest nicht sicher erkennen, ob die zuerst eintreffende Antwort tatsächlich von der angesprochenen Person stammt.
DNSSEC (DNS Security Extensions) löst dieses Problem: Es ergänzt DNS um kryptografische Signaturen.
Jede DNS-Antwort wird vom autoritativen DNS-Server mit einem privaten Schlüssel signiert. Der anfragende Resolver kann die Signatur mit dem öffentlichen Schlüssel verifizieren und erkennt so, ob eine Antwort manipuliert wurde.
DNSSEC heißt also: Jede DNS-Antwort trägt eine digitale Unterschrift. Stimmt die Unterschrift nicht, wird die Antwort verworfen.
Als Beispiel: Du fragst: „Wohin zeigt member.cybersec-academy.de?“
Ohne DNSSEC könnte ein Angreifer im WLAN antworten: „Auf meine IP“ und dich auf eine Fake-Anmeldeseite lenken.
Mit DNSSEC hat die echte Antwort eine digitale Unterschrift. Passt die nicht, wird sie verworfen.
Dafür wird quasi eine „Vertrauenskette“ gebildet.
- Der Zoneninhaber signiert alle DNS-Einträge seiner Zone mit seinem ZSK (Zone Signing Key).
- Der ZSK wird seinerseits durch einen übergeordneten KSK (Key Signing Key) signiert.
Stell dir eine Kette von Stempeln vor: Root bestätigt .de, .de bestätigt beispiel.de, und beispiel.de bestätigt seine Einträge. Dein DNS-Resolver prüft diese Stempel und vertraut der Antwort nur, wenn wirklich die ganze Kette stimmt. Die nachfolgende Abbildung veranschaulicht das Konzept:
Dafür gibt es einige wichtige DNSSEC-Record-Typen:
RRSIG: Enthält die digitale Signatur für einen DNS-EintragDNSKEY: Enthält den öffentlichen Schlüssel der Zone (ZSK und KSK) um die Signatur zu prüfenDS(Delegation Signer): Verknüpft die Schlüssel einer Kindzone mit der Elternzone, fungiert wie das Bindeglied in der VertrauensketteNSEC/NSEC3: Beweist, dass ein angefragter DNS-Eintrag nicht existiert (authentifizierte Nichtexistenz)
Teste dein erlerntes Wissen über DNSSEC:
Praxisübung
Prüfe selbst, ob eine Domain DNSSEC benutzt. Dafür kannst du das Tool dig verwenden. Es ist in Kali bereits vorinstalliert. Führe folgendes Kommando aus:
dig +dnssec bnd.bund.de
Die ANSWER SECTION kurz erklärt:
bsi.bund.de. 600 IN A 80.245.144.218: Der Hosteintrag zeigt auf die IPv4-Adresse80.245.144.218.bsi.bund.de. 600 IN RRSIG A ... bund.de. ...: Das ist die DNSSEC-Signatur zum A-Record. Heißt: „Diese IP-Antwort wurde von der Zone signiert und kann geprüft werden.“
Die Elemente der DNSSEC-Signatur stellen sich folgendermaßen zusammen:
RRSIG A: Signatur für den A-Record13: Signatur-Algorithmus (13 = ECDSAP256SHA256 – das steht für ECDSA/SHA-256)3: Anzahl der Labels im ursprünglichen Namen (bsi.bund.de, drei Elemente)600: Original-TTL, sie wird in die Signaturprüfung einbezogen202600926104402 / 20260916104402: Zeitstempel, gültig bis / gültig ab (Signatur-Zeitraum)41004 bund.de.: Key-ID und signierende Zone bund.de (weil bsi.bund.de darunter liegt)- Der lange Base64-Block am Ende ist die eigentliche Signatur (Unterschrift)
Nachfolgend eine kleine Challenge für dich, mal sehen, ob du es herausbekommst.