Ein zusätzlicher Faktor, der die Datei extrem aufbläht, sind die NSEC-Einträge, die ihrerseits ebenfalls signiert werden müssen. Diese Einträge dienen dazu, das Nicht-Vorhandensein von Einträgen zu beweisen. Hierzu werden die Zoneneinträge intern alphanumerisch sortiert. Jeder NSEC-Eintrag gehört zu einem normalen RR und zeigt auf den nachfolgenden normalen RR. Der NSEC-Eintrag von
»ns.avc.local
«
zeigt im Beispiel auf
»www.avc.local
«
, da dieser an nächster Stelle folgt. Der NSEC-RR des letzten Eintrags (hier:
»www.avc.local
«
) zeigt auf die Zone selbst, also
»avc.local
«
. Damit schließt sich der Kreis. Fragt ein Resolver zum Beispiel nach dem Eintrag
»server1.avc.local
«
, teilt der Server ihm die Nicht-Existenz durch einen NSEC-Eintrag mit, der für
»ns.avc.local
«
als nächstfolgenden Eintrag
»www.avc.local
«
enthält.
Dieses Konzept führt jedoch zu dem Problem, dass ein Angreifer durch geschickte Abfragen der Zone sämtliche Einträge einer Zone systematisch auslesen kann. Dieses sogenannte Zone Walking lässt sich durch NSEC3 unterbinden
[2]
. Dieser RR führt den Vorgänger- und Nachfolger-Eintrag nicht im Klartext, sondern als Hashwert. Ein direktes Auslesen der Einträge ist somit nicht mehr möglich. Wurden die Zonenschlüssel KSK und ZSK mit dem Algorithmus NSEC3RSASHA1 erstellt, kann die Zone jederzeit mit NSEC3 signiert werden. Hierzu ist die Option
»-3 -
«
notwendig, wobei der Administrator statt des
»-
«
auch ein zwei Bytes langes Salt angeben kann, um die Sicherheit zu erhöhen. Im einfachsten Fall realisiert er die Signatur mit NSEC3 folgendermaßen:
dnssec-signzone -3 - -o avc.local db.avc.local
Die Konfiguration des Servers ist nur die eine Seite der Medaille. Natürlich müssen die Resolver ebenfalls angepasst werden, um mit DNSSEC richtig umgehen zu können, in diesem Fall also der eigene DNS-Server. Dazu müssen zum einen in der Konfigurationsdatei
»named.conf
«
DNSSEC aktiviert werden, zum anderen ist es notwendig, den Trust Anchor beziehungsweise Secure Entry Point in Form des KSKs einzubinden.
Im einfachsten Fall wird der KSK der Zone
»avc.local
«
selbst genutzt. Hierzu kopiert der Administrator die entsprechende Datei, die den Public Key des KSK enthält, in diesem Beispiel
»Kavc.local.+007+41799.key
«
, auf den Resolver. Hier steht der KSK in einem
»trusted-keys
«
-Statement in der Datei
»named.conf
«
:
trusted-keys { avc.local. 257 3 7 "AwEAAdyIn[...]8Uwg="; };
Das Trusted-Keys-Statement enthält eine Zeile, die bis auf den Passus
»IN DNSKEY
«
der Form eines DNSKEY-RRs entspricht. Darüber hinaus muss der Schlüssel in Anführungszeichen stehen. Nach dem Neustart des Servers kann dieser in seiner Eigenschaft als DNSSEC-fähiger Resolver DNSSEC-Antworten der Zone
»avc.local
«
validieren. In der Realität ist es allerdings sinnvoll, den Public Key des KSK der Root-Zone als Trusted Key einzubinden. Dieser lässt sich inklusive der
»trusted-key
«
-Direktive unter
[3]
herunterladen, oder über den folgenden Befehl abfragen:
dig +dnssec . dnskey