DNSsec-Signaturen überprüfen mit Bind

Wer einen authoritativen Nameserver betreibt sollte die eigenen Zonen mit DNSsec sichern. Hier zeige ich euch, wie ihr einen rekursiven Nameserver so einrichtet, dass der DNSsec-Signaturen prüft. Was ist der Unterschied? Authoritative Nameserver sorgen beim Besitzer einer Domain, dass diese gefunden werden kann. Rekursive Nameserver suchen für einen Internetanschluss die richtige Verbindung zu fremden Domains.

Warum soll ich DNSsec aktivieren?

• Ich schütze mich damit gegen Angriffe auf Schwachstellen des DNS-Protokolls. 2008 entdeckte Dan Kaminsky eine Sicherheitslücke bei der über Cache Poisoning DNS-Einträge gefälscht werden können. Ohne DNSsec ist man nicht mehr sicher, dass das DNS die richtige IP-Adresse zu einer Domain liefert.
• Ich kann das DNS nutzen um andere Daten gegen Manipulation geschützt ablegen. Die ssh-Fingerprints-Einträge im DNS sind nicht mehr fälschbar; das Zertifikat für meinen Webserver lässt sich auch überprüfen, wenn ich der ausstellenden Zertifizierungsstelle nicht vertraue. Sogar selbst signierte Zertifikate lassen sich überprüfen. DANE oder TLSA heißt der Standard. Er hat das Potential die Verbreitung von Kryptografie im Internet zu fördern. Das erste Mal überhaupt können nun [Zertifikate beim Mailserverbetrieb wirklich getestet werden.)[https://www.heise.de/netze/meldung/Verschluesselter-Mail-Transport-Posteo-setzt-als-erster-Provider-DANE-ein-2187144.html) Zuvor musste ein Mailserver jedem Zertifikat vertrauen oder konnte nur Verbindungen zu einem engen Zirkel anderer Provider testen.
• DNSsec schützt gegen Spam, den der Provider anzeigt, wenn ich mich bei einer Webadresse vertippe. Immer mehr Provider fälschen DNS-Ergebnisse und zwingen ihre Nutzer bei Tippfehlern in der Webadresse damit auf die eigenen Werbeseiten. Im Web nervt dies nur, andere Dienste haben viel größere Probleme, wenn eine nicht existierende Domain aufgelöst werden kann. Das Internet ist nicht nur Web!
• Ich lerne mehr über die Technik, die ich nutze. Ganz nach persönlicher Einstellung kein Argument oder das wichtigste von allen. Im Moment sind Admins, die sich mit DNSsec auskennen, ihren Kollegen noch zwei Kopflängen voraus. Wer Erfahrung hat kann damit als Experte punkten und blickt in die Zukunft des Internets.

Klar gibt es auch immer ein paar Nachteile:

• „Never change a running system.“ – Meistens ist der Nameserver schon eingerichtet und konfiguriert. Die Administratoren können mit dieser Konfiguration umgehen und das System bedienen. Eine neue Konfiguration kann Fehler auslösen, Administratoren müssen geschult werden und lernen mit neuen Problemen umzugehen.
• Anfragen an den DNS können langsamer werden. Der Nameserver muss zusätzliche Daten abfragen und Signaturen prüfen. Eventuell werden die Antworten anderer Nameserver so groß, dass die Anfragen über das langsamere TCP statt UDP verschickt werden müssen.
• Manche alte Firewall, mancher alte DSL-Router macht Probleme. Hierzu gehören auch Fritz!boxen auf denen keine Updates installiert sind. Das Problem ist, dass diese Geräte die Erweiterungen im DNS-Protokoll, das EDNS-Format nicht kennen. Korrekte DNS-Antworten werden deswegen teilweise als Angriff eingestuft und nicht durchgelassen.
• DNSsec ist hierarchisch aufgebaut. Die Wurzel des Vertrauens ist die root-Zone. Damit haben die Verwalter der root-Zone mehr Macht über den DNS-Namensraum erhalten. Allerdings ist die Gewalt über den Signaturschlüssel verteilt worden. Der Signaturschlüssel wurde auf mehrere sogenannte TCR (Trusted Community Representatives) aufgeteilt. Niemand hat alleine die Möglichkeit die root-Zone zu signieren.

Manche meinen ein weiterer Nachteil sei, dass die Signaturen bei DNSsec nicht im Client sondern im Nameserver des Zugangsproviders geprüft werden. Die Verbindung zwischen Provider-Nameserver und Client sei so nicht geschützt. Dieses Problem lässt sich jedoch leicht dadurch lösen, dass der Client selbst Signaturprüfungen vornimmt. Wenn er das nicht tut, kann man dies nicht dem Protokoll anlasten.

Meiner Ansicht nach überwiegen die Vorteile bei weitem.

Umkonfiguration von Bind

Wir können DNSsec bei der Namensauflösung in bind sehr einfach aktivieren. Im options-Bereich der Konfigurationsdatei müssen nur zwei Zeilen eingetragen werden:

options {
        directory "/var/cache/bind";

        auth-nxdomain no;    # conform to RFC1035
        listen-on-v6 { any; };

        allow-recursion { 127.0.0.1; ::1; };

        dnssec-enable yes;
        dnssec-validation yes;
};

Die Einstellung „dnssec-enable“ aktiviert den grundlegenden Support für DNSsec in Bind. Die Einstellung „dnssec-validation“ aktivert, dass beim Auflösen von Domains die DNSsec-Signaturen mit angefordert und überprüft werden.

Überprüfen, ob eine Domain DNSsec unterstützt

Mit der neuen Konfiguration gehört jede Namensauflösung in eine von zwei Kategorien:

1. Die aufgelöste Domain ist nicht mit DNSsec geschützt. Das Ergebnis ist nicht sicherer als bisher.
2. Die aufgelöste Domain ist durch DNSsec geschützt. Das Ergebnis, das wir bekommen, wurde von Bind überprüft. Wenn die Überprüfung fehlschlägt bekommen wir das Ergebnis gar nicht mehr.

Wie können wir feststellen in welchen dieser beiden Fälle eine Namensauflösung gehört? Entweder wir installieren uns ein Plugin in den Webbrowser. Der DNSsec-Status wird dann in der Adressleiste angezeigt. Hier für Firefox, hier für Chrome und hier für den Internet Explorer.

Auch auf der Kommandozeile können wir eine Domain überprüfen. Wie für alles hat der Befehl dig auch hierfür die passende Option: +dnssec. Der Parameter lässt dig den DNSsec-Status vom Resolver anfordern. Dieser wird dann von dig mit ausgegeben. Im Header wird hierzu das Flag „ad“ angezeigt, wenn die DNSsec-Prüfung erfolgreich war:

# dig switch.ch +dnssec

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> switch.ch +dnssec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36976
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 3, ADDITIONAL: 10

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;switch.ch. IN A

;; ANSWER SECTION:
switch.ch. 60 IN A 130.59.108.97
[...]
;; Query time: 330 msec
;; SERVER: ::1#53(::1)
;; WHEN: Mon May  6 21:33:12 2013
;; MSG SIZE  rcvd: 1211

Achtung Falle: Wer so testen will, ob die eigene Zone korrekt mit DNSsec gesichert ist, kann falsche Ergebnisse bekommen. Wenn ein Nameserver eine Anfrage zu einer selbst gehosteten Domain beantwortet ist das ad-Flag nie gesetzt. Das liegt daran, dass er in diesem Fall keine Überprüfung der Signaturen durchgeführt hat. Das muss er auch nicht, da er bereits weiß, dass die Daten korrekt sind.

Wollt ihr eure eigene Zone überprüfen? Der öffentliche Nameserver von Google macht das für euch: dig example.com +dnssec @8.8.8.8 (8.8.8.8 ist eine der IP-Adressen unter denen Google öffentliche Nameserver betreibt.)