DNS-Sicherheit: DNSSEC, DNS over HTTPS
Klassisches DNS hat ein fundamentales Sicherheitsproblem: Es ist vollständig unverschlüsselt und nicht authentifiziert. Jeder, der im Netzwerkpfad sitzt (ISP, WLAN-Betreiber, Angreifer im selben Netz), kann DNS-Anfragen mitlesen oder manipulieren. Dieses Problem führt zu ernsten Angriffsszenarien: Cache Poisoning, DNS-Hijacking und MITM-Angriffe.
Zwei komplementäre Ansätze adressieren verschiedene Aspekte: DNSSEC löst das Authentizitätsproblem (sind die Antworten echt?), während DNS over HTTPS (DoH) und DNS over TLS (DoT) das Vertraulichkeitsproblem lösen (können Dritte mitlesen?). Für umfassende DNS-Sicherheit braucht man beide. Verbindung zu: Verschlüsselung und Kryptografie, IT-Sicherheit Grundlagen.
1) DNS-Angriffsvektoren
Typische DNS-Angriffe – Klicke für Details
DNS Cache Poisoning
Falsche Einträge in Cache injizieren
DNS Hijacking
DNS-Antworten abfangen/umleiten
DNS Amplification
DDoS via DNS-Verstärkung
DNS Tunneling
Daten in DNS-Anfragen verstecken
Klicke auf einen Angriff für Details.
2) DNS-Sicherheitsmechanismen
Schutzmaßnahmen – Klicke für Details
DNSSECDNS Security Extensions – Authentizität und Integrität
Was schützt DNSSEC? Authentizität und Integrität von DNS-Antworten. Durch digitale Signaturen kann ein Resolver verifizieren, dass eine Antwort tatsächlich vom autoritativen Nameserver stammt und nicht manipuliert wurde.
Wie es funktioniert: Der autoritative NS signiert seine DNS-Records mit einem privaten Schlüssel. Der öffentliche Schlüssel ist im DNS als DNSKEY-Record veröffentlicht. Die Vertrauenskette geht bis zur Root-Zone (IANA signiert die Root).
Neue Record-Typen durch DNSSEC:
• RRSIG: Signatur für einen Record-Set
• DNSKEY: Öffentlicher Schlüssel der Zone
• DS: Delegation Signer (Vertrauenskette)
• NSEC/NSEC3: Authenticated Denial of Existence
Was DNSSEC NICHT schützt: Vertraulichkeit – DNS-Anfragen sind weiterhin im Klartext sichtbar. Dafür: DoH oder DoT. Details: Asymmetrische Kryptografie.
Wie es funktioniert: Der autoritative NS signiert seine DNS-Records mit einem privaten Schlüssel. Der öffentliche Schlüssel ist im DNS als DNSKEY-Record veröffentlicht. Die Vertrauenskette geht bis zur Root-Zone (IANA signiert die Root).
Neue Record-Typen durch DNSSEC:
• RRSIG: Signatur für einen Record-Set
• DNSKEY: Öffentlicher Schlüssel der Zone
• DS: Delegation Signer (Vertrauenskette)
• NSEC/NSEC3: Authenticated Denial of Existence
Was DNSSEC NICHT schützt: Vertraulichkeit – DNS-Anfragen sind weiterhin im Klartext sichtbar. Dafür: DoH oder DoT. Details: Asymmetrische Kryptografie.
DoHDNS over HTTPS – Verschlüsselung und Privatsphäre
Was schützt DoH? Vertraulichkeit von DNS-Anfragen. Anfragen werden wie normaler HTTPS-Traffic verschlüsselt – ISPs und Netzwerkadministratoren können weder Anfragen mitlesen noch einfach blockieren.
Wie es funktioniert: DNS-Anfragen werden als HTTPS-POST/GET-Requests über Port 443 an einen DoH-Resolver gesendet (z.B. https://1.1.1.1/dns-query). Für das Netz sieht es wie normales Web-Browsing aus.
Unterstützung: Firefox (eingebaut, Standard), Chrome/Edge (eingebaut), Windows 11 (systemweit), Android (Private DNS), iOS. Server-seitig: Cloudflare 1.1.1.1, Google 8.8.8.8, NextDNS.
Kontroverse: DoH untergräbt zentrale Netzwerkkontrolle (Firewall-Filtering, Content-Blocking). Für Unternehmensumgebungen problematisch – Clients könnten firmeninternen DNS-Richtlinien umgehen.
Wie es funktioniert: DNS-Anfragen werden als HTTPS-POST/GET-Requests über Port 443 an einen DoH-Resolver gesendet (z.B. https://1.1.1.1/dns-query). Für das Netz sieht es wie normales Web-Browsing aus.
Unterstützung: Firefox (eingebaut, Standard), Chrome/Edge (eingebaut), Windows 11 (systemweit), Android (Private DNS), iOS. Server-seitig: Cloudflare 1.1.1.1, Google 8.8.8.8, NextDNS.
Kontroverse: DoH untergräbt zentrale Netzwerkkontrolle (Firewall-Filtering, Content-Blocking). Für Unternehmensumgebungen problematisch – Clients könnten firmeninternen DNS-Richtlinien umgehen.
DoTDNS over TLS – TLS-gesicherte Verbindung
Was schützt DoT? Wie DoH: Verschlüsselung von DNS-Anfragen durch TLS. Verwendet aber Port 853 (dedizierter DNS-Port) statt HTTPS-Port 443.
Vorteil gegenüber DoH: Port 853 ist eindeutig identifizierbar – Netzwerkadministratoren können DoT-Traffic sehen (aber nicht lesen), filtern oder durch eigene DoT-Server umleiten.
Unterstützung: Android (Private DNS-Einstellung), Linux (systemd-resolved), pfSense, BIND, Unbound. Cloudflare, Google und Quad9 unterstützen beide (DoH + DoT).
Unternehmenseinsatz: DoT ist einfacher in Netzwerkinfrastruktur zu integrieren als DoH – dedizierter Port ist besser kontrollierbar.
Vorteil gegenüber DoH: Port 853 ist eindeutig identifizierbar – Netzwerkadministratoren können DoT-Traffic sehen (aber nicht lesen), filtern oder durch eigene DoT-Server umleiten.
Unterstützung: Android (Private DNS-Einstellung), Linux (systemd-resolved), pfSense, BIND, Unbound. Cloudflare, Google und Quad9 unterstützen beide (DoH + DoT).
Unternehmenseinsatz: DoT ist einfacher in Netzwerkinfrastruktur zu integrieren als DoH – dedizierter Port ist besser kontrollierbar.
3) Vergleich: Plain DNS, DoH, DoT
Vergleich der DNS-Transport-Varianten
Plain DNS (klassisch)
Port: 53 (UDP/TCP)
Verschlüsselung: Keine
Privatsphäre: Keine
Kompatibilität: Universal
Netzwerkkontrolle: Voll kontrollierbar
Performance: Schnellst
DNS over HTTPS (DoH)
Port: 443 (HTTPS)
Verschlüsselung: TLS 1.3
Privatsphäre: Hoch
Kompatibilität: Browser/Apps
Netzwerkkontrolle: Schwer filterbar
Performance: Minimal overhead
DNS over TLS (DoT)
Port: 853 (TCP)
Verschlüsselung: TLS 1.3
Privatsphäre: Hoch
Kompatibilität: OS/Geräte
Netzwerkkontrolle: Filterbar (Port 853)
Performance: Minimal overhead
Best Practice: DNSSEC für Authentizität (auf eigenem autoritativen NS aktivieren) + DoT im Unternehmensnetz für verschlüsselte Resolver-Kommunikation. DoH für End-User-Privatsphäre im mobilen/Heimbereich. Für maximale Sicherheit: eigenen DoH/DoT-Resolver betreiben statt öffentlichen Diensten vertrauen.
Zusammenfassung
| Mechanismus | Schützt gegen | Schützt NICHT gegen |
|---|---|---|
| DNSSEC | Cache Poisoning, gefälschte Antworten | Abhorchen von DNS-Traffic |
| DoH | Abhören, ISP-Tracking | Gefälschte Antworten (ohne DNSSEC) |
| DoT | Abhören, Manipulation im Transit | Gefälschte Antworten (ohne DNSSEC) |
| DNSSEC + DoH | Beides – vollständige DNS-Sicherheit | Kompromittierter Resolver selbst |