NSEC3 ist ein Verfahren, um im Domain Name System (DNS) das Fehlen eines Domainnamens oder Resource Records mit kryptographischen DNSSEC-Signaturen nachzuweisen. Durch den NSEC3 Resource Record können DNS-Spoofing-Angriffe abgewehrt werden, die vorgaukeln, dass ein bestimmter Domainname nicht existiert. NSEC3 wurde von der IETF im Jahr 2008 als Request for Comments veröffentlicht. Im Gegensatz zu dem alternativen NSEC Resource Record versteckt NSEC3 die existierenden Domainnamen durch eine kryptographische Hashfunktion, um sie vor dem Auslesen per Zone Walking zu schützen.

Mit dem Signieren von DNS-Einträgen mittels DNSSEC kann verifiziert werden, dass diese Einträge nicht verfälscht wurden und von den korrekten autoritativen Nameservern stammen. Zunächst nicht möglich ist es jedoch, das Nicht-Vorhandensein von DNS-Einträgen zu beweisen. Fragt etwa ein Client den Namen test.example.org an, so kann ein Angreifer die entsprechenden Daten aus dem Antwortpakets des Servers entfernen, ohne dass dies dem Client ersichtlich wäre.

Um derartige Attacken zu verhindern, werden alle Namen einer Zone über NSEC Resource Records alphabetisch geordnet ringförmig verkettet, wobei der letzte Eintrag auf den ersten zeigt (siehe NSEC Resource Record). Diese NSEC-Records werden mit einem RRSIG Resource Record unterschrieben. In seinen Antwortpaketen liefert ein DNS-Server zu einem Namen jeweils den zugehörigen NSEC-Eintrag mit.

Semantisch stellt ein NSEC-Resource-Record für den Client also sicher, dass sich zwischen zwei Namen kein weiterer befindet. Dies kann ausgenutzt werden, um eine Liste aller Namen in einer DNS-Zone zu erschließen, indem sequentiell alle NSEC-Resource-Records einer Zone abgefragt werden (Zone Walking). Diese Eigenschaft von NSEC bzw. DNSSEC ist in bestimmten Einsatzszenarien unerwünscht.

Im Gegensatz zu NSEC verwendet NSEC3 Hashwerte der Namen statt Klartext-Label, wodurch die Ordnungsrelation auf der Menge der errechneten Hashwerte definiert wird. Ein NSEC3-Resource-Record bestätigt also, dass zwischen zwei Hashwerten zu Namen der Zone kein Hashwert eines weiteren Namens liegt. Der Resolver kann also den Hash-Wert seines angefragten Labels ermitteln und feststellen, dass der nächste Wert in der Kette ein anderer ist, ohne zu wissen, welchen Inhalt dieser konkret hat.

Die verwendete Hashfunktion und andere Parameter des Verfahrens wie zum Beispiel ein Salt sind im NSEC3 Resource Record hinterlegt und werden vom Resolver ausgewertet. Zusätzlich gibt es pro Zone einen NSEC3PARAM Resource Record, der diese Parameter für den autoritativen Nameserver hinterlegt.

Ein NSEC3 Resource Record besteht aus den folgenden Feldern:

Hashed Owner Name

Base32-kodierter Hashwert eines Domainnamens (Anfang eines NSEC3-Bereichs)

TTL

Time to Live

Klasse

IN (Internet)

Typ

NSEC3

Hash-Algorithmus

verwendete Hashfunktion (1: SHA-1)

Flags

Verwendung der Opt-Out-Funktion (0: kein Opt-Out; 1: Opt-Out)

Iterationen

Anzahl zusätzlicher Hash-Iterationen

Salt

beim Hashing verwendeter Salt-Wert

Next Hashed Owner Name

Base32-kodierter Hashwert eines Domainnamens (Ende eines NSEC3-Bereichs)

Liste der Typen

Liste der vorhandenen Record-Typen unterhalb des Owner Names

Der Zweck eines NSEC3PARAM Resource Records ist es, in der DNS-Zone Parameter für die autoritativen Nameserver zu hinterlegen, die für die NSEC3-Hashberechnung erforderlich sind. Die Informationen sind prinzipiell auch in den NSEC3-Records enthalten, der NSEC3PARAM-Record erleichtert aber die Auffindbarkeit, da er an der Spitze der Zone unter dem Zonennamen abgelegt wird. DNSSEC-Resolver und Validatoren verwenden den NSEC3PARAM-Record nicht.

Der NSEC3PARAM Resource Record besteht aus folgenden Feldern:^[1]

Owner Name

Zonenname

TTL

Time to Live

Klasse

IN (Internet)

Typ

NSEC3PARAM

Hash-Algorithmus

verwendete Hashfunktion (1: SHA-1)

Flags

Verwendung der Opt-Out-Funktion (0: kein Opt-Out; 1: Opt-Out)

Iterationen

Anzahl zusätzlicher Hash-Iterationen

Salt

beim Hashing verwendeter Salt-Wert

Bei Abfrage des nicht existierenden Domainnamens DiesisteinNSEC3Beispiel.de geben die Nameserver von .de folgende drei NSEC3 Resource Records zurück:

pffaak97rt0cs40je4c2iho30cebf3it.de. 7200 IN NSEC3 1 1 15 CA12B74ADB90591A PFFBLDU4RR5BISB2JIOS36ABAJLQNQMS NS DS RRSIG

Dieser Record weist die Nichtexistenz von DiesisteinNSEC3Beispiel.de nach, da dessen Hashwert pffaollcec3ma3e5jl2b2gb7gc9dt3bd zwischen den dargestellten Hashwerten liegt.

tjlb7qbojvmlf1s6gdriru7vsms1lg16.de. 7200 IN NSEC3 1 1 15 CA12B74ADB90591A TJLG9BE83U1BLVBVCTP8RIQP60D6ATDP NS SOA RRSIG DNSKEY NSEC3PARAM

Dieser Record weist nach, dass der umschließende Domainname de vorhanden ist (Hashwert tjlb7qbojvmlf1s6gdriru7vsms1lg16). Dieser Nachweis ist erforderlich, damit der Client weiß, unterhalb von welchem Domainnamen ein eventueller Wildcard-Record zu suchen ist.

nihitgish70cve28nu73a3segd6r1d4p.de. 7200 IN NSEC3 1 1 15 CA12B74ADB90591A NIHRI169E5SB3FJMDM1I3LTSNURVSITQ NS DS RRSIG

Dieser Record weist die Nichtexistenz eines Wildcard-Records *.de nach, da dessen Hashwert nihkeqi54qck38bpfvggv7rq5jrrd2vp zwischen den dargestellten Hashwerten liegt.

NSEC3 erschwert zwar das Zone Walking, dennoch können durch kryptoanalytische Angriffe die Klartextnamen einer Zone teilweise oder ganz erlangt werden. Der Angriff besteht aus zwei Phasen:^[2]

1. Hash Crawling: Zunächst holt sich der Angreifer durch wiederholtes Anfragen bei den Nameservern die vollständige Kette der NSEC3-Records einer DNS-Zone. Die Anfragenamen wählt der Angreifer zufällig, wobei nur diejenigen Anfragen zum Server gesendet werden, bei denen der Angreifer erwartet einen bislang unbekannten NSEC3-Record zu erhalten. In der Regel ist eine DNS-Anfrage pro NSEC3-Record in der Zone erforderlich.
2. Hash Breaking: Anschließend führt der Angreifer einen Brute-Force-Angriff, Wörterbuchangriff oder Markow-Ketten-Angriff durch, um die NSEC3-Hashwerte zu Klartextnamen zurückzurechnen. Dieses Verfahren ähnelt dem Passwortcracking und kann durch den Einsatz von Grafikprozessoren erheblich beschleunigt werden.

Durch den Einsatz des obigen Angriffsverfahrens auf alle Top-Level-Domains können innerhalb von zwei Wochen 79 % der Klartextnamen wiederhergestellt werden. Die Anzahl an Hash-Iterationen hat keinen signifikanten Einfluss auf die Wiederherstellungsrate, sondern die Qualität des für den Angriff verwendeten Wörterbuchs.^[3]

• RFC: 5155 – DNS Security (DNSSEC) Hashed Authenticated Denial of Existence. (Spezifikation von NSEC3 und NSEC3PARAM, englisch).

1. ↑ RFC: 5155 – DNS Security (DNSSEC) Hashed Authenticated Denial of Existence. Abschnitt 4 (englisch).
2. ↑ Matthäus Wander, Lorenz Schwittmann, Christopher Boelmann, Torben Weis: GPU-based NSEC3 Hash Breaking. (PDF; 0,7 MB) In: 2014 IEEE 13th International Symposium on Network Computing and Applications (NCA). IEEE, 2014, ISBN 978-1-4799-5393-6, doi:10.1109/NCA.2014.27. Vortrag: Folien. (PDF; 1,9 MB)
3. ↑ Matthäus Wander: Measurement Survey of Server-Side DNSSEC Adoption. (PDF; 0,4 MB) In: 2017 Network Traffic Measurement and Analysis Conference (TMA). IEEE, 2017, ISBN 978-3-901882-95-1, doi:10.23919/TMA.2017.8002913. Vortrag: Folien. (PDF; 0,5 MB) Video. youtube.