Hexenwerk

Jetzt fehlt noch die Signatur der Zone. Der folgende Befehl erzeugt sie:

dnssec-signzone -o avc.local db.avc.local

Das Ergebnis ist eine Datei namens »db.avc.local.signed« . Diese Datei muss der Administrator in die Konfigurationsdatei »named.conf« als Zone-Statement einbinden:

zone "avc.local {
 type master;
 file "/etc/bind/db.avc.local. signed";};

Außerdem ist es notwendig, BIND für seine neue Rolle als DNSSEC-Nameserver zu konfigurieren. Die folgenden beiden Zeilen müssen auf allen beteiligten DNS-Servern unter BIND9 in der Options-Sektion in »named.conf« eingetragen werden, sowohl auf dem Resolver als auch auf dem autoritativen Server:

dnssec enable yes;
dnssec-validation yes;

Anschließend übernimmt ein Neustart des DNS-Server die Änderungen in der Konfiguration und lädt die neue, signierte Zone. Ob dies funktioniert hat, zeigt der Blick in das Syslog-Protokoll, das im Erfolgsfall folgenden Eintrag enthält:

Jan 30 09:19:25 dns1 named[4368]: zone avc.local/IN: loaded serial 2 (DNSSEC signed)

Digitale Signatur

Der Vergleich zwischen der unsignierten und der signierten Zonendatei zeigt, wie viel mehr Informationen notwendig sind, um DNSSEC zu betreiben. Jeder einzelne Zoneneintrag ist durch einen RRSIG-Ressource Record signiert. Dieser enthält die Art des signierten Eintrags (zum Beispiel SOA oder NS), die genutzten Algorithmen, die TTL sowohl für den signierten Eintrag selbst als auch für den RRSIG und die Zeitstempel für den Ablauf und den Beginn der Gültigkeit des RRSIG-RRs. Darüber hinaus ist der Eigner dieses Eintrags aufgeführt. Dies ist regelmäßig die Zone selbst, in diesem Fall also »avc.local« . Schließlich folgt die Signatur. Dabei handelt es sich um einen Hashwert, der mit dem Private Key des ZSK verschlüsselt wurde.