DNS-Sicherheit - Definition & Erklärung

DNS ist das Telefonbuch des Internets - und gleichzeitig eines der meistmissbrauchten Protokolle für Angriffe. DNS-Tunneling für Command & Control, DNS-Hijacking für Phishing, DNS-Amplification für DDoS: Wer DNS kontrolliert, kontrolliert den Netzwerkverkehr. Wer DNS überwacht, erkennt fast jeden Angriff.

Warum DNS ein Sicherheitsproblem ist

DNS wurde 1983 ohne jegliche Sicherheitsmechanismen entworfen. Das Protokoll kennt weder Verschlüsselung (alles läuft im Klartext) noch Authentifizierung (jeder kann Antworten liefern) noch Integritätsschutz (Antworten können manipuliert werden).

Die praktischen Konsequenzen dieser Designentscheidungen sind erheblich:

DNS-Antworten können gefälscht werden (Cache Poisoning)
DNS-Traffic wird von ISPs, Behörden und Angreifern überwacht
DNS wird für Command-and-Control-Kommunikation von Malware missbraucht
DNS kann als DDoS-Amplifier eingesetzt werden

DNS ist dabei allgegenwärtig: Fast jede Netzwerkkommunikation beginnt mit einem DNS-Lookup - auch Malware, die ihren C2-Server via DNS auflöst, und auch Phishing-Domains. Damit sind DNS-Logs eine Goldgrube für die Threat Detection.

DNSSEC - DNS-Authentifizierung

DNSSEC (DNS Security Extensions) fügt kryptografische Signaturen zu DNS-Records hinzu. Der Zone-Inhaber signiert DNS-Records mit einem privaten Schlüssel, der Resolver prüft die Signatur mit dem öffentlichen Schlüssel, und die Signaturkette verläuft von der Root-Zone über TLD (.de) bis zur Domain und ihren Subdomains. Wenn die Signatur ungültig ist, wird die Antwort verworfen.

Was DNSSEC schützt - und was nicht

DNSSEC schützt…	DNSSEC schützt NICHT…
Cache Poisoning: gefälschte DNS-Antworten werden erkannt	Privatsphäre: Anfragen bleiben im Klartext
Man-in-the-Middle: Manipulation der DNS-Antwort erkennbar	DDoS: DNSSEC-Antworten sind größer → Amplification
DNS-Hijacking (teilweise): Zone-Records authentifiziert	Den DNS-Resolver selbst

DNSSEC-Status prüfen

# DNSSEC-Antwort prüfen:
dig +dnssec a7.de
# → RRSIG Record vorhanden → DNSSEC aktiv
# → AD Flag in Response → Resolver hat validiert

# Test ob DNSSEC-Validierung aktiv ist:
dig sigfail.verteiltesysteme.net +dnssec
# → SERVFAIL = DNSSEC-Validierung funktioniert korrekt

Wichtig: Rund 83% der deutschen Domains haben kein DNSSEC (Stand 2024). DNSSEC sollte dringend beim Registrar aktiviert werden.

DNS over HTTPS (DoH) und DNS over TLS (DoT)

Das Problem mit klassischem DNS

UDP-Port 53 überträgt DNS-Traffic unverschlüsselt. ISPs können alle DNS-Anfragen sehen. In öffentlichen WLANs ist DNS-Manipulation durch einen Angreifer im Netz trivial möglich. Diese Lücke schließen die verschlüsselten DNS-Protokolle.

DNS over TLS (DoT)

DoT nutzt Port 853 (TCP) mit TLS-Verschlüsselung für DNS-Traffic. Es eignet sich gut für die Kommunikation von Clients mit dem internen Resolver und wird von Android 9+, Windows 11 und Linux unterstützt. Der Nachteil: Ein eigener Port macht DoT für Firewalls einfach filterbar.

DNS over HTTPS (DoH)

DoH nutzt Port 443 (HTTPS) und versendet DNS-Anfragen über HTTP/2 oder HTTP/3. Da der Traffic nicht von normalem HTTPS-Traffic zu unterscheiden ist, lässt er sich kaum blocken. Darin liegt aber auch der Nachteil: Unternehmen haben Schwierigkeiten, DoH im Browser zu kontrollieren. DoH wird von Firefox, Chrome, Windows und Android unterstützt.

Für Unternehmen: DoH im Browser unterbinden

DoH in Browsern umgeht den internen DNS-Resolver des Unternehmens und damit alle DNS-basierten Sicherheitsmaßnahmen. Die Gegenmaßnahmen:

Firefox DoH-Policy via GPO oder MDM deaktivieren
Chrome DoH-Policy via GPO steuern
Einen eigenen DoH/DoT-Resolver betreiben, auf den alle Clients zeigen

Ein eigener DoH-Resolver lässt sich z.B. mit Unbound und nginx aufbauen: Unbound dient als rekursiver Resolver, nginx stellt einen HTTPS-Proxy mit /dns-query-Endpoint bereit. Alle Anfragen laufen über den kontrollierten Resolver - Filtering, Logging und Security bleiben vollständig möglich.

DNS over QUIC (DoQ)

Das neueste DNS-Protokoll (RFC 9250, 2022) nutzt QUIC statt TCP/UDP und ist dadurch schneller und moderner. Die Verbreitung ist noch gering.

DNS-Sicherheitslösungen für Unternehmen

1. Protective DNS / DNS-Filtering

Das Grundprinzip: Bösartige Domains blocken, bevor eine Verbindung hergestellt wird. Bekannte C2-Server-Domains, gemeldete Phishing-Sites, Malvertising und Botnet-C2 werden in Blocklisten erfasst und auf DNS-Ebene gesperrt.

Kommerzielle Lösungen:

Anbieter	Besonderheit
Cisco Umbrella	Cloud-basiert, globales Threat Intelligence
Palo Alto DNS Security	Integration in NGFW
Cloudflare Gateway	Kostenlose Basis-Version (1.1.1.2)
NextDNS	Consumer + Business, sehr konfigurierbar

Open Source / kostengünstige Optionen:

Pi-hole mit Blocklists (für kleine Netze)
BIND RPZ (Response Policy Zones): eigene Blocklists auf BIND-Server
Unbound mit Blocklists

Das BSI empfiehlt DNS-Filtering als eine der kosteneffizientesten Sicherheitsmaßnahmen - es blockt 70-80% aller Malware-Verbindungen.

2. DNS-Monitoring und Threat Detection

Der DNS-Traffic sollte auf folgende Anomalien überwacht werden:

Domains, die kurz nach ihrer Registrierung angefragt werden (DGA-Hinweis)
Sehr lange Subdomains (DNS-Tunneling: aGVsbG8gd29ybGQ.evil.com)
Ungewöhnliche DNS-Record-Typen (TXT, NULL)
Bekannte DGA-Muster (Conficker, GameOver Zeus)
NXDOMAIN-Fluten: viele Non-Existente Domains von einem Host

SIEM-Regeln für DNS-Anomalien:

# Verdächtig: Subdomain länger als 50 Zeichen
DNS_QUERY | WHERE length(subdomain) > 50
         | WHERE NOT whitelist_domain(fqdn)
         → Alert: "Mögliches DNS-Tunneling"

# Verdächtig: Viele NXDOMAIN-Antworten
DNS_RESPONSE | WHERE response_code = "NXDOMAIN"
             | stats count by src_ip
             | WHERE count > 100 IN last 10min
             → Alert: "Mögliche Malware-Aktivität (DGA)"

DNS-Tunneling - Angreifer-Perspektive

DNS-Tunneling nutzt DNS für versteckte Kommunikation. DNS-Traffic wird selten geblockt (funktioniert auch hinter restriktiven Firewalls), selten überwacht, und UDP/TCP-Port 53 ist nahezu überall offen.

Wie DNS-Tunneling funktioniert

Der Angreifer kontrolliert den DNS-Server für boese-domain.com
Auf dem kompromittierten Host läuft ein DNS-Tunneling-Tool (iodine, dnscat2)
Daten werden Base64-codiert als Subdomain in DNS-Anfragen versteckt: aGVsbG8gd29ybGQ.boese-domain.com
Der böse DNS-Server dekodiert die Anfragen und antwortet via DNS-Response
Kompletter C2-Traffic läuft über DNS - für normale Netzwerkmonitoring-Tools unsichtbar

Erkennungsmerkmale von DNS-Tunneling

Sehr lange Subdomains (mehr als 50 Zeichen)
Viele unterschiedliche Subdomains derselben Domain
Ungewöhnliche DNS-Record-Typen (TXT, NULL, CNAME-Ketten)
Hohe DNS-Anfragerate von einem einzelnen Host
Ungewöhnlich hohe Datenmenge über DNS (normal unter 1 KB/s, Tunnel deutlich mehr)

Bekannte Tools (auch für Pentests):

iodine: IPv4-over-DNS
dnscat2: C2 over DNS
DNSExfiltrator: Daten-Exfiltration via DNS TXT-Records

DNS-Konfiguration-Checkliste

Resolver-Konfiguration

Kein offener Resolver (nur interne Clients dürfen anfragen)
Rekursion nur für interne Netze erlauben
Rate Limiting gegen Amplification-Attacks konfigurieren
DNSSEC-Validierung aktivieren (auf dem internen Resolver)
Logging aller Anfragen aktivieren und an SIEM weiterleiten

Public DNS Records

SPF-Record vorhanden (E-Mail-Spoofing verhindern)
DMARC-Record mit “reject”-Policy
DKIM-Record für alle verwendeten Mail-Services
MX-Record nur wenn E-Mail aktiv genutzt wird
DNSSEC für eigene Domain beim Registrar aktiviert
CAA-Record: nur bestimmte CAs dürfen Zertifikate ausstellen
TLSA-Record (DANE): Zertifikat via DNS verankern

Monitoring

DNS-Logs an SIEM weiterleiten (alle Anfragen)
Alerting bei langen Subdomains (mehr als 50 Zeichen)
Alerting bei vielen NXDOMAIN-Antworten
Anomaliedetektion auf DNS-Traffic
Externen DNS-Monitor nutzen (BSI DNS-Check, dnsviz.net)