Anlässlich des bevorstehende Tausch des KSK in der DNS Root Zone habe ich mal die DNSSEC Fähigkeiten meines privaten Telekom VDSL Anschlusses überprüft:

Der DNS-Resolver im W724V Typ C (aktuelle FW 09011603.05.012) behandelt falsch signierte DNS Antworten wie korrekt signierte. Als Testfall eignet sich die bewusst falsch signierte Domain fail05.dnssec.works. Hier getestet unter Windows 10 mit dem Cygwin Port von dig 9.11.0-P3.

Die erste Anfrage sollte eigentlich schon SERVFAIL liefern, löst aber den Namen auf:

$ dig @192.168.2.1 fail05.dnssec.works
...
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51569
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
...
;; ANSWER SECTION:
fail05.dnssec.works.    3600    IN      A       5.45.109.212

Die zweite Antwort aus dem DNS- Cache ist noch schlimmer. Das AD (Authenticated Data) Flag ist jetzt gesetzt. Die Antwort signalisiert also, dass die DNS Signatur des A Records verifiziert wurde:

$ dig @192.168.2.1 fail05.dnssec.works
...
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37179
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
...
;; ANSWER SECTION:
fail05.dnssec.works.    3589    IN      A       5.45.109.212

Beide im Speedport eingetragenden DNS-Forwarder der Telekom (217.237.150.115, 217.237.151.205) verhalten sich wie erwartet.

Eine Anfrage mit Validierung liefert SERVFAIL:

$ dig @217.237.151.205 fail05.dnssec.works
...
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 32706
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
...

Eine Anfrage ohne Validierung (CD: Checking Disabled) liefert eine Antwort, aber ohne gesetztes AD Flag:

$ dig @217.237.151.205 +cdflag fail05.dnssec.works
...
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32613
;; flags: qr rd ra cd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
...
;; ANSWER SECTION:
fail05.dnssec.works.    3600    IN      A       5.45.109.212
...

Scheinbar fordert der Speedport von der eingetragenen Forwardern immer nicht validierte Antworten an, und gibt sie dann (ab der 2. Anfrage) sogar als validiert weiter. Das geht doch wohl garnicht, oder?