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)

Die Sache mit dem DNS-Client

Ein elementares Problem bleibt bestehen: Der Client muss zwingend DNSSEC beherrschen, um die Antworten validieren zu können. Dies ist den meisten Stub-Resolvern, also den einfachen Standard-DNS-Clients auf Betriebssystemen wie Linux, Windows und Mac, nicht gegeben. Sie delegieren sämtliche DNS-Auflösungsarbeit durch rekursive Anfragen an ihre DNS-Server, die ihrerseits als Resolver im Internet auftreten und entweder selbst eine rekursive Anfrage an einen Forwarder, zum Beispiel den DNS-Server des Providers, richten oder eine iterative Anfrage direkt an die Root-Server stellen.

Daher wird in der Praxis regelmäßig ein interner DNS-Server für Anfragen durch die Clients des Unternehmens-Netzwerks eingerichtet, der DNSSEC-fähig ist und die Antworten aus dem Internet validieren kann. Dies ist in den meisten Umgebungen jedoch kein Problem, da Clients häufig ohnehin nicht direkt mit dem Internet kommunizieren dürfen und einen DNS-Proxy nutzen. Der DNSSEC-fähige Resolver setzt nun in seiner Anfrage das DO-Flag (DO=DNSSEC OK) und signalisiert damit, dass signierte Antworten erwünscht sind. Liefert der antwortende Server im Internet eine Signatur, die nicht validiert werden kann, behandelt der Resolver die Anfrage als nicht beantwortet, der Client auf der Workstation im Unternehmensnetz erhält somit eine Fehlermeldung. Kann die Signatur erfolgreich überprüft werden, sendet der Resolver an seinen anfragenden Client die Antwort ohne DNSSEC-Informationen, allerdings mit gesetzem AD-Flag (Authenticated Data). Ob der Client dies auswertet oder nicht, ist ihm überlassen. Falls keine Signatur in der Antwort vorhanden ist, wird dies ebenfalls akzeptiert und der DNSSEC-fähige Resolver verhält sich standardmäßig wie bei einer normalen DNS-Abfrage. Somit ist sichergestellt, dass das System kompatibel bleibt.

Schlüssel erzeugen

Will der Administrator auf dem primären DNS-Server der Zone »avc.local« DNSSEC einführen, braucht er zunächst die beiden Schlüsselpaare KSK und ZSK. Hierzu kann er die folgenden beiden Befehle verwenden, die er am besten im BIND-Verzeichnis (bei Debian »/etc/bind« ) ausführt:

dnssec-keygen -f KSK -n ZONE -a NSEC3RSASHA1 -b 2048 avc.local
dnssec-keygen -n ZONE -a NSEC3RSASHA1 -b 1024 avc.local

Die Option »-f KSK« legt den Schlüssel als KSK fest, woraufhin der Schlüssel ein Flag erhält. Ist das Flag nicht gesetzt, handelt es sich um einen ZSK. Der Parameter »-n ZONE« legt die Art des Schlüssels fest, um einen DNSSEC-Schlüssel zu erstellen. Der Algorithmus wird mit »-a NSEC3RSASHA1« so festgelegt, dass auch NSEC3 verwendet werden kann. Die Manpage zu »dnssec-keygen« gibt Auskunft zu weiteren verfügbaren Algorithmen und Schlüsseltypen.

Wichtig ist hier, dass KSK und ZSK denselben Algorithmus verwenden. Schließlich wird die Schlüssellänge mit der Option »-b« definiert, wobei es sinnvoll ist, den KSK länger als den ZSK zu wählen. Beim ZSK kommt es (auch) auf Performance an, hier sind 1024 Bit ein guter Kompromiss. Als Ergebnis des Befehls »dnssec-keygen« finden sich im aktuellen Verzeichnis zwei neue Dateien, die etwa so aussehen:

Kavc.local.+007+41799.private
Kavc.local.+007+41799.key

Dabei handelt es sich um den Private und den Public Key. Ob ein KSK oder ein ZSK vorliegt, offenbart ein Blick in die Datei mit der Endung ».key« :

; This is a key-signing key, keyid 41799,for avc.local.
; Created: 20120131073749 (Tue Jan 31 08:37:49 2012)
; Publish: 20120131073749 (Tue Jan 31 08:37:49 2012)
; Activate: 20120131073749 (Tue Jan 31 08:37:49 2012)
avc.local. IN DNSKEY 257 3 7 AwEAAb[...]

Die ersten drei Zeilen sind nur Kommentare, die letzte Zeile ist der korrekte DNSKEY-RR für den Eintrag in der Zone. Die Zahl 257 zeigt an, dass es sich um einen KSK handelt, 256 steht für ZSK. Beide Schlüssel müssen nun der Zonendatei hinzugefügt werden. Dies ist etwa durch folgenden Befehl möglich, wobei man die Pfade eventuell anpassen muss:

cat Kavc.local.+007+*.key >> /etc/bind/db.avc.local

Anschließend stehen beide notwendigen DNSKEY-RRs in der Zonendatei.

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