Was ist eigentlich DNSSEC?

Ein Problem von DNS in der heutigen Zeit ist, dass die Antwort einer DNS-Abfrage nicht überprüfbar ist und daher auch gefälscht werden kann. Wie diese Überprüfung doch ermöglicht werden kann, erkläre ich in diesem Blogbeitrag.

Was DNS ist, habe ich bereits in einem anderen Blogbeitrag beschrieben. Es gibt verschiedene Möglichkeiten, warum eine DNS-Antwort gefälscht sein kann. Zum Beispiel die Umsetzung von Netzsperren auf DNS-Basis, wobei die Antwort (IP-Adresse) nicht der tatsächlichen IP-Adresse entspricht, sondern eine IP-Adresse zurückgeliefert wird, die bspw. auf eine Portalseite einer Behörde zeigt.

Oder aber auch, dass ein Internet Service Provider (ISP) mit der gleichen Methode Anfragen an nicht-existierende Domains auf eine eigene Portalseite umleitet, auf der gegebenenfalls auch Werbung erscheint.

Um eine Überprüfung zu ermöglichen, wurde das DNS um DNSSEC erweitert (RFC4033, RFC4034 und RFC4035). DNSSEC ergänzt das DNS um eine Quellenauthentisierung (sichert den Datenpfad zwischen dem DNS Client und dem DNS Server), Integritätssicherung (Erkennung von Manipulationen der Antwort) und gesicherte Nicht-Existenz von DNS-Einträgen.

Wie genau funktioniert jetzt DNSSEC?

Da DNSSEC eine Erweiterung von DNS ist, werden zu den bereits möglichen Resource Records entsprechend weitere Resource Records als Antwort geliefert (RRSIG, DNSKEY, NSEC3 NSEC3 PARAM).
Das bedeutet, es werden mehr als nur die eigentlichen Resource Records zurückgeliefert, wenn die Anfrage als DNSSEC-Anfrage definiert ist.

Hierzu ein Beispiel wenn die Validierung fehl schlägt:

$ dig @1.1.1.1 +dnssec +multi www.dnssec-failed.org

; <<>> DiG 9.11.3-1ubuntu1.3-Ubuntu <<>> @1.1.1.1 +dnssec +multi www.dnssec-failed.org
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 1622
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.dnssec-failed.org. IN A
;; Query time: 109 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Mon Nov 26 11:51:26 CET 2018
;; MSG SIZE  rcvd: 39

Hier ein Beispiel, wenn es für den Eintrag keine Signatur gibt, aber DNSSEC-Validierung gefordert wurde. Dann wird der eigentliche RR zurückgeliefert:

$ dig @1.1.1.1 +dnssec +multi www.google.com      

; <<>> DiG 9.11.3-1ubuntu1.3-Ubuntu <<>> @1.1.1.1 +dnssec +multi www.google.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40038
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1452
;; QUESTION SECTION:
;www.google.com.                IN A

;; ANSWER SECTION:
www.google.com.         15 IN A 216.58.214.36
;; Query time: 5 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Mon Nov 26 11:51:48 CET 2018
;; MSG SIZE  rcvd: 59

Wenn DNSSEC für die Domain konfiguriert ist und der lokale Client diese prüft (in der Regel die Betriebssysteme, welche die Namensauflösung bereitstellen), wird die Namensauflösung wie gewohnt funktionieren, außer die Antwort konnte nicht validiert werden.
In diesem Fall erreicht man zwar den gewünschten Dienst nicht, jedoch wird man auch nicht auf eventuell unerwünschte Dienste „umgeleitet“.

Alternativen zu DNSSEC

Aus Sicht des Datenschutzes gegenüber mitlesenden Internet Service Providern bietet DNSSEC keinen Vorteil, da hier die Anfragen weiterhin im Klartext gestellt werden.
Alternativen hierzu werden gerade aktiv entwickelt, einerseits DNS over TLS (siehe hierzu RFC 7858) oder auch DNS over HTTPS (DoH) (Quelle: https://tools.ietf.org). Letzteres wird seit Version 62 in Firefox unterstützt (Quelle: https://daniel.haxx.se/blog).

3 Kommentare

  1. Interessanter und gut verständlicher Beitrag.
    So wie ich es verstanden habe werden durch DNSSEC auch Angriffe wie Cache Poisoing bzw. DNS-Spoofing verhindert, da hierbei die Resource Records mit Signaturen versehen werden, die durch Verschlüsselungsverfahren erstellt werden und somit für potenzielle Angreifer nicht zugänglich sind. Der Angreifer kann zwar die DNS Antwort fälschen, hat aber keine Signatur.

    1. Das ist richtig. Aber es gilt nur für die DNS RR für die es eine Signatur gibt.

      Die große Mehrheit der Domains wird auch heute noch nicht signiert sein (z.B http://www.google.com).
      Ein Grund hierfür ist der hohe, administrative und technische Aufwand das sauber und fehlerfrei umzusetzen, ohne dass es für den Anbieter einen großen Mehrwert bietet (im Gegensatz zum Benutzer).

      Eine Übersicht der TLD, die selbst signiert sind gibt es hier: http://stats.research.icann.org/dns/tld_report/
      Damit besteht zumindest die Möglichkeit das eine Domains unterhalb dieser TLD signiert werden kann.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

CAPTCHA *