DNS Architecture Review

DNS ist in den meisten Unternehmen historisch gewachsen. Es gibt einen Router, der irgendwann DHCP-Leases ausgeteilt hat. Irgendwann kam ein Windows Server mit Active Directory. Irgendwann hat der Hoster die Zone übernommen. Irgendwann hat jemand 8.8.8.8 als Resolver eingetragen, weil etwas nicht funktioniert hat. Das Ergebnis ist eine DNS-Infrastruktur, die niemand vollständig überblickt – und die bei einem Vorfall niemand sicher beurteilen kann.

Der DNS Architecture Review schafft diesen Überblick. Wir analysieren, wie DNS bei Ihnen tatsächlich aufgebaut ist – intern und extern – und dokumentieren die Architektur so, dass sie als Arbeits- und Nachweisdokument im Tagesbetrieb tatsächlich verwendet werden kann.

Haben interne Clients einen eigenen Resolver oder fragen sie direkt öffentliche DNS-Server? Gibt es eine saubere Trennung zwischen interner Zone (z.B. corp.example.de) und öffentlicher Zone (example.de)? In Active-Directory-Umgebungen ist die DNS-Integration mit dem Domain Controller eine häufige Fehlerquelle: konkurrierenden Resolvern, falsch konfigurierten Zonen und unkontrollierten Weiterleitungen begegnen wir in vielen Projekten.

Wir dokumentieren den Ist-Zustand und bewerten, ob die interne DNS-Konfiguration sicherheits- und betriebstechnisch tragfähig ist.

Welcher Resolver wird für ausgehende Anfragen genutzt – ISP-Resolver, Public DNS oder ein eigener Forwarder? Wird DNSSEC-Validierung aktiv durchgeführt, und an welcher Stelle? Gibt es DNS-over-TLS oder DNS-over-HTTPS? Wer hat Zugriff auf Resolver-Logs, und werden sie überhaupt gespeichert?

Letzteres ist keine akademische Frage: DNS-Logs sind im Kontext von NIS2 und DORA eine wichtige Erkennungsquelle für Angriffe – C2-Traffic und DNS-Tunneling hinterlassen Spuren im Resolver-Log, die im SIEM sichtbar sein sollten.

Werden DHCP-Leases automatisch in DNS eingetragen (Dynamic DNS)? Wenn ja: Ist dieser Prozess abgesichert, oder kann jedes Gerät im Netz beliebige DNS-Einträge anlegen? In Active-Directory-Umgebungen ist unkontrolliertes DDNS ein verbreitetes und unterschätztes Angriffsszenario.

In MSP-Umgebungen kommt häufig hinzu, dass unklar ist, wer DHCP tatsächlich verwaltet – der Kunde, der MSP oder ein Router im Keller. Wir klären diese Verantwortlichkeiten und bewerten die technische Absicherung.

Wo liegen die autoritativen Nameserver für öffentliche Domains – beim Registrar, beim Hoster, selbst betrieben? Gibt es einen primären und einen sekundären Nameserver, der wirklich unabhängig ist? Sind Zonentransfers (AXFR/IXFR) auf autorisierte Sekundär-Nameserver beschränkt – oder sind sie offen?

Offene Zonentransfers sind ein häufiger und unterschätzter Befund: Sie geben Angreifern eine vollständige Liste aller internen Hostnamen und IP-Adressen. Wir prüfen die autoritative Infrastruktur auf Konsistenz, Redundanz und Zugriffsbeschränkungen.

Gibt es aktives Monitoring für DNS-Verfügbarkeit? Ist dokumentiert, wer für DNS-Incidents zuständig ist – intern, MSP oder Hoster? Wie lange würde es dauern, einen DNS-Ausfall zu bemerken? Gibt es einen dokumentierten Prozess für DNS-bezogene Vorfälle?

Diese Fragen wirken organisatorisch, haben aber direkte technische Konsequenzen: Ohne dokumentierte Zuständigkeiten und ohne Monitoring verlängert sich die Mean Time to Detect bei DNS-Vorfällen erheblich – mit direkten Auswirkungen auf Compliance-Nachweise nach NIS2 und DORA.

DNS-Infrastruktur ist in regulatorischen Rahmenwerken häufig implizit vorausgesetzt, aber selten explizit adressiert. Das führt dazu, dass DNS in Asset-Inventaren fehlt, in Risikoanalysen nicht auftaucht und in Incident-Plänen nicht berücksichtigt wird – obwohl DNS eine zentrale Verfügbarkeitskomponente jedes internetbasierten Dienstes ist. Die folgende Einordnung ist eine fachlich-technische Bewertung; sie ersetzt keine Rechtsberatung.

NIS2 verlangt von betroffenen Unternehmen ein vollständiges Bild ihrer Netz- und Informationssicherheit – inklusive der Abhängigkeiten von Dienstleistern und Infrastrukturanbietern (Art. 21 NIS2). DNS-Abhängigkeiten gehören dazu: vom Registrar, vom Hoster, vom Resolver-Betreiber. Unternehmen, die ihre DNS-Architektur nicht dokumentiert haben, können diese Abhängigkeiten nicht vollständig in ihrer Risikoanalyse abbilden. NIS2 verpflichtet zudem zu Maßnahmen zur Angriffserkennung; DNS-Logs sind – wenn sie existieren und ausgewertet werden – eine wertvolle Erkennungsquelle.

DORA fordert eine vollständige Erfassung aller kritischen IKT-Abhängigkeiten im Rahmen des IKT-Risikomanagements. DNS gehört dazu, fehlt aber in der Praxis in vielen ICT-Asset-Registries von Finanzunternehmen. DORA verlangt darüber hinaus die Definition von RTO für kritische Dienste und deren regelmäßige Überprüfung. Wer seine DNS-Architektur nicht kennt, kann keine belastbaren Aussagen über Ausfallwahrscheinlichkeiten und Wiederherstellungszeiten treffen.

Telekommunikationsunternehmen müssen nach §166 TKG Sicherheitskonzepte erstellen, die die Integrität und Verfügbarkeit ihrer Netze dokumentieren und schützen. DNS ist für TKG-verpflichtete Unternehmen keine periphere Infrastruktur, sondern ein Kernelement der Netzkommunikation. Eine strukturierte DNS-Architekturdokumentation – intern, extern, autoritativ, rekursiv – ist eine sinnvolle Grundlage für ein belastbares TKG-Sicherheitskonzept.

Hersteller vernetzter Produkte, die DNS für Dienste, Updates oder Telemetrie nutzen, müssen diese Abhängigkeiten im Rahmen von Security by Design dokumentieren und bewerten. Ein Produkt, das auf externe DNS-Dienste angewiesen ist, ohne diese Abhängigkeit zu kennen oder zu überwachen, wird den CRA-Anforderungen nur eingeschränkt gerecht. Der DNS Architecture Review identifiziert diese Abhängigkeiten systematisch.

1. Erstgespräch – Scope, Netzwerkumgebung und Zielinfrastruktur klären. Kostenlos, ca. 30–45 Minuten, remote.

2. Strukturierte Erhebung – Wir arbeiten mit einem erprobten Fragebogen und ergänzenden technischen Abfragen. Je nach Umfang remote oder hybrid (z.B. ein halber Tag vor Ort). Ein vollständiger Systemzugriff ist nicht erforderlich.

3. Architekturdokumentation – Strukturierte Dokumentation Ihrer DNS-Architektur: internes DNS, externes DNS, Resolver-Konfiguration, DHCP-Integration, autoritative Infrastruktur, Zuständigkeiten. Format: verwendbares Arbeits- und Nachweisdokument, kein Präsentationsdeck.

4. Maßnahmenkatalog – Priorisierte Liste der identifizierten Schwachstellen und Handlungsempfehlungen, eingeteilt nach Kritikalität und Umsetzungsaufwand.

5. Ergebnisbesprechung – Gemeinsame Durchsprache der Dokumentation und des Maßnahmenkatalogs. Remote oder vor Ort, ca. 90 Minuten.