Mit E-Mail-Diensten muss sich jeder Administrator früher oder später einmal beschäftigen. Das zur CeBIT erscheinende ADMIN 02/2012 gibt dazu Praxis-Tipps und ... (mehr)

DNSSEC-Abfragen

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:

  • Erhält er eine signierte Antwort, die er nicht validieren kann, stellt er den Status SERVERFAIL fest und verwirft die Antwort als ungültig.
  • Existiert der angefragte Name in der Zone nicht, liefert der Server entsprechende NSEC-Einträge [3] zurück, und der Resolver stellt den Status NXDOMAIN fest. Auch in diesem Fall handelt es sich um Authenticated Data, das AD-Flag ist also gesetzt.
  • Antwortet der Server mit nicht signierten Zonendaten, wird DNSSEC komplett ignoriert, die Antworten werden als gültig betrachtet und vom Resolver an den Client weitergeleitet.

Wie der Vater, so der Sohn

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 ).

Abbildung 4: Die Vertrauenskette im Fall einer delegierten, ebenfalls signierten Subdomain.

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.

comments powered by Disqus
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Ausgabe /2023