Ist DNSSEC sinnvoll?

Question 1

ist DNSSEC sinnvoll?

Dies kann nicht beantwortet werden (welches Wort auch immer Sie in diesem Satz anstelle von „DNSSEC“ verwenden), bis Sie anfangen zu beschreiben, wogegen Sie sich verteidigen möchten.

Wenn Sie die Liste der Risiken/Schwachstellen/Bedrohungen haben, gegen die Sie sich schützen möchten, können Sie herausfinden, welche Lösungen es gibt und für jede Lösung bestimmen, wie nützlich sie ist oder nicht.

DNSSECist bei einigen DNS-Problemen nützlich, aber nicht bei allen. Es bringt neue Probleme mit sich (laufende Wartung von Signaturen und Schlüsseln zum Beispiel), aber auch neue Funktionen (aggressives Caching von allem unterhalb von a, NXDOMAINwenn es ordnungsgemäß von DNSSEC validiert wird).

Selbst wenn ein DNS-Resolver bestätigt, dass ein autorisierter Nameserver die richtigen Daten unverfälscht gesendet hat – wie verhindern wir, dass der DNS-Resolver manipulierte DNS-Antworten an den DNS-Client sendet?

Das ist nichts anderes als heute: Wenn Sie einen öffentlichen DNS-Resolver verwenden ( 8.8.8.8, 1.1.1.1um 9.9.9.9nur einige zu nennen), gehen Sie natürlich das VOLLSTÄNDIGE Risiko ein, dass er Ihnen Datenmüll sendet. Das ist ein Kompromiss. DoH/DoT löst hier nichts, da es nur die Inhaltsübertragung zwischen Ihnen und diesem Resolver schützt, nicht den Inhalt selbst. Welcher Inhalt ist durch DNSSEC „geschützt“, solange der Domänenname, für den Sie Abfragen durchführen, durch DNSSEC geschützt ist (das ist ein Teil, den Sie in Ihren Fragen vergessen haben und der DNSSEC tatsächlich schwierig macht: Domänennamenbesitzer müssen es aktivierenUNDDNS-Resolver müssen die neuen Signaturen verwenden und die Validierung durchführen; wenn ein Teil dieser Gleichung mit zwei Variablen nicht vorhanden ist, ist DNSSEC nicht nützlich, weil es einfach nicht funktionieren kann)

Die Frage dreht sich also eher darum, welchen rekursiven Nameserver man verwenden soll und wo er laufen soll. Um maximale Kontrolle zu haben, sollte der Resolver natürlich auf IHREN Rechnern laufen. Er kann dort weiterhin externe Ressourcen und DNS-Resolver verwenden, aber die endgültige DNSSEC-Validierung sollte auf Ihrem Nameserver und nicht auf anderen erfolgen. Natürlich ist das mehr Arbeit, als sich einfach auf eine andere Ressource zu verlassen, die den ganzen DNSSEC-Kram „kostenlos“ für Sie erledigt.

Wenn der DNS-Resolver DNSSEC nicht unterstützt, kann er dann trotzdem DNS-Abfragen an einen autoritativen Nameserver senden, für dessen Zone DNSSEC eingerichtet ist?

Ja. Ein Resolver, der DNSSEC-Daten haben möchte, muss in seiner Anfrage das Flag "DO" umschalten.

Aus digder Dokumentation:

        +[no]dnssec
         This option requests that DNSSEC records be sent by setting the DNSSEC OK (DO) bit in the OPT record in the additional section of the query.

Was Sie so sehen können:

$ dig +dnssec example.com

; <<>> DiG 9.16.18 <<>> +dnssec example.com
;; global options: +cmd
;; Sending:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40492
;; flags: rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
                           ^^

Oder aus §3.2.1 von RFC 4035:

3.2.1. Das DO-Bit

Die Resolver-Seite eines sicherheitsbewussten rekursiven Nameservers MUSS das DO-Bit beim Senden von Anfragen setzen, unabhängig vom Status des DO-Bits in der von der Nameserver-Seite empfangenen initiierenden Anfrage. Wenn das DO-Bit in einer initiierenden Abfrage nicht gesetzt ist, MUSS die Nameserver-Seite alle authentifizierenden DNSSEC-RRs aus der Antwort entfernen, darf jedoch KEINE DNSSEC-RR-Typen entfernen, die die initiierende Abfrage explizit angefordert hat.

Wenn der DNS-Client (rekursiver Resolver) dies tut UND wenn der abgefragte autoritative Nameserver DNSSEC aktiviert hat (daher RRSIG/ NSEC/ NSEC3Datensatztypen in den Zonen), dann erhält der Resolver diese Datensätze und kann anschließend die DNSSEC-Validierung durchführen.

Wenn Sie (ein DNS-Stub/Client, der kein Resolver ist) einen rekursiven Resolver abfragen, haben Sie die Möglichkeit, das CDFlag zu verwenden, das wie folgt definiert ist:

        +[no]cdflag
        This option sets [or does not set] the CD (checking disabled) bit in the query. This requests the server to not perform DNSSEC validation of responses.

(Vorsicht vor der möglichen doppelten Verneinung).

Wenn der Client nicht verwendet CD, ist die DNSSEC-Validierung NICHT deaktiviert, sondern aktiviert und der Remove-Server liefert entweder die endgültige Antwort (wenn DNSSEC für den Datensatz aktiviert ist UND die Validierung erfolgreich war) oder antwortet mit, NXDOMAINwenn die DNSSEC-Validierung fehlgeschlagen ist. Das Flag ADwird gesetzt, um anzuzeigen, dass alle Datensätze als sicher validiert wurden, wenn dies der Fall ist (wenn die Abfrage von einem rekursiven Nameserver kommt, kann dieses Flag nicht von einem autoritativen Nameserver stammen, da Sie die vollständige DNSSEC-Kette vom IANA-Stamm benötigen, um einen bestimmten Datensatz zu validieren).

Answer

ist DNSSEC sinnvoll?

Dies kann nicht beantwortet werden (welches Wort auch immer Sie in diesem Satz anstelle von „DNSSEC“ verwenden), bis Sie anfangen zu beschreiben, wogegen Sie sich verteidigen möchten.

Wenn Sie die Liste der Risiken/Schwachstellen/Bedrohungen haben, gegen die Sie sich schützen möchten, können Sie herausfinden, welche Lösungen es gibt und für jede Lösung bestimmen, wie nützlich sie ist oder nicht.

DNSSECist bei einigen DNS-Problemen nützlich, aber nicht bei allen. Es bringt neue Probleme mit sich (laufende Wartung von Signaturen und Schlüsseln zum Beispiel), aber auch neue Funktionen (aggressives Caching von allem unterhalb von a, NXDOMAINwenn es ordnungsgemäß von DNSSEC validiert wird).

Selbst wenn ein DNS-Resolver bestätigt, dass ein autorisierter Nameserver die richtigen Daten unverfälscht gesendet hat – wie verhindern wir, dass der DNS-Resolver manipulierte DNS-Antworten an den DNS-Client sendet?

Das ist nichts anderes als heute: Wenn Sie einen öffentlichen DNS-Resolver verwenden ( 8.8.8.8, 1.1.1.1um 9.9.9.9nur einige zu nennen), gehen Sie natürlich das VOLLSTÄNDIGE Risiko ein, dass er Ihnen Datenmüll sendet. Das ist ein Kompromiss. DoH/DoT löst hier nichts, da es nur die Inhaltsübertragung zwischen Ihnen und diesem Resolver schützt, nicht den Inhalt selbst. Welcher Inhalt ist durch DNSSEC „geschützt“, solange der Domänenname, für den Sie Abfragen durchführen, durch DNSSEC geschützt ist (das ist ein Teil, den Sie in Ihren Fragen vergessen haben und der DNSSEC tatsächlich schwierig macht: Domänennamenbesitzer müssen es aktivierenUNDDNS-Resolver müssen die neuen Signaturen verwenden und die Validierung durchführen; wenn ein Teil dieser Gleichung mit zwei Variablen nicht vorhanden ist, ist DNSSEC nicht nützlich, weil es einfach nicht funktionieren kann)

Die Frage dreht sich also eher darum, welchen rekursiven Nameserver man verwenden soll und wo er laufen soll. Um maximale Kontrolle zu haben, sollte der Resolver natürlich auf IHREN Rechnern laufen. Er kann dort weiterhin externe Ressourcen und DNS-Resolver verwenden, aber die endgültige DNSSEC-Validierung sollte auf Ihrem Nameserver und nicht auf anderen erfolgen. Natürlich ist das mehr Arbeit, als sich einfach auf eine andere Ressource zu verlassen, die den ganzen DNSSEC-Kram „kostenlos“ für Sie erledigt.

Wenn der DNS-Resolver DNSSEC nicht unterstützt, kann er dann trotzdem DNS-Abfragen an einen autoritativen Nameserver senden, für dessen Zone DNSSEC eingerichtet ist?

Ja. Ein Resolver, der DNSSEC-Daten haben möchte, muss in seiner Anfrage das Flag "DO" umschalten.

Aus digder Dokumentation:

        +[no]dnssec
         This option requests that DNSSEC records be sent by setting the DNSSEC OK (DO) bit in the OPT record in the additional section of the query.

Was Sie so sehen können:

$ dig +dnssec example.com

; <<>> DiG 9.16.18 <<>> +dnssec example.com
;; global options: +cmd
;; Sending:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40492
;; flags: rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
                           ^^

Oder aus §3.2.1 von RFC 4035:

3.2.1. Das DO-Bit

Die Resolver-Seite eines sicherheitsbewussten rekursiven Nameservers MUSS das DO-Bit beim Senden von Anfragen setzen, unabhängig vom Status des DO-Bits in der von der Nameserver-Seite empfangenen initiierenden Anfrage. Wenn das DO-Bit in einer initiierenden Abfrage nicht gesetzt ist, MUSS die Nameserver-Seite alle authentifizierenden DNSSEC-RRs aus der Antwort entfernen, darf jedoch KEINE DNSSEC-RR-Typen entfernen, die die initiierende Abfrage explizit angefordert hat.

Wenn der DNS-Client (rekursiver Resolver) dies tut UND wenn der abgefragte autoritative Nameserver DNSSEC aktiviert hat (daher RRSIG/ NSEC/ NSEC3Datensatztypen in den Zonen), dann erhält der Resolver diese Datensätze und kann anschließend die DNSSEC-Validierung durchführen.

Wenn Sie (ein DNS-Stub/Client, der kein Resolver ist) einen rekursiven Resolver abfragen, haben Sie die Möglichkeit, das CDFlag zu verwenden, das wie folgt definiert ist:

        +[no]cdflag
        This option sets [or does not set] the CD (checking disabled) bit in the query. This requests the server to not perform DNSSEC validation of responses.

(Vorsicht vor der möglichen doppelten Verneinung).

Wenn der Client nicht verwendet CD, ist die DNSSEC-Validierung NICHT deaktiviert, sondern aktiviert und der Remove-Server liefert entweder die endgültige Antwort (wenn DNSSEC für den Datensatz aktiviert ist UND die Validierung erfolgreich war) oder antwortet mit, NXDOMAINwenn die DNSSEC-Validierung fehlgeschlagen ist. Das Flag ADwird gesetzt, um anzuzeigen, dass alle Datensätze als sicher validiert wurden, wenn dies der Fall ist (wenn die Abfrage von einem rekursiven Nameserver kommt, kann dieses Flag nicht von einem autoritativen Nameserver stammen, da Sie die vollständige DNSSEC-Kette vom IANA-Stamm benötigen, um einen bestimmten Datensatz zu validieren).

Question 2

Idealerweise validieren Sie lokal auf dem Client (heutzutage nicht mehr so üblich, aber keineswegs unbekannt) oder verlassen sich auf einen sicheren Netzwerkpfad, der die Lücke zwischen dem Client und einem vertrauenswürdigen Validierungs-Resolver überbrücken kann.
Dieser sichere Netzwerkpfad könnte etwas wie DNS-over-TLS, DNS-over-HTTPS, DNSCrypt oder bis zu einem gewissen Grad ein lokales Netzwerk sein (schwächeres Vertrauensniveau, aber immer noch nützlich für eine Teilmenge von Angriffsszenarien).
Ja

Answer

Idealerweise validieren Sie lokal auf dem Client (heutzutage nicht mehr so üblich, aber keineswegs unbekannt) oder verlassen sich auf einen sicheren Netzwerkpfad, der die Lücke zwischen dem Client und einem vertrauenswürdigen Validierungs-Resolver überbrücken kann.
Dieser sichere Netzwerkpfad könnte etwas wie DNS-over-TLS, DNS-over-HTTPS, DNSCrypt oder bis zu einem gewissen Grad ein lokales Netzwerk sein (schwächeres Vertrauensniveau, aber immer noch nützlich für eine Teilmenge von Angriffsszenarien).
Ja

Ist DNSSEC sinnvoll?

Antwort1

Antwort2

verwandte Informationen