DNSSEC am Router aktivieren - doppelt gemoppelt?

WilleHelm

Cadet 3rd Year
Registriert
Juli 2012
Beiträge
47
Hallo!

DNSSEC ist gerade in aller Munde und nachdem es für praktisch alle Auswirkungen hatte, frage ich mich, ob mein Verständnis davon überhaupt richtig ist.

Ich dachte bisher, DNSSEC muss extra aktiviert werden, weil es ja im Grunde optional ist, weshalb mein Router auch eine eigene Option dafür neben bzw. statt DoH und DoT hat:

1778074404620.png


Quad9 & Co. geben jedenfalls an, sie validieren es, und ich würde meinen, einfach durch Verwendung ihrer Standard-IP als DNS:

1778074496494.png


Jetzt frage ich mich, ob ich all die Zeit am Router unnötig doppelt validieren ließ, wenn es der DNS-Provider im Hintergrund tut!?

Danke schon mal für die Erläuterung! :-)
 
  • Gefällt mir
Reaktionen: KEV24in_Janßen
Der "DNS-Provider" tut es nicht im hintergrund, er unterstützt es.
Damit die Option in deinem Router überhaupt etwas bewirken kann muss eben auch ein DNSSEC fähiger resolver verwendet werden, was in deinem Fall mit Quad9 gegeben ist.
Eine "unnötige doppelte validierung" hat nicht statt gefunden

edit: noch einmal einfacher erklärt was DNSSEC eigentlich machen/bewirken soll:
Es soll verhindern das die Daten (ip des Ziels) manipuliert werden bzw. das diese manipulation erkannt wird.
Natürlich hat der DNS-Server auch geprüft das die Daten die er angefragt hat, auf dem weg zu ihm, nicht manipuliert wurden aber die Daten können ja auch auf dem Weg, vom DNS-Server, zu dir bzw. deinem Router manipuliert werden und um das zu erkennen muss halt auch dein Router diese Prüfung noch durchführen.
 
Zuletzt bearbeitet:
Theoretisch ist das doppelt gemoppelt, ja. Der Upstream-Resolver führt ja schon die DNSSEC-Validierung durch. Wenn du DNSSEC selbst nicht aktiv einschaltest, vertraut dein Router der Validierungsprüfung des Upstream-Resolvers.

Wenn du DNSSEC aktivierst, prüft der Resolver auf deinem Router noch mal eigenständig die Signaturen. Theoretisch schützt dich das davor, dass der Upstream-Resolver (in deinem Fall also Quad9) falsche Daten sendet.

Da die Infrastruktur von Quad9 nicht unter deiner Kontrolle steht, würde ich den Overhead in Kauf nehmen und DNSSEC einschalten.

Der sauberere Weg wäre natürlich, gar keinen Upstream-Resolver zu nutzen, sondern selbst einen validierenden rekursiven Resolver wie Unbound einzusetzen.
Ergänzung ()

homer0815 schrieb:
DoH ist halt über https, DoT über tls.

Das hat alles überhaupt gar nichts mit DNSSEC zu tun und der komplette Post ist am Thema vorbei.
 
  • Gefällt mir
Reaktionen: WilleHelm und LuxSkywalker
homer0815 schrieb:
DoH ist halt über https, DoT über tls.
Was nur DNSSEC sein soll, keine Ahnung?
Es gibt auch noch Quik.
Warum antwortest du in einem Thread über DNSSEC wenn du selbst zugibst überhaupt nicht zu wissen was das ist?
Warum gehst du dann ausführlich auf DoH und dein DNS-Setup ein, wenn es 0 mit dem Thema zu tun hat?

DNSSEC hat mit DoH, DoT etc. überhaupt nichts zu tun.
 
Ja hab da wohl paar Kürzel verwechselt.
Nach einer Frühschicht sollte ich wohl lieber ins Bett gehen. Irgendwie gehörte das in meinem Hirn zusammen DNSsec und Verschlüsselung.
 
Dankeschön, das erklärt einiges!
Also wenn ich das richtig interpretiere in Bezug auf den großen Ausfall neulich, wird (das optionale) DNSSEC in der Regel von allen DNS-Providern genutzt, also auch dem eigenen ISP-DNS, den wohl die allermeisten nutzen, und ist gar kein besonderes Merkmal mehr eines guten Public Resolvers, weil sonst nur deren Nutzer betroffen gewesen wären?

msgt schrieb:
[...] aber die Daten können ja auch auf dem Weg, vom DNS-Server, zu dir bzw. deinem Router manipuliert werden und um das zu erkennen muss halt auch dein Router diese Prüfung noch durchführen.
Das sprengt natürlich das Thema und den Rahmen, aber kurz gefragt, wie wahrscheinlich ist das Szenario für den Otto Normalverbraucher? Da müsste dann der ISP gehackt worden sein, oder ein Mitarbeiter kriminelle Energien aufwenden?

Ich denke, momentan reicht mir für extra Sicherheit und Privatsphäre Quad9 & Co.
Wenn ich denen auch nicht "vertraue" wird's etwas kompliziert. 😌 Aber ich verstehe den Ansatz mit Unbound & Co.!

Zu guter Letzt bleibt mir bei meinem Router also nur die Wahl einer (außergewöhnlichen) Zweitprüfung oder der Verschlüsselung, weil man kann nur eine Option davon wählen. 🤔
 
Zuletzt bearbeitet:
WilleHelm schrieb:
Also wenn ich das richtig interpretiere in Bezug auf den großen Ausfall neulich, wird (das optionale) DNSSEC in der Regel von allen DNS-Providern genutzt, also auch dem eigenen ISP-DNS, den wohl die allermeisten nutzen, und ist gar kein besonderes Merkmal mehr eines guten Public Resolvers?

DNSSEC-Validierung sollte™️heutzutage Standard sein. Leider gibt es immer noch Resolver da draußen, die keine Validierung durchführen und daher anfällig sind für DNS-Spoofing. Und dazu gehören leider teilweise auch noch die DNS-Server der ISPs.

In diesem Fall waren die paradoxerweise eben nicht von dem DENIC Fuckup betroffen. Denn wenn Signaturen nicht geprüft werden, fallen eben auch falsche Signaturen nicht auf. Die validierenden Resolver haben die kaputte Signatur erkannt und daraufhin die Antworten abgelehnt. So soll das ja auch sein, das ist der Sinn von DNSSEC.

WilleHelm schrieb:
Zu guter Letzt bleibt mir bei meinem Router also nur die Wahl einer (unüblichen?) Zweitprüfung

Es spricht gar nichts dagegen, die Validierung noch mal lokal durchzuführen. Der Resolver auf deinem Router speichert dann den sog. Trust Anchor, das ist der öffentliche Schlüssel der DNS-Root-Zone. Wenn du jetzt eine Domain auflöst, fordert dein Router neben A und AAAA Records zusätzlich die digitalen Signaturen an und validiert diese mit diesem Schlüssel. Ich würde hier den Zero Trust Ansatz fahren: warum dem Upstream Resolver vertrauen, wenn man die Signaturen auch selbst prüfen kann? Also DNSSEC einschalten.

WilleHelm schrieb:
oder der Verschlüsselung, weil man kann nur eine Option wählen. 🤔

Ich nehme an, hier wird einfach davon ausgegangen, dass ein DoH/T/Q Resolver sowieso eine Validierung durchführt und es nicht erforderlich ist, diese noch mal selbst durchzuführen. Sehe ich, wie gesagt, anders.

Die Alternative habe ich ja schon genannt:
CoMo schrieb:
Der sauberere Weg wäre natürlich, gar keinen Upstream-Resolver zu nutzen, sondern selbst einen validierenden rekursiven Resolver wie Unbound einzusetzen.

Unbound ist ein vollständiger rekursiver Resolver. Du machst dich damit unabhängig von irgendwelchen DNS-Servern im Internet. In der Pi-Hole Doku ist der Unterschied gut beschrieben:

https://docs.pi-hole.net/guides/dns/unbound/#what-does-this-guide-provide
 
  • Gefällt mir
Reaktionen: dideldei und WilleHelm
Herzlichen Dank für die ausführlichen Antworten! 🙂
 
  • Gefällt mir
Reaktionen: CoMo
Zurück
Oben