Die Namensauflösung und die Kontrolle der TCP-Ports sind zwei Säulen der Netzwerksicherheitspolitik. Seit dem Inkrafttreten der europäischen Durchführungsverordnung 2024/2690 am 1. Juli 2025 unterliegen DNS-Anbieter, Top-Level-Domain-Registries und Cloud-Dienste spezifischen technischen Anforderungen. Dieser regulatorische Rahmen verändert konkret, wie Netzwerkteams die DNS-Filterung und die Governance der TCP-Ströme angehen müssen.
Verschlüsseltes DNS und Verlust der Netzsichtbarkeit: ein unterschätzter blinder Fleck
DNS über HTTPS (DoH), DNS über TLS (DoT) und DNS über QUIC schützen die Vertraulichkeit der Anfragen zwischen dem Client und dem Resolver. Dieser Schutz hat jedoch einen Nachteil: Wenn ein Browser oder ein Betriebssystem einen externen Resolver verwendet, der nicht von der Organisation kontrolliert wird, werden die internen Filterrichtlinien unwirksam.
Das Problem beschränkt sich nicht nur auf das Umgehen von Sperrlisten. Ein externer Resolver kann auch die Erkennung von Datenexfiltration durch DNS-Tunneling verhindern, einer Technik, die Informationen in den Anfragen selbst kodiert. Ohne Sichtbarkeit über diese Ströme verlieren Sicherheitsteams eine Erkennungsfähigkeit, die auf der Analyse des unverschlüsselten DNS-Verkehrs über Port 53 basierte.
Um diese Sichtbarkeit zu erhalten, muss die verschlüsselte Auflösung zu einem internen, DoH- oder DoT-kompatiblen Resolver zentralisiert werden. Die Sicherheitsressourcen auf Open Syd erläutern die damit verbundenen Härtungsmechanismen. Die Filterung auf Firewall-Ebene muss dann ausgehende DNS-Anfragen an nicht autorisierte Drittanbieter-Resolver blockieren, auch über den von DoH verwendeten Port 443.
TCP-Ports und DNS-Filterung: eine kohärente Kontrollpolitik aufbauen
DNS verwendet hauptsächlich den UDP-Port 53 für Standardanfragen. Wenn die Antwort die maximale Größe eines UDP-Datagramms (512 Byte standardmäßig) überschreitet, signalisiert der Server eine Trunkierung, und der Client wechselt auf den TCP-Port 53, um die vollständige Antwort zu erhalten. Die Zonentransfers zwischen DNS-Servern verwenden ebenfalls TCP 53.
Diese Dualität von UDP/TCP schafft eine spezifische Angriffsfläche. Das ungefilterte Blockieren von TCP 53 kann die Auflösung bestimmter großer Einträge (DNSSEC, lange TXT-Einträge) unterbrechen. Andererseits erleichtert das Offenlassen von TCP 53 ohne Einschränkungen das DNS-Tunneling und nicht autorisierte Zonentransfers.
Kriterien für eine geeignete Netzwerkfilterung
- TCP 53 nur zwischen internen DNS-Servern und identifizierten upstream-Resolvern zulassen, niemals direkt von Arbeitsplätzen
- Die ephemeral Quellports (Bereich 49152-65535 gemäß IANA-Empfehlungen) nur für legitime DNS-Auflösungsprozesse über Anwendungsfirewall-Regeln einschränken
- Ungewöhnliche Volumina an ausgehenden DNS-Anfragen überwachen, ein klassischer Indikator für Tunneling oder Kommunikation mit einem Command-and-Control-Server (C2)
- DNS-Anfragen auf dem internen Resolver protokollieren, um das SIEM zu speisen, was den Verlust der Sichtbarkeit aufgrund der End-to-End-Verschlüsselung ausgleicht
Die Filterung nur nach Port reicht nicht aus. Die Kombination aus Portkontrolle und DNS-Inhaltsanalyse (Überprüfung der aufgelösten Domainnamen, Erkennung hoher Entropie in Subdomains) bietet einen robusteren Schutz gegen Umgehungstechniken.
NIS2-Pflichten: Was die Richtlinie für die DNS-Verwaltung ändert
Die NIS2-Richtlinie (Richtlinie (EU) 2022/2555) und ihre Durchführungsverordnung 2024/2690 führen operationale Verpflichtungen ein, die direkt die DNS-Infrastruktur der betroffenen Entitäten betreffen.
Im Falle eines Vorfalls, der die Verfügbarkeit oder Integrität des DNS-Dienstes beeinträchtigt, verlangt das Benachrichtigungssystem eine erste Warnung innerhalb von 24 Stunden, gefolgt von einer detaillierten Benachrichtigung innerhalb von 72 Stunden und einem abschließenden Bericht innerhalb eines Monats. Diese Fristen setzen eine schnelle Erkennungs- und Qualifikationsfähigkeit für DNS-Vorfälle voraus.
Die Verordnung umfasst auch die Sicherheit der Lieferkette, Kryptographie und Zugangskontrolle. Für einen Netzwerkadministrator bedeutet dies, dass die Wahl eines externen DNS-Resolvers (Cloud-Dienst, öffentlicher Resolver) eine Bewertung des Anbieters im Hinblick auf diese Kriterien beinhalten muss. Die Rückmeldungen aus der Praxis variieren diesbezüglich: Einige Organisationen sind der Meinung, dass große öffentliche Resolver eine überlegene Resilienz bieten, während andere der Ansicht sind, dass die Abhängigkeit von Dritten das regulatorische Risiko erhöht.
Netzwerksegmentierung und DNS: Die Angriffsfläche durch Routing reduzieren
Die Netzwerksegmentierung begrenzt die Ausbreitung einer Kompromittierung, aber ihre Interaktion mit DNS wird selten im Detail behandelt. Ein in VLANs segmentiertes Netzwerk mit einem einzigen DNS-Resolver für alle Segmente bietet einen Dreh- und Angelpunkt für einen Angreifer, der diesen Resolver kompromittiert.
Dedizierte DNS-Resolver pro Netzwerksegment bereitstellen reduziert dieses Risiko. Jeder Resolver löst nur die für das Segment erforderlichen Namen auf, und die Firewall-Regeln verbieten nicht autorisierte intersegmentale DNS-Anfragen. Dieser Ansatz erhöht den Verwaltungsaufwand, segmentiert jedoch effektiv seitliche Bewegungen.
Prüfpunkte für ein DNS-Audit
- Überprüfen, dass jedes Netzwerksegment über explizite Regeln verfügt, die den DNS-Verkehr zu bestimmten Zielen erlauben oder verweigern
- Sicherstellen, dass interne DNS-Einträge (private Zonen) nicht von Segmenten, die dem Internet ausgesetzt sind, zugänglich sind
- Kontrollieren, dass Zonentransfers (AXFR/IXFR) auf die autorisierten sekundären Server mit TSIG-Authentifizierung beschränkt sind
Die Verknüpfung zwischen DNS, TCP-Ports und Netzwerksegmentierung bildet ein kohärentes Ganzes, dessen jeder Bestandteil die Grenzen der anderen ausgleicht. Eine Portfilterung ohne DNS-Governance bleibt durchlässig, ebenso wie ein gesichertes DNS seine Wirksamkeit verliert, wenn das Netzwerk-Routing Umgehungen ermöglicht. Die NIS2-Richtlinie drängt Organisationen dazu, diese Verknüpfung zu formalisieren, aber die verfügbaren Daten erlauben noch keine Messung des tatsächlich erreichten Konformitätsniveaus der betroffenen Entitäten.
