Ist DNSSEC in der Konfiguration des Resolvers aktiviert, setzt der Resolver das DO-Flag in DNS-Requests und fordert somit DNSSEC-signierte Antworten an. Für Testzwecke bietet sich an, diese Funktion mit
»dig
«
zu testen. Eine Anfrage nach
»ns.avc.local
«
zeigt
Listing 1
.
Listing 1
dig +dnssec ns.avc.local
01 # dig +dnssec ns.avc.local 02 03 ; <<>> DiG 9.7.3 <<>> +dnssec ns.avc.local 04 ;; global options: +cmd 05 ;; Got answer: 06 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5717 07 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 1 08 09 ;; OPT PSEUDOSECTION: 10 ; EDNS: version: 0, flags: do; udp: 4096 11 ;; QUESTION SECTION: 12 ;ns.avc.local. IN A 13 14 ;; ANSWER SECTION: 15 ns.avc.local. 604252 IN A 192.168.1.1 16 ns.avc.local. 604252 IN RRSIG A 7 3 604800 20120301070708 20120131070708 57422 avc.local. nG2T4+Nt5LcYxIrqaXB+8MKrAvgIqtiyCyJoDfgiaHOn/GHO4sN5MDAn gZ1eXY2KKGE2RYhSndfMVBBjhtUaFLdkPp2e49lbSe2TattGKO811dOm GptWhUn1oSm2/GM4yzPaYhju1i0X9dpVzkblepMVytsYfalNq+esj+s1 nHA= 17 18 ;; AUTHORITY SECTION: 19 avc.local. 604252 IN NS ns.avc.local. 20 avc.local. 604252 IN RRSIG NS 7 2 604800 20120301070708 20120131070708 57422 avc.local. kjE3OGsgrrRpWMlHxuApNaVILFYwM0z3kI/kny8sAM7Du5nbjTVHkd1V qOIaN9Su6uaOosXgjbUuTc6TPjGaTPKmSKlPI7fh/vxVKWt4ijZipYOl 9XfUGJNgAu3vfpRlnQZtcd6DYm3ODXf5uQaHD994ZqCmx+5F+0X2fZyh ssM= 21 22 ;; Query time: 0 msec 23 ;; SERVER: 127.0.0.1#53(127.0.0.1) 24 ;; WHEN: Tue Jan 31 22:28:02 2012 25 ;; MSG SIZE rcvd: 409
Neben den RRSIG-Einträgen, die angezeigt werden, sind insbesondere die Flags in der Header-Sektion interessant: Das Flag
»ad
«
zeigt an, dass es sich um Authenticated Data handelt, die Antwort also validiert werden konnte. Dies bestätigt auch der status:
»NOERROR
«
. Je nach Situation reagiert der Resolver unterschiedlich:
DNS ist ein hierarchisches System, in dem Verantwortlichkeiten für einzelne Zonen delegiert werden. Hierzu definieren die übergeordneten Zonendateien DNS-Server, die für die darunterliegenden Zonen verantwortlich sind. So ist es zum Beispiel möglich, in der Zone
»avc.local
«
einen anderen Server zu bestimmen, der die Subzone
»training.avc.local
«
verwaltet. Auch die untergeordnete Zone kann signiert werden. Hierzu nutzt der Server seinen eigenen KSK und ZSK. Die Herausforderung besteht nun darin, eine Vertrauenskette herzustellen. Dies geschieht durch die erwähnten DS-RRs (DS=Delegation Signer). Dabei wird der Hashwert des KSKs einer untergeordneten Zone erfasst. Ist dieser Eintrag nun durch den ZSK der übergeordneten Zone signiert, gilt er als vertrauenswürdig.
Konkret heißt das in unserem Beispiel: Der Server
»ns.training.avc.local
«
verwaltet die Subdomain
»training.avc.local
«
und hat die entsprechende Zonendatei mit seinem eigenen KSK und ZSK signiert. In der Zonendatei der übergeordneten Zone
»avc.local
«
auf
»ns.avc.local
«
existiert ein DS-Eintrag mit dem Hashwert des KSKs von
»training.avc.local
«
. Dieser wird nun durch die Signatur der gesamten Zonendatei mittels des ZSKs von
»avc.local
«
signiert und ist damit vertrauenswürdig – vorausgesetzt, dem ZSK von
»avc.local
«
wird vertraut. Aber genau dies ist der Fall, da der ZSK von
»avc.local
«
vom KSK für
»avc.local
«
signiert wurde und dieser KSK als Trust Anchor auf dem Resolver eingetragen wurde (
Abbildung 4
).
Technisch ist die Umsetzung nicht wesentlich komplizierter, da
»dnssec-signzone
«
eine Datei namens
»dsset-
Zonenname
«
erstellt, in unserem Beispiel
»dsset-avc.local
«
. Diese Datei enthält die fertigen DS-RRs einmal als SHA1- und zum anderen als SHA2-Wert. Einer der beiden Einträge wird in die Zonendatei der übergeordneten Zone eingetragen. Nach der erneuten Signatur dieser Datei ist der untergeordnete KSK, damit der ZSK und alle signierten Einträge in der Zonendatei für
»training.avc.local
«
vertrauenswürdig. Zwar ist es möglich, jeden beliebigen Eintrittspunkt im hierarchischen System von DNS zu wählen, jedoch ist es naheliegend, den höchstmöglichen SEP zu wählen, damit nur dieser eine Public Key gepflegt werden muss.