DEV Community

Uhltak Therestismysecret
Uhltak Therestismysecret

Posted on

DNS-Sicherheit im Vergleich: DoT, DoH vs. DNSSEC – Ihr Schutzplan

#dns #dot #doh #dnssec

Der tägliche Datenverkehr wird nie sicherer – es sei denn, Sie tun etwas dagegen

Stellen Sie sich vor, Sie bestellen einen Kaffee und der Barista gibt Ihnen das falsche Getränk – jedes Mal. Genau das passiert, wenn Ihr DNS‑Resolver unverschlüsselt arbeitet: Ihre Anfragen werden auf dem Weg zum autoritativen Server abgefangen, umgelenkt und manchmal sogar manipuliert. Viele glauben, ein VPN sei die ultimative Lösung, doch das ist ein Trugschluss: Das VPN verschlüsselt den Verkehr nach der DNS‑Auflösung, nicht die Auflösung selbst. In diesem Beitrag zeige ich, warum DoT, DoH und DNSSEC die einzigen bausteinweisen sind, die Sie wirklich benötigen – und wie Sie sie in Ihrer Linux‑Umgebung einrichten, testen und dauerhaft betreiben.

DNS over TLS (DoT) – Verschlüsselte DNS‑Abfrage über TLS

Erklärung

DoT transportiert DNS‑Nachrichten über eine etablierte TLS‑Verbindung (Port 853). Damit ist die Kommunikation zwischen Resolver und Upstream‑Server vertraulich und vor Man‑in‑the‑Middle‑Angriffen geschützt. Im Gegensatz zu klassischen UDP‑Abfragen (Port 53) bleibt die Verbindung nach dem Handshake offen, was Latenz verringert – ein großer Gewinn für Endgeräte mit vielen kleinen Anfragen.

Praktisches Beispiel

Wir benutzen Stubby, ein leichtgewichtiger DoT‑Client, der systemweit als lokaler Resolver fungiert. Die Installation auf Debian/Ubuntu läuft mit:

sudo apt-get update && sudo apt-get install stubby -y
Enter fullscreen mode Exit fullscreen mode

Die Konfigurationsdatei /etc/stubby/stubby.yml wird wie folgt angepasst, um Cloudflare (1.1.1.1) und Google (8.8.8.8) als Upstream‑Server zu nutzen:

resolution_type: GET
listen_addresses:
  - 127.0.0.1@53
  - ::1@53
upstream_recursive_servers:
  - address_data: 1.1.1.1
    tls_auth_name: "cloudflare-dns.com"
    tls_port: 853
  - address_data: 8.8.8.8
    tls_auth_name: "dns.google"
    tls_port: 853
Enter fullscreen mode Exit fullscreen mode

Nach dem Speichern aktivieren wir den Dienst:

sudo systemctl restart stubby
sudo systemctl enable stubby
Enter fullscreen mode Exit fullscreen mode

Um sicherzugehen, dass das System Stubby nutzt, ändern wir /etc/resolv.conf (oder die Netzmanager‑Konfiguration) zu:

nameserver 127.0.0.1
Enter fullscreen mode Exit fullscreen mode

Ein kurzer Test mit dig zeigt, dass die Anfragen über TLS gehen:

dig @127.0.0.1 example.com +tls
Enter fullscreen mode Exit fullscreen mode

Wenn das Ergebnis status: NOERROR liefert und das Feld ;; OPT PSEUDOSECTION: eine TLS‑Version anzeigt, funktioniert alles.

Persönliche Einschätzung

DoT ist in meiner täglichen Arbeit das Goldstandard‑Tool, weil es keine zusätzlichen Browser‑Erweiterungen erfordert und auf allen Netzwerk‑Stacks funktioniert. Der einzige Stolperstein ist die Kompatibilität mit manchen Unternehmens‑Proxy‑Setups, die TLS‑Outbound blockieren. Dort hilft ein lokaler Proxy‑Tunnel (z. B. ssh -L) aus.

DNS over HTTPS (DoH) – DNS im HTTP‑Kanal

Erklärung

DoH verpackt DNS‑Payloads in HTTPS‑Requests (Port 443). Der große Vorteil: DoH‑Traffic ist schwer von reinen HTTP(S)-Traffic zu unterscheiden, sodass Firewalls und DPI‑Apparate ihn selten blockieren. Außerdem kann DoH über standardmäßige HTTP‑Bibliotheken wie curl oder Browser‑APIs genutzt werden.

Praktisches Beispiel

Unter Linux nutzen wir das Tool cloudflared (von Cloudflare) als DoH‑Proxy. Installation via apt bzw. Snap:

# Debian/Ubuntu
sudo apt-get install cloudflared -y
# alternativ (falls Snap verfügbar)
sudo snap install cloudflared
Enter fullscreen mode Exit fullscreen mode

Starten wir den Daemon im Hintergrund, der auf 127.0.0.1:53 lauscht und DoH zu Cloudflare (https://cloudflare-dns.com/dns-query) weiterleitet:

cloudflared proxy-dns --address 127.0.0.1 --port 53 --upstream https://cloudflare-dns.com/dns-query
Enter fullscreen mode Exit fullscreen mode

Für ein dauerhaftes System‑Service erstellen wir /etc/systemd/system/cloudflared-dns.service:

[Unit]
Description=Cloudflare DoH Proxy
After=network.target

[Service]
ExecStart=/usr/local/bin/cloudflared proxy-dns --address 127.0.0.1 --port 53 --upstream https://cloudflare-dns.com/dns-query
Restart=on-failure
User=nobody
Group=nogroup

[Install]
WantedBy=multi-user.target
Enter fullscreen mode Exit fullscreen mode

Aktivieren und starten:

sudo systemctl enable cloudflared-dns
sudo systemctl start cloudflared-dns
Enter fullscreen mode Exit fullscreen mode

Ein kurzer Test mit dig über DoH‑Proxy:

dig @127.0.0.1 www.wikipedia.org +https
Enter fullscreen mode Exit fullscreen mode

Falls dig die Option +https nicht kennt, nutzen wir curl zur Kontrolle:

curl -H 'accept: application/dns-message' 'https://cloudflare-dns.com/dns-query?name=example.com&type=A' --output - | hexdump -C
Enter fullscreen mode Exit fullscreen mode

Persönliche Einschätzung

DoH ist praktisch unverzichtbar für moderne Workloads, weil viele Cloud‑Native‑Applikationen bereits native DoH‑Clients implementieren (z. B. systemd-resolved ab v247). Der Trade‑off: DoH kann das DNS‑Caching im Betriebssystem umfahren, wenn mehrere lokale Resolver aktiv sind. In einer produktiven Umgebung halte ich bei Bedarf DoH nur für die Endgeräte und setze DoT für die Server‑Backbone‑Verbindungen ein.

DNSSEC – Authentizität der DNS‑Antworten

Erklärung

Während DoT/DoH die Vertraulichkeit Ihrer Anfragen schützen, garantiert DNSSEC die Integrität der zurückgelieferten Daten. Jede Zone wird mit einem kryptografischen Schlüssel signiert; Resolver prüfen die Kette bis zum Root‑Key. So ist ein „Gefälschte‑Antwort“-Angriff praktisch unmöglich, solange die Validierung aktiviert ist.

Praktisches Beispiel

Wir richten einen eigenen autoritativen Server mit BIND 9 ein und signieren die Zone myhome.lan. Schritt‑für‑Schritt:

  1. Zone‑Datei erstellen (/etc/bind/zones/myhome.lan.db): 
$TTL 86400
@   IN  SOA ns1.myhome.lan. admin.myhome.lan. (
        2026072601 ; serial
        3600       ; refresh
        1800       ; retry
        1209600    ; expire
        86400 )    ; minimum
    IN  NS  ns1.myhome.lan.
ns1 IN  A   192.168.1.10
www IN  A   192.168.1.20
Enter fullscreen mode Exit fullscreen mode
  1. Schlüssel erzeugen (KSK und ZSK): 
cd /etc/bind/keys
dnssec-keygen -a RSASHA256 -b 2048 -r /dev/urandom -n ZONE myhome.lan
dnssec-keygen -f KSK -a RSASHA256 -b 4096 -r /dev/urandom -n ZONE myhome.lan
Enter fullscreen mode Exit fullscreen mode

Die beiden generierten Dateien (Kmyhome.lan.+008+xxxxx.key und .private) werden später veröffentlicht.

  1. Zone signieren: 
dnssec-signzone -o myhome.lan -k Kmyhome.lan.+008+XXXXX.key /etc/bind/zones/myhome.lan.db
Enter fullscreen mode Exit fullscreen mode

Das Ergebnis ist myhome.lan.db.signed mit DNSSEC‑RRSIG‑Einträgen.

  1. BIND‑Konfiguration (named.conf.local): 
zone "myhome.lan" {
    type master;
    file "/etc/bind/zones/myhome.lan.db.signed";
    allow-update { none; };
};
Enter fullscreen mode Exit fullscreen mode
  1. Resolver‑Validierung aktivieren (z. B. systemd-resolved): 
sudo mkdir -p /etc/systemd/resolved.conf.d
cat <<EOF | sudo tee /etc/systemd/resolved.conf.d/dnssec.conf
[Resolve]
DNSSEC=yes
EOF
sudo systemctl restart systemd-resolved
Enter fullscreen mode Exit fullscreen mode

Ein Test mit dig zeigt, dass die Antwort nun ad (Authenticated Data) enthält:

dig @127.0.0.1 www.myhome.lan +dnssec
Enter fullscreen mode Exit fullscreen mode

Persönliche Einschätzung

DNSSEC ist die Einzige, die Sie vor gefälschten Antworten schützt. In meinen Projekten kombinieren wir DNSSEC im internen DNS mit DoT für die Upstream‑Verbindungen. Der übliche Haken ist das Schlüssel‑Roll‑Management – vergessene Schlüsselabläufe führen schnell zu Ausfällen. Daher setze ich automatisierte Schlüssel‑Rotation via rndc und ein Monitoring‑Alarm, das das Ablaufdatum prüft.

Gemeinsamer Einsatz – Welche Technik wann?

Merkmal DoT DoH DNSSEC
Vertraulichkeit ✓ (TLS) ✓ (HTTPS) –
Integrität – – ✓
Kompatibilität Kern‑Linux, Server‑Daemons Browser, mobile Apps Jeder Resolver
Performance Geringe Latenz (persistent TLS) Etwas höher (HTTPS‑Handshake) Keine Auswirkung
Einrichtungsaufwand gering (stubby/cloudflared) mittel (systemd‑resolved, cloudflared) hoch (Zone‑Signing, Schlüssel‑Management)

Empfehlung: Für Workstations und Laptops ist DoH die bequemste Lösung, weil moderne Browser es nativ unterstützen. In Server‑Umgebungen, wo mehrere Services denselben Resolver teilen, setze ich DoT, weil es keine zusätzlichen HTTP‑Header erfordert und leicht über systemd-resolved konfigurierbar ist. DNSSEC sollte immer aktiv sein – es ist kein optionales Feature, sondern ein Grundschutz.

Häufige Fehler und wie Sie sie vermeiden

  1. Resolver prüft DNSSEC nicht – Viele Distributionen deaktivieren die Validierung aus Gründen der Kompatibilität. Prüfen Sie mit dig +dnssec example.com das Vorhandensein des ad‑Flags. Wenn es fehlt, aktivieren Sie DNSSEC=yes in systemd-resolved oder options dnssec in named.conf.
  2. Upstream‑Server blockieren TLS/HTTPS – In Unternehmensnetzen blockieren Firewalls manchmal Port 853 oder verschlüsselte SNI‑Domain‑Namen. Nutzen Sie tcpdump -i eth0 -n port 853 um zu prüfen, ob die Pakete überhaupt das Netzwerk verlassen.
  3. Verwechslung von DoT‑Port und regulärem DNS‑Port – Wenn Sie stubby nutzen, vergessen Sie nicht, den lokalen Port‑Umleitungsdienst (z. B. iptables -t nat -A OUTPUT -p udp --dport 53 -j REDIRECT --to-ports 53) zu entfernen, sonst gehen Anfragen an den falschen Daemon.
  4. Ungepflegte Schlüssel in DNSSEC – Ein abgelaufener ZSK bricht die gesamte Kette. Ein Cron‑Job, der dnssec-signzone -u ausführt und das Ergebnis prüft, verhindert Überraschungen.
  5. Cache‑Inkompatibilitäten – Durch DoH kann der lokale DNS‑Cache (z. B. nscd) veraltete, nicht‑signierte Antworten behalten. Leeren Sie den Cache nach einer DoH‑Einführung (sudo systemctl restart nscd).

Fazit und der nächste konkrete Schritt

  • DoT ist ideal für serverseitige, persistent‑verbindende Umgebungen. Richten Sie stubby oder systemd-resolved mit DNSOverTLS=yes ein.
  • DoH passt zu Desktop‑ und Mobilgeräten, weil es über Port 443 läuft und von Browsern unterstützt wird. Deployen Sie cloudflared als lokales Proxy.
  • DNSSEC ist das unverzichtbare Gegenstück, das die Authentizität Ihrer Antworten garantiert. Signieren Sie Ihre eigenen Zonen und aktivieren Sie Validierung im Resolver.

Ihr nächster Schritt:

  1. Wählen Sie ein DoT‑ oder DoH‑Setup, das zu Ihrer Infrastruktur passt (Beispiel: sudo apt install stubby && sudo systemctl enable --now stubby).
  2. Testen Sie die Konfiguration mit dig +tls bzw. dig +https.
  3. Schalten Sie DNSSEC‑Validierung in Ihrem Resolver ein und prüfen Sie dig +dnssec.
  4. Implementieren Sie ein Monitoring‑Alert (z. B. Prometheus + node_exporter) für TLS‑Handshake‑Fehler und DNSSEC‑Key‑Ablauf.

Damit ist Ihr DNS‑Stack nicht nur verschlüsselt, sondern auch authentifiziert – das Fundament einer sicheren Netzwerkarchitektur.

Top comments (0)