Was ist eigentlich DNSSEC?

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