DEV Community

Uhltak Therestismysecret
Uhltak Therestismysecret

Posted on

DNS-Sicherheit: DoT, DoH & DNSSEC im Vergleich – Was schützt wirklich?

#dot #doh #dnssec #netzwerksicherheit

Hook – Warum wir alle schon blind unserem DNS vertrauen (oder nicht)

Stellen Sie sich vor, Sie bestellen ein Pizzaservice, geben Ihre Adresse per Telefon durch und jeder Anruf wird abgehört. Genau das passiert jeden Tag mit Ihrem DNS: Ohne Verschlüsselung kann ein Angreifer sehen, welche Webseiten Sie ansteuern, Antworten manipulieren und Sie zu Phishing‑Seiten umleiten. Die meisten Nutzer glauben, ihr ISP sei neutral, doch das ist ein Trugschluss – der DNS-Resolver kann jederzeit Antworten fälschen. Deshalb ist DNS‑Sicherheit kein Nice‑to‑have, sondern ein Muss. In diesem Artikel zerlegen wir die drei zentralen Bausteine der modernen DNS‑Abwehr – DoT, DoH und DNSSEC – und prüfen, welche Schutzmechanismen sie tatsächlich bieten.

DNS over TLS (DoT) – Der alte Klassiker im neuen Gewand

Was ist DoT?

DNS over TLS (DoT) encapsuliert die klassische DNS‑Abfrage (Port 53/UDP) in einen TLS‑Tunnel (Port 853/TCP). Der Client baut eine TLS‑Verbindung zu einem Resolver auf, verifiziert das Server‑Zertifikat und sendet danach DNS‑Pakete verschlüsselt. Der Vorteil: Der gesamte DNS‑Verkehr ist vor Schnüffel- und Manipulationsversuchen geschützt – solange das Zertifikat vertrauenswürdig ist.

Praktisches Beispiel: DoT mit systemd‑resolved auf Ubuntu 22.04 

# 1. TLS‑Resolver hinzufügen (Cloudflare)
sudo bash -c 'cat > /etc/systemd/resolved.conf.d/99-cloudflare-dns.conf <<EOF
[Resolve]
DNS=1.1.1.1#853
DNS=1.0.0.1#853
DNSOverTLS=yes
EOF'

# 2. systemd‑resolved neu starten
sudo systemctl restart systemd-resolved

# 3. Prüfen, ob DoT aktiv ist
resolvectl status | grep "DNSOverTLS"
Enter fullscreen mode Exit fullscreen mode

Der Befehl resolvectl status zeigt DNSOverTLS=yes – das bedeutet, sämtliche DNS‑Abfragen des Systems laufen jetzt über den verschlüsselten Port 853.

Persönliche Einschätzung

DoT ist ein solides Fundament, weil es das bestehende Resolver‑Modell unverändert lässt. Es lässt sich in praktisch jedem Linux‑Stack aktivieren, benötigt keine extra Software und funktioniert mit bekannten Resolvern wie Cloudflare, Quad9 oder den eigenen ISP‑Servern. Der Haken: DoT nutzt ausschließlich TCP, weshalb in restriktiven Firewalls (z. B. Legacy‑Proxy‑Umgebungen) der Port 853 oft blockiert wird. Außerdem bleibt das eigentliche DNS‑Antworten‑Authentizitätsproblem ungelöst – das ist DNSSEC’s Spielplatz.

DNS over HTTPS (DoH) – Der hippe Cousin aus der Browserwelt

Was ist DoH?

DoH verlagert DNS‑Abfragen in das HTTP/2‑ oder HTTP/3‑Protokoll und kapselt sie in HTTPS (Port 443/TCP). Das Ergebnis: DNS‑Traffic sieht aus wie normaler Web‑Traffic und kann daher von Netzwerk‑Middleboxes kaum mehr unterschieden werden. DoH ist besonders populär bei Browsern (Firefox, Chrome) und mobilen Apps, die bereits HTTPS‑Verbindungen aufbauen.

Praktisches Beispiel: DoH mit cloudflared als lokaler Resolver 

# 1. cloudflared (DoH‑Client) herunterladen
device=$(uname -m); curl -L -o cloudflared https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-${device}
chmod +x cloudflared
sudo mv cloudflared /usr/local/bin/

# 2. System‑d Service für cloudflared erstellen
sudo bash -c 'cat > /etc/systemd/system/cloudflared.service <<EOF
[Unit]
Description=Cloudflare DNS over HTTPS proxy
After=network-online.target
Wants=network-online.target

[Service]
ExecStart=/usr/local/bin/cloudflared proxy-dns --port 5053 --address 127.0.0.1
Restart=on-failure
User=nobody
Group=nogroup

[Install]
WantedBy=multi-user.target
EOF'

# 3. Service starten und aktivieren
sudo systemctl daemon-reload
sudo systemctl enable --now cloudflared

# 4. Localhost‑Resolver in /etc/resolv.conf eintragen
sudo bash -c 'echo "nameserver 127.0.0.1" > /etc/resolv.conf'

# 5. Testen
dig @127.0.0.1 example.com +short
Enter fullscreen mode Exit fullscreen mode

Die Ausgabe bestätigt, dass Anfragen über den lokalen DoH‑Proxy laufen. Der eigentliche DNS‑Verkehr wird via HTTPS zu https://dns.cloudflare.com/dns-query geschickt.

Persönliche Einschätzung

DoH ist der Chamäleon‑Modus des DNS: Er tarnt DNS‑Traffic als normaler HTTPS‑Datenstrom und umgeht Deep‑Packet‑Inspection leicht. Das ist ein starkes Argument in Unternehmensnetzen, wo man sonst nur über dedizierte TLS‑Ports gehen kann. Der Preis: Komplexität. Man muss einen zusätzlichen Proxy‑Dienst betreiben, und die Integration in das bestehende Resolver‑Framework (systemd‑resolved, NetworkManager) ist nicht immer nahtlos. Außerdem kann DoH das klassische DNS‑Caching im System unterlaufen, weil das lokale Proxy‑Programm eigene Caches verwaltet – das kann zu Inkonsistenzen führen.

DNSSEC – Der digitale Fingerabdruck für DNS‑Antworten

Was ist DNSSEC?

DNSSEC (Domain Name System Security Extensions) fügt kryptografische Signaturen zu DNS‑Einträgen hinzu. Jeder Zone‑Owner signiert seine Records mit einem privaten Schlüssel; Resolver prüfen die Signatur mit dem zugehörigen öffentlichen Schlüssel, der in einer übergeordneten Zone (meist die Root‑Zone) verankert ist. Das Prinzip heißt: Authentizität, nicht Vertraulichkeit. DNSSEC verhindert, dass ein Angreifer gefälschte Antworten (Cache‑Poisoning) einschleusen kann – die Signatur würde nicht passen.

Praktisches Beispiel: DNSSEC‑Validierung mit unbound 

# 1. Unbound installieren (Debian/Ubuntu)
sudo apt-get update && sudo apt-get install -y unbound

# 2. Grundkonfiguration aktivieren
sudo bash -c 'cat > /etc/unbound/unbound.conf.d/dnssec.conf <<EOF
server:
  root-hints: "/var/lib/unbound/root.hints"
  auto-trust-anchor-file: "/var/lib/unbound/root.key"
  do-ip4: yes
  do-udp: yes
  do-tcp: yes
  hide-identity: yes
  hide-version: yes
  prefetch: yes
  prefetch-key: yes
  qname-minimisation: yes
  validator:
    trust-anchor-file: "/var/lib/unbound/root.key"
EOF'

# 3. Root‑Hints herunterladen (falls noch nicht vorhanden)
sudo wget -O /var/lib/unbound/root.hints https://www.internic.net/domain/named.cache

# 4. Unbound starten
sudo systemctl restart unbound

# 5. DNSSEC‑Abfrage testen (dig +dnssec)
 dig @127.0.0.1 dnssec-failed.org +dnssec +short
Enter fullscreen mode Exit fullscreen mode

dnssec-failed.org liefert ein SERVFAIL, weil die Zone bewusst falsche Signaturen hat – das beweist, dass unser Resolver DNSSEC korrekt prüft.

Persönliche Einschätzung

DNSSEC ist der einzige echte Schutz gegen gefälschte DNS‑Antworten. Es garantiert, dass die erhaltene IP‑Adresse wirklich vom autorisierten Inhaber stammt. Der Nachteil ist, dass DNSSEC allein die Vertraulichkeit nicht schützt – das macht DoT/DoH nötig. Außerdem erfordert DNSSEC, dass alle Zonen korrekt signiert sind; das ist in der Praxis noch nicht überall der Fall. Auch das Management von Schlüssel‑Rollovern (KSK/ZSK) kann für kleine Betreiber aufwändig sein.

Gemeinsamer Vergleich – Was schützt wirklich?

Merkmal DoT DoH DNSSEC
Ziel Vertraulichkeit (Verschlüsselung) Vertraulichkeit + Tarnung Authentizität (Signatur)
Transportlayer TLS über TCP (Port 853) HTTPS über TCP (Port 443) Kein zusätzlicher Transportlayer
Kompatibilität Breite Unterstützung in System‑Daemons Browser‑first, aber Proxy‑Lösungen nötig Nur von Resolvern geprüft, nicht von Clients
Performance‑Impact gering (ein TLS‑Handshake pro Session) leicht höher (HTTPS‑Header) minimal (Zusatz‑Verifizierung)
Deploy‑Komplexität niedrig (config Datei) mittel (extra Service/Proxy) mittel‑bis‑hoch (Schlüsselmanagement)

Takeaway: Für reine Vertraulichkeit reicht DoT aus, wenn Ihr Netzwerk den Port 853 offen lässt. Wenn Sie Netzwerk‑Inspektoren austricksen wollen, ist DoH das elegante Mittel. Wenn Sie jedoch sicherstellen wollen, dass die erhaltene Antwort wirklich von der legitimen Zone stammt, benötigen Sie DNSSEC – idealerweise kombiniert mit DoT oder DoH, damit Sie sowohl Vertraulichkeit als auch Authentizität erhalten.

Häufige Fehler – Warum die meisten Implementierungen trotzdem unsicher bleiben

  1. Nur DoT/DoH einsetzen, DNSSEC ignorieren – Der Traffic ist verschlüsselt, aber ein Angreifer kann immer noch gefälschte Antworten einspielen, wenn der Resolver DNSSEC‑validiert. Ohne DNSSEC kann ein Man‑in‑The‑Middle die verschlüsselte Verbindung aufbauen und legitime Antworten mit eigenen IPs zurückschicken.
  2. Unterschätzte Firewall‑Restriktionen – Viele Unternehmensfirewalls blockieren Port 853, weil er als „nicht‑standard“ gilt. Das führt dazu, dass DoT‑Clients auf das unverschlüsselte System‑Resolver‑Fallback zurückfallen – ein klassischer fallback‑to‑insecure.
  3. Fehlende Schlüssel‑Rollover‑Strategie bei DNSSEC – Ignoriert man das regelmäßige Erneuern von KSK/ZSK, läuft man Gefahr, dass veraltete Schlüssel nicht mehr vertrauenswürdig sind und legitime Anfragen fehlschlagen.
  4. Duplizierte Caches – DoH‑Proxies (z. B. cloudflared) besitzen eigene Caches, die nicht mit dem System‑Cache synchronisiert werden. Das kann zu verwirrenden Ergebnissen führen, besonders bei TTL‑Änderungen.
  5. Keine Integritätsprüfung des TLS‑Zertifikats – Wenn Sie DoT zu einem privaten Resolver mit selbst‑signiertem Zertifikat verbinden, sollten Sie das Zertifikat in trusted-ca importieren; sonst akzeptiert der Client potenziell kompromittierte Zertifikate.

Fazit & nächster Schritt – So sichern Sie Ihr DNS jetzt sofort

  1. Implementieren Sie DoT auf allen Servern: Ändern Sie /etc/systemd/resolved.conf.d/99-dns.conf und aktivieren Sie DNSOverTLS=yes. Testen Sie mit resolvectl query example.com und prüfen Sie, dass DNSOverTLS aktiv ist.
  2. Setzen Sie einen lokalen DoH‑Proxy (cloudflared) ein, wenn Ihr Netzwerk keine TLS‑Ports zulässt. Das ist ein schneller Win‑Win für Home‑Lab‑ und Small‑Biz‑Umgebungen.
  3. Aktivieren Sie DNSSEC‑Validierung in Ihrem bevorzugten Resolver (unbound, bind9, systemd‑resolved). Der Aufwand ist minimal – ein kurzer Eintrag in der Konfiguration reicht.
  4. Überwachen Sie die DNS‑Logs: Nutzen Sie journalctl -u systemd-resolved bzw. unbound -vv für detaillierte Fehlermeldungen, um Fehlkonfigurationen sofort zu entdecken.
  5. Dokumentieren Sie den Schlüssel‑Rollover‑Plan – Erstellen Sie ein kleines Playbook (z. B. mit Ansible), das das Ersetzen von KSK/ZSK automatisiert und dabei das dnssec-keymgr‑Tool nutzt.

Kurzfassung: Die Kombination aus DoT + DoH (Vertraulichkeit) und DNSSEC (Authentizität) liefert den umfassendsten Schutz für Ihren DNS‑Traffic. Entscheiden Sie je nach Netzwerk‑Policy, welchen Teil Sie zuerst aktivieren – das Ergebnis ist stets besser als das ungesicherte Standard‑DNS.

Nächster Praxis‑Schritt: Öffnen Sie Ihre Server‑Shell, führen Sie das DoT‑Beispiel aus und prüfen Sie mit resolvectl status. Anschließend installieren Sie cloudflared für DoH und testen Sie die lokale Auflösung. Abschließend aktivieren Sie DNSSEC in Unbound, verifizieren Sie mit dig +dnssec. In weniger als einer Stunde haben Sie Ihren DNS‑Stack massiv gehärtet – denn das ist das wahre „What‑really‑protects‑you“-Gefühl.

Top comments (0)