DEV Community

Uhltak Therestismysecret
Uhltak Therestismysecret

Posted on

DNS-Sicherheit verstehen: DoT, DoH und DNSSEC im Praxisvergleich

#dns #dot #doh #dnssec

Warum wir alle plötzlich über DNS reden – ein provokanter Einstieg

Stellen Sie sich vor, Sie geben bei einem Online-Shop Ihre Kreditkartendaten ein und plötzlich wird Ihr Geld an einen völlig anderen Empfänger überwiesen. Das war gestern, heute ist das DNS. Bei einem simplen ping example.com liegt das Rückgrat des Internets – das Domain Name System – im Hintergrund, und jeder Eingriff von außen kann Sie in den digitalen Abgrund stürzen. Deshalb reden inzwischen alle über DNS‑Sicherheit, doch die meisten kennen nur das Wort „VPN“. Wir gehen heute tiefer: DNS‑over‑TLS (DoT), DNS‑over‑HTTPS (DoH) und DNSSEC – drei unterschiedliche Schutzschichten, die Sie kennen sollten, um nicht das nächste Opfer zu werden.

1. Grundprinzipien: Was schützt was?

Erklärung

  • DoT verschlüsselt den gesamten DNS‑Query‑Channel über TLS. Der Client verbindet sich mit einem dedizierten Port 853 und fragt dort ab – ähnlich wie bei HTTPS, nur dass das Protokoll DNS bleibt.
  • DoH kapselt DNS‑Anfragen in reguläre HTTPS‑Requests (Port 443). Das hat den Vorteil, dass DNS‑Traffic durch Firewalls oder Deep‑Packet‑Inspection kaum zu unterscheiden ist.
  • DNSSEC ist kein „Verschlüsselungs‑Tool“, sondern ein Authentisierungs‑Mechanismus. Jeder DNS‑Eintrag wird kryptografisch signiert, so dass ein Angreifer nicht einfach einen gefälschten Eintrag einschleusen kann.

Beispiele & persönliche Bewertung

Technologie Ziel Was Sie wirklich schützt
DoT Vertraulichkeit & Integrität des Transportes Schutz vor MitM‑Abhören, aber nicht vor gefälschten Antworten, wenn der Resolver kompromittiert ist
DoH Vertraulichkeit + Tarnung Gleiches wie DoT, plus Unterscheidbarkeit für Netzwerk‑Tools eliminiert
DNSSEC Authentizität der Daten Schutz vor Cache‑Poisoning und Man‑in‑the‑Middle‑Manipulation, jedoch keine Verschlüsselung des Kanals

Mein Fazit: Wenn Sie nur verhindern wollen, dass jemand Ihren DNS‑Traffic ausspioniert, reicht DoT/DoH. Wenn Sie jedoch sicherstellen wollen, dass die zurückgelieferten IP‑Adressen echt sind – zum Beispiel im Unternehmensnetz, das kritische Services hostet – brauchen Sie DNSSEC.

2. DoT in der Praxis – Konfiguration und Test

Erklärung

DoT erfordert einen DNS‑Resolver, der TLS unterstützt (z. B. Unbound 1.14+, Knot Resolver oder Bind 9.16+). Der Client muss wissen, welchen Server er ansprechen soll. Unter Linux ist das meist systemd-resolved oder stubby.

Beispiel 1 – Stubby installieren & konfigurieren 

# Auf Debian/Ubuntu
sudo apt-get update && sudo apt-get install stubby
Enter fullscreen mode Exit fullscreen mode

/etc/stubby/stubby.yml anpassen (Ausschnitt):

resolution_type: GETTLS

upstream_recursive_servers:
  - address_data: 1.1.1.1
    tls_auth_name: "cloudflare-dns.com"
    tls_port: 853
  - address_data: 9.9.9.9
    tls_auth_name: "dns.quad9.net"
    tls_port: 853
Enter fullscreen mode Exit fullscreen mode

Die Datei speichert die TLS‑Authentifizierung (Server‑Name‑Indication) und den Port 853. Dann:

sudo systemctl restart stubby
sudo resolvectl dns $(ip route get 1.1.1.1 | awk '{print $5}') 127.0.0.1#53
Enter fullscreen mode Exit fullscreen mode

Jetzt nutzt das System DoT über Stubby. Einen schnellen Test führt man mit dig aus:

DIG +tls +short @127.0.0.1 example.com
Enter fullscreen mode Exit fullscreen mode

Wenn die Ausgabe eine IP‑Adresse liefert, funktioniert DoT.

Meine Einschätzung

DoT ist einfach zu implementieren, weil Sie lediglich den Resolver umstellen. Der Knackpunkt ist die Auswahl eines vertrauenswürdigen TLS‑Resolver‑Pools – ein schlechter Resolver kann Sie wieder in die Irre führen.

3. DoH in der Praxis – Curl & Browser‑Integration

Erklärung

DoH nutzt das HTTPS‑Protokoll, deshalb kann jeder Browser (Firefox, Chrome) oder jedes Tool, das HTTP‑Requests senden kann, als DNS‑Resolver agieren. Ziel ist, DNS‑Traffic in normalen Web‑Traffic zu verstecken.

Beispiel 2 – DoH mit curl testen 

# Anfrage an Cloudflare's DoH‑Endpoint
curl -H "accept: application/dns-json" "https://cloudflare-dns.com/dns-query?name=example.com&type=A" | jq .Answer[0].data
Enter fullscreen mode Exit fullscreen mode

Ergebnis: 93.184.216.34. Dabei sehen Sie, dass die Antwort im JSON‑Format zurückkommt.

Beispiel 3 – Firefox DoH aktivieren

  1. about:config öffnen.
  2. network.trr.uri auf https://dns.google/dns-query setzen.
  3. network.trr.mode auf 2 (strict) setzen.
  4. Browser neu starten.

Jetzt leitet Firefox alle DNS‑Auflösungen über DoH an Googles Resolver.

Meine Einschätzung

DoH ist unsichtbar, das ist sowohl Vor- als auch Nachteil. Unternehmen verlieren die Möglichkeit, DNS‑Abfragen zu protokollieren, weil sie jetzt im HTTPS‑Traffic verborgen sind. Für Privatanwender ist das ein großer Datenschutz‑Boost, für Admins ein neues Rätsel.

4. DNSSEC – Authentizität auf DNS‑Ebene sichern

Erklärung

DNSSEC erweitert jede Zone um digitale Signaturen. Der Prozess besteht aus:

  1. Schlüsselgenerierung (KSK – Key Signing Key, ZSK – Zone Signing Key).
  2. Signieren der Zone (dnssec-signzone).
  3. Publizieren der Schlüssel im Parent‑Domain‑Eintrag (z. B. bei example.com im com‑TLD‑Zone‑File).

Beispiel 4 – BIND‑9 mit DNSSEC einrichten 

# 1. Schlüssel erzeugen
cd /etc/bind
dnssec-keygen -a RSASHA256 -b 2048 -n ZONE example.com
# -> Kexample.com.+007+12345.key & .private

# 2. Zone signieren
dnssec-signzone -o example.com -k Kexample.com.+007+12345.key db.example.com
# Ergebnis: db.example.com.signed
Enter fullscreen mode Exit fullscreen mode

In named.conf.local einbinden:

zone "example.com" {
    type master;
    file "/etc/bind/db.example.com.signed";
    allow-update { none; };
};
Enter fullscreen mode Exit fullscreen mode

Starten Sie BIND neu:

sudo systemctl restart bind9
Enter fullscreen mode Exit fullscreen mode

Beispiel 5 – Überprüfen mit dig 

# DNSSEC‑Abfrage
dig +dnssec example.com RRSIG
Enter fullscreen mode Exit fullscreen mode

Wenn Sie ein RRSIG‑Record sehen, ist DNSSEC aktiv. Zusätzlich prüfen Sie die Kette mit dig +trace +dnssec example.com – hier sollten Sie keine SERVFAIL‑Meldung erhalten.

Meine Einschätzung

DNSSEC ist nicht optional, wenn Sie kritische Infrastrukturen betreiben. Der Aufwand ist zwar höher – Schlüsselrotation, DS‑Eintrag beim Registrar – aber das Sicherheits‑ROI ist enorm: Keine Cache‑Poisoning‑Angriffe mehr, weil jede Antwort kryptografisch verifiziert wird.

5. Häufige Fehler und Stolperfallen

Fehler Warum er kritisch ist Gegenmaßnahme
Kein Trusted Resolver – Nutzung eines öffentlichen DoT‑Servers ohne Zertifikatsüberprüfung Man kann leicht einen Man‑in‑the‑Middle einführen, wenn der TLS‑Handshake nicht verifiziert wird. Verwenden Sie tls_auth_name und prüfen Sie das Server‑Zertifikat (Fingerprints).
DoH im Browser, aber lokaler Resolver aktiv – Dual‑Stack führt zu unerwarteten Caches Der Browser ignoriert lokale Policies, weil er direkt DoH nutzt. Deaktivieren Sie DoH im Browser oder konfigurieren Sie den lokalen Resolver, um DoH‑Upstream‑Server zu nutzen.
DNSSEC‑Key‑Verwaltung vernachlässigt – Schlüssel laufen ab, DS‑Eintrag nicht aktualisiert Bei abgelaufenen Schlüsseln liefert der Resolver SERVFAIL. Automatisieren Sie Schlüsselrotation mit dnssec-keymgr oder rndc‑Skripten.
Keine Monitoring‑Logs für DNS – Man sieht Angriffe erst nach dem Schaden DNS‑Abfragen werden selten geloggt, besonders bei DoH. Nutzen Sie systemd-resolved‑Logging (journalctl -u systemd-resolved) und setzen Sie log‑queries in Unbound.

6. Fazit & konkreter nächster Schritt

Wir haben gesehen, dass DoT und DoH den Transport schützen, DNSSEC aber die Daten selbst. Kein einzelnes Tool löst alle Probleme – ein Defense‑in‑Depth‑Ansatz ist nötig:

  1. DoT für interne Systeme (z. B. über stubby oder unbound).
  2. DoH für End‑User‑Devices, wenn Sie das Risiko von Netzwerk‑Filtern minimieren wollen.
  3. DNSSEC für jede produktive Zone, insbesondere für Unternehmens‑ und Cloud‑Domänen.

Konkreter nächster Schritt für Sie

Kurz: Installieren Sie heute stubby, konfigurieren Sie Ihren Resolver auf TLS 853 und prüfen Sie mit dig +tls. Danach aktivieren Sie DNSSEC für Ihre interne Zone und testen Sie mit dig +dnssec.

Durch diese drei Maßnahmen erhöhen Sie sofort die Vertraulichkeit, Integrität und Authentizität Ihrer DNS‑Infrastruktur – und verhindern, dass ein einfacher „DNS‑Poisoning‑Attacke“ Ihr Unternehmen teuer zu stehen kommt.

Bleiben Sie neugierig: DNS‑Sicherheit ist ein sich schnell entwickelndes Feld. Schauen Sie regelmäßig in die Release‑Notes von Unbound, BIND und den großen DoH‑Anbietern. Und vergessen Sie nie: Das schönste Tool ist das, das Sie täglich einsetzen und kontinuierlich überprüfen.

Top comments (0)