# DNS Security: Den Vertrauensanker im Web sichern

TL;DR / Management Summary DNS ist eines der ältesten und unsichersten Protokolle des Internets (Standard: Port 53 UDP, unverschlüsselt). Ein Senior Admin weiß, dass DNS-Antworten manipuliert (Spoofing) oder mitgelesen werden können. In diesem Modul implementieren wir moderne Schutzmaßnahmen: DNSSEC zur Verifizierung der Antwort-Integrität, sowie DNS-over-TLS (DoT) und DNS-over-HTTPS (DoH) zur Verschlüsselung der Anfragen. Wir machen den DNS-Resolver zum “Private Investigator”, dem niemand etwas vormachen kann.

# 1. Einführung & Architektur

Die Bedrohungen: Hijacking & Sniffing.

1. DNSSEC: Signiert DNS-Zonen kryptografisch. Stellt sicher, dass die IP, die Sie erhalten, wirklich vom Inhaber der Domain stammt.
2. DoT / DoH: Verschlüsselt den Weg vom Client zum Resolver. Verhindert, dass ISPs oder Angreifer im WLAN sehen, welche Webseiten Sie aufrufen.

# Die Architektur-Optionen (Mermaid)

graph TD
    A[Linux Host] --> B{Resolver Strategy}
    B -->|Classic| C[UDP 53: Unencrypted]
    B -->|Privacy| D[DoT Port 853: TLS Tunnel]
    B -->|Stealth| E[DoH Port 443: HTTPS]
    D/E --> F[Privacy DNS: Quad9 / Cloudflare / AdGuard]
    C --> G[Standard ISP DNS]
    F -->|Verify| H[DNSSEC Validation]

# 2. DNS-over-TLS mit systemd-resolved

Verschlüsselung leicht gemacht.

In modernen Systemen (Arch, Ubuntu, SLES) kann der Standard-Resolver DoT nativ.

Datei: /etc/systemd/resolved.conf

[Resolve]
DNS=9.9.9.9#dns.quad9.net
DNSOverTLS=yes
DNSSEC=yes
FallbackDNS=1.1.1.1#cloudflare-dns.com

• #dns.quad9.net: Der Hostname ist für das Zertifikats-Matching bei TLS zwingend nötig.

# 3. Der eigene Security-Resolver: Unbound

Maximale Kontrolle.

In Enterprise-Umgebungen setzen wir oft Unbound als lokalen, validierenden Resolver ein.

# Installation & Hardening

sudo apt install unbound # Debian
sudo dnf install unbound # RHEL

Datei: /etc/unbound/unbound.conf

server:
    # Nur auf localhost lauschen
    interface: 127.0.0.1
    # DNSSEC Validierung aktivieren
    auto-trust-anchor-file: "/var/lib/unbound/root.key"
    # Schutz vor Cache Poisoning
    harden-glue: yes
    harden-dnssec-stripped: yes
    # Privatsphäre
    qname-minimisation: yes

# 4. Day-2 Operations: Validierung der Kette

Wissen, dass es funktioniert.

# DNSSEC Test

Nutzen Sie delv (Domain Entity Lookup & Validation):

delv @127.0.0.1 google.com
# Achten Sie auf den String: "; fully validated"

# TLS Check

Prüfen Sie mit tcpdump, ob noch Pakete auf Port 53 (unverschlüsselt) das System verlassen:

sudo tcpdump -i eth0 port 53
# Wenn DoT aktiv ist, sollte hier im Idealfall Stille herrschen.

# 5. Troubleshooting & “War Stories”

Wenn die Sicherheit den Zugriff blockiert.

# Story 1: “Der Time-Drift Blackout”

Symptom: Plötzlich lassen sich keine Webseiten mehr aufrufen. dig liefert SERVFAIL. Ursache: Die Systemzeit des Servers ist falsch. Da DNSSEC-Signaturen einen Zeitstempel haben, werden sie als ungültig verworfen, wenn die lokale Uhr zu weit abweicht. Lösung: NTP fixen (Artikel 334). Ohne korrekte Zeit bricht DNSSEC das gesamte Internet des Servers.

# Story 2: “Das Captive Portal Dilemma”

Symptom: Ein Admin-Laptop mit erzwungenem DoH/DoT verbindet sich im Hotel-WLAN, aber kein Internet geht. Ursache: Das Hotel-WLAN muss den User erst auf eine Login-Seite leiten. Da der Browser nur verschlüsseltes DNS zu einem globalen Server versucht, der lokale Hotel-DNS-Server (der den Redirect macht) aber ignoriert wird, schlägt die Umleitung fehl. Lösung: Nutzen Sie DNSOverTLS=opportunistic für mobile Geräte, um in unverschlüsselte Netze zurückzufallen, bis der Login erfolgt ist.

# 6. Fazit & Empfehlung

• Zentralisierung: Nutzen Sie in großen Netzen einen zentralen, gehärteten Unbound-Cluster.
• Privacy: Aktivieren Sie DoT auf jedem Server. Es verhindert, dass Metadaten über Ihre Infrastruktur im Netz “lecken”.
• Wahl: Quad9 (9.9.9.9) ist oft die beste Wahl für Admins, da es bösartige Domains bereits auf DNS-Ebene filtert.

# Anhang: Cheatsheet