DNS-Governance: Die vier Wege zum Scheitern von DNS-Umgebungen

Die meisten DNS-Umgebungen werden nicht verwaltet, sondern angesammelt. Einträge werden aus guten Gründen erstellt, die dahinterstehenden Projekte enden, und niemand prüft ab, was veröffentlicht wurde und was tatsächlich noch aktuell ist. Wer die Umgebung erbt, übernimmt jede einzelne Entscheidung von Menschen, die inzwischen weitergezogen sind – in der Regel ohne Dokumentation und ohne Möglichkeit zu erkennen, welche Einträge noch relevant sind.

Diese Ansammlung schlägt auf vier spezifische Arten fehl – jede mit eigener Ursache, eigenen Kosten und einem eigenen Erkennungsweg.

Jede dieser Arten beginnt auf dieselbe Weise: Jemand legt einen Eintrag aus gutem Grund an, das Projekt endet, und niemand gleicht später mehr ab, ob der Eintrag noch zur Realität passt.

Die meisten DNS-Umgebungen funktionieren wie ein Schrank, den niemand mehr öffnet. Alles befindet sich darin, die Tür ist geschlossen, und solange E-Mails zugestellt werden und die Webseite lädt, sieht niemand einen Grund nachzuschauen. Irgendwann braucht jemand etwas ganz Bestimmtes, öffnet die Tür – und entdeckt, was sich darin wirklich angesammelt hat.

Lange war das akzeptabel, da nichts auf das Gegenteil hindeutete. Die Frameworks, nach denen Sicherheitsteams ihre Arbeit messen, bauen auf Ergebnissen statt auf technischen Mechanismen auf. NIST CSF fragt, ob Sie Ihre Assets managen. NCSC CAF fragt, ob Sie Ihre Systeme verstehen. Keines benennt DNS-Einträge explizit als eigene Assetklasse mit eigenen Hygiene-Anforderungen – DNS-Governance blieb damit eine ungeschriebene Disziplin guter Teams, während alle anderen sie aufschoben.

Das hat sich in den letzten drei Jahren und durch vier Dokumente geändert, die meisten davon aus Europa. Die EU verfasste detaillierte technische Vorgaben für Organisationen, die DNS-Infrastruktur betreiben; ENISA machte daraus umsetzbare Leitlinien samt Beispielnachweisen und NIST überarbeitete zum ersten Mal seit 2013 seinen DNS Deployment Guide. Zusammen hoben sie DNS-Hygiene von einer still geltenden guten Praxis zu einem Bereich, für den man einen Nachweis vorlegen können muss.

Dieser Leitfaden beschreibt, was diese Dokumente tatsächlich verlangen, für wen sie gelten, die vier praktischen Ausfallwege in DNS-Umgebungen und ein fünfstufiges Modell, mit dem sich ein unübersichtlicher Bestand überhaupt führen lässt. Zielgruppe sind Teams, die große Domain-Portfolios über mehrere Registrare und Dienstleister hinweg erben, ohne dass sie diese Umgebung selbst aufgebaut haben.

Zwei der vier Scheitermuster wurden schon ausführlich behandelt – auf die entsprechenden Leitfäden wird hier verlinkt. Beginnen Sie mit Dangling DNS: Wie Sie Einträge vor Übernahme finden und reparieren für die Aussagen von OWASP und AWS über Einträge, die auf gelöschte Cloud-Ressourcen zeigen, und wie offene Zonentransfers Ihr internes Netzwerk offenlegen für einen praktischen Blick auf Zonen, die mit einer einzigen Abfrage ausgespäht wurden.

Zwei Aspekte dieser Abfolge lohnen das Herausheben. Erstens die Richtung: 2022 setzte die EU eine Verpflichtung. 2024 waren die technischen Anforderungen spezifiziert. 2025 veröffentlichte ENISA Beispiele für Nachweise. Regulierungsbehörden wechselten von „manage your risk“ zu „das ist die Anforderung und hier zeigen Sie die Erfüllung“. DNS wurde in jedem Schritt explizit benannt.

Zweitens ist bemerkenswert, dass NIST unabhängig davon dieselben Schlussfolgerungen zieht. SP 800-81r3 ist keine Reaktion auf NIS2, sondern das US-amerikanische Pendant nach 13 Jahren. Dass beide Prozesse auf unterschiedlichen Kontinenten binnen desselben Zeitfensters DNS-Hygiene als Schwerpunkt erkannten, spricht für das Problem – nicht gegen einzelne Regulatoren.

Genau hier werden die meisten Texte über NIS2 und DNS unsauber – dabei ist diese Unterscheidung entscheidend, wenn Sie die Pflichten Ihrer Organisation bestimmen wollen.

NIS2 ist eine Richtlinie, keine Verordnung. Sie wirkt durch die Umsetzungsgesetze der einzelnen Mitgliedstaaten, ohne Unternehmen europaweit direkt und einheitlich zu binden. Die Artikel 2 und 3 nennen 18 Sektoren samt Schwellenwerten für „wesentliche“ und „wichtige“ Einrichtungen – eingebaut sind aber Ausnahmen, und nationale Behörden können Unternehmen unabhängig von ihrer Größe in den Geltungsbereich einordnen. Die Anforderungen aus Artikel 21 sind ergebnisorientiert, DNS ist darin Teil der Netzwerksicherheit und Assetverwaltung, aber kein explizit genannter Punkt. In der Praxis hängt daher alles an der Ausgestaltung des jeweiligen Landesgesetzes – der Sektor- und Größenansatz liefert einen Startpunkt, aber nie eine endgültige Antwort.

Durchführungsverordnung 2024/2690 bindet eine konkrete Liste. Die detaillierten technischen Anforderungen richten sich an DNS-Dienstleister, TLD-Registries, Cloud-Computing-Provider, Rechenzentren, CDN-Anbieter, MSP, MSSP, Online-Marktplätze, Suchmaschinen und soziale Netzwerke sowie Trust Service Provider. Registrar werden nicht eigenständig im Anhang genannt, können aber im Rahmen der nationalen NIS2-Umsetzung trotzdem betroffen sein – das ist dann eine separate Rechtsgrundlage. Betreiben Sie als Unternehmen eigene Domains, gelten die Annex-Anforderungen nicht unmittelbar für Sie, binden jedoch höchstwahrscheinlich mehrere Ihrer Dienstleister. ENISAs technische Umsetzungshilfe ist der praktische Begleittext inklusive Mapping zu europäischen und internationalen Standards.

NIST SP 800-81r3 ist freiwillige Leitlinie und spricht alle an. Keine Pflicht, kein Geltungsbereich. Es ist ein nützlicher technischer Maßstab neben geltendem Recht, Verträgen und Branchenregelungen – und die Art von Dokument, das ein Auditor oder ein Sicherheitsfragebogen von Kunden gerne zitiert, weil es unabhängig von Sektor und Geografie gültig ist. NIST hat im Juli 2026 potenzielle Updates und Errata veröffentlicht – prüfen Sie die aktuelle Version, nicht eine zwischengespeicherte, bevor Sie Details zitieren. Für einen Leitfaden zu den konkreten Inhalten, von Protective DNS bis Authority Server Hardening, siehe Ivan Ristic zu NISTs Secure DNS Deployment Guide.

Praktisch für die meisten Unternehmen: Sie fallen nicht direkt unter die technischen Anforderungen der CIR 2024/2690, während NIS2 je nach Umsetzung in Ihrem Land gelten kann oder auch nicht. NIST SP 800-81r3 ist das eine Dokument in dieser Liste, mit dem Sie sofort arbeiten können, ohne die Geltung klären oder eine Umsetzungsfrist abwarten zu müssen.

Die häufigste Panne – und die unspektakulärste. DNS löst nicht mehr korrekt auf, und weil das oft nur teilweise passiert, merkt es niemand rechtzeitig.

• Lame Delegations entstehen, wenn in einer Elternzone NS-Einträge auf einen Nameserver zeigen, der entweder nicht autoritativ für die Kindzone ist oder sie gar nicht kennt. Die Delegation ist eingetragen, der Server erfüllt aber seine Aufgabe nicht. Welche Domainauflösung funktioniert, hängt dann davon ab, welchen Server ein Resolver zufällig abfragt – für manche klappt es, für andere gibt es SERVFAIL. Beide Ausgänge sind technisch richtig, nur einer beim Test sichtbar.
• Verwaiste Einträge zeigen auf Infrastruktur, die nicht mehr existiert. Ein Server wurde abgebaut, ein Load Balancer ersetzt, ein Dienst migriert – und der A- oder CNAME-Eintrag blieb zurück. Manchmal funktioniert der Eintrag schlicht nicht mehr. Manchmal wird die Adresse einem anderen Mieter zugeteilt – jetzt zeigt der Eintrag auf fremde Infrastruktur.
• Teilweise Auflösungsfehler sind am schwersten zu finden, weil sie die meisten Monitoringarten austricksen. Eine Prüfung nach dem Motto „Löst diese Domain auf?“ von einem Standort auf einem Resolver ergibt ein sauberes Ergebnis. Gleichzeitig landen andere Nutzer auf Nameservern mit veralteten Daten, Resolvern, die DNSSEC validieren (während Ihres nicht validiert), oder einem Pfad, bei dem ein NS-Eintrag tot ist. Der Fehler ist real und reproduzierbar – nur nicht da, wo jemand hinschaut.

Der Grund, warum diese Fehlerkategorie bestehen bleibt: DNS ist bewusst widerstandsfähig gebaut. Redundanz bedeutet, dass meist auch ein ausgefallener von vier Nameservern keinen sichtbaren Ausfall erzeugt – nur einen minimal langsameren, weniger zuverlässigen Dienst. Die Verschlechterung ist still, es gibt keinen eindeutigen Auslöser zum Nachforschen.

Ein Zonentransfer (AXFR) repliziert die komplette Zonen-Datei eines primären Nameservers auf einen sekundären. Notwendig, normal und gefährlich, wenn Transfers nicht eingeschränkt werden – denn ein nicht konfigurierter Nameserver gibt die gesamte Zone an jeden heraus, der fragt.

Eine Abfrage liefert alle Hostnamen samt Adressen. Kein Scannen, kein Subdomain-Bruteforcing, keine Ratespielchen. In von uns geprüften Umgebungen bedeutete dies: interne Namenskonventionen, Sprach-Infrastruktur, Entwicklungsumgebungen im Produktivnetz – und fast vollständige Netzwerkkarten innerhalb einer einzigen Antwort.

Ein Muster, das man kennen sollte: Elternzonen sind oft abgesichert, weil sie an prominenter Stelle stehen. Delegierte Subdomains hingegen, von anderen Teams betrieben oder für konkrete Produkte aufgestellt, haben eigene Konfiguration – und werden von niemandem geprüft. Details samt realen Rückgaben aus zwei wirklichen Zonen finden Sie in wie offene Zonentransfers Ihr internes Netzwerk offenlegen.

Ein verwaister Eintrag zeigt nach Außerbetriebnahme des zugehörigen Drittanbieterdienstes weiterhin auf diesen Namen. Kann die Zielressource von Dritten neu beansprucht werden, kontrollieren sie damit Ihre Domain.

Die technischen Details sind schlicht: Ein Team setzt eine Kampagnenseite auf, etwa auf einem Website-Baukasten oder einer Cloud-Plattform, trägt einen DNS-Eintrag ein, und irgendwann endet das Projekt. Der Dienst wird gelöscht – aber der Eintrag bleibt, denn das Anlegen ist geplant, das Entfernen hat niemand zur Aufgabe.

Zum Risiko wird das erst durch die Plattform dahinter.

Im Rahmen einer Kundenprüfung scannten wir eine Domainlandschaft, um abzugleichen, wohin DNS-Einträge tatsächlich zeigen und was intern angenommen wird. Eine Domain war Jahre zuvor für eine Marketing-Kampagne mit einem A-Eintrag zu einem Website-Baukasten angelegt worden. Die Kampagne war vorbei, die Seite gelöscht – der Eintrag bestand unverändert fort.

Wir testeten, ob die Plattform anderen die Ressourcen-Übernahme erlaubt. Sie tat es: kein TXT-Record zum Nachweis der Zonenkontrolle, keine Datei auf der Subdomain, keine Prüfung, ob der Domaininhaber ursprünglich jemand anderes war, keine Benachrichtigung für den Altbesitzer. Die Plattform betrachtete den DNS-Eintrag selbst als ausreichend, was den Kern des Problems zeigt: der Eintrag besagt nichts über das Anrecht, die Ressource zu beanspruchen.

Am selben Nachmittag band unser Team die Domain an einen eigenen Account und stellte eine selbst verfasste Seite bereit – über den echten Hostnamen der Kundendomain, ohne Zertifikatswarnung und ohne sichtbare Auffälligkeit. Ein Besucher, der die Adresse eingab oder einem alten Kampagnenlink folgte, hätte keinen Anlass zum Zweifel.

Wir meldeten das Verfahren noch am selben Tag. Nach Bestätigung wurde der DNS-Eintrag abends entfernt und die Lücke geschlossen. Die Verwundbarkeit bestand so lange wie der Eintrag – vermutlich Jahre. Das Finden, der Nachweis und das Schließen passten in einen Arbeitstag. Die eigentliche Schwierigkeit war nie die technische Reparatur.

Deshalb ist eine Übernahme kritischer als andere Fehlerarten. Ein Leck gibt Angreifern Informationen. Eine Übernahme verschafft ihnen einen funktionierenden, vertrauenswürdigen Lieferweg. Inhalte von einer schon vertrauten Domain lösen andere Instinkte aus als ein Lookalike – das macht Credential-Theft, Malware-Verbreitung und Traffic-Diebstahl viel einfacher.

Cloud-Anbieter weisen offen darauf hin, dass sie diese Lücke nicht selbst schließen: AWS dokumentiert, dass viele Services Namen alter Ressourcen von neuen Kunden übernehmen lassen; domänenübergreifende Verifikationsmechanismen gibt es nicht, und die Incident-Teams beobachten gezieltes Scanning auf public DNS nach verwaisten Einträgen [5]. OWASP stuft es als betriebliches Problem ein: empfiehlt Inventur, Entfernen von Einträgen vor Abschalten der Ressourcen sowie Überwachen der Anbieter-Fehlerstrings [6]. Beides stimmt, beides liegt in Ihrer Verantwortung. Technische Details zur Erkennung und Behebung liefert dangling DNS: wie Sie Einträge vor Übernahme finden und reparieren.

Der Fehlermodus, der Audits übersteht, weil alles grün meldet.

Defektes DNSSEC ist der klarste Fall – mit asymmetrischem Fehler. Eine signierte Zone mit abgelaufener Signatur oder DS-Record, der nicht mehr zum Schlüssel passt, scheitert bei der Validierung lautstark. DNSSEC macht seine Aufgabe – aber nach außen wirkt es wie ein unerklärter Ausfall. Leiser ist die Variante, bei der die Zone überall signiert aussieht, die Validierung aber nirgendwo stattfindet. Die Berichterstattung signalisiert DNSSEC – der Schutz ist nicht vorhanden. Unser Leitfaden zu NISTs DNS-Empfehlungen erklärt korrekte DNSSEC-Einführung.

Ein veröffentlichter TLSA-Eintrag ist für sich genommen keine echte DANE-Einführung – DANE funktioniert nur, wenn die DNSSEC-Kette sauber validiert. Für SMTP gilt: Ein unsicheres TLSA-Ergebnis wird wie vor-DANE opportunistisches TLS behandelt – nicht als authentifiziertes DANE.

Inkonsistente NS- und SOA-Einträge führen dazu, dass die Nameserver sich über den Zoneninhalt nicht einig sind. Wenn das NS-Set im Parent nicht mit dem im Child übereinstimmt, können Resolver Server erreichen, die laut Ihrer Ansicht gar nicht mehr autoritativ sind. Unterscheiden sich SOA-Seriennummern auf Ihren Nameservern, liefern diese womöglich unterschiedliche Daten aus – und welches Ergebnis der Nutzer bekommt, hängt vom Server ab. Beides kann ein Check, der nur einen Nameserver abfragt, nicht erkennen.

Denn: Was diese Fehler vereint, ist der positive Kontrollreport. Sie können einen sauberen Scan, eine signierte Zone und einen DANE-Eintrag vorlegen – und trotzdem ist der Schutz nicht aktiv.

Zwei Punkte sind bei dieser Zuordnung bemerkenswert:

Lame Delegation taucht doppelt auf, in zwei Fehlerarten – das zeigt den Wert der Taxonomie. Abschnitt 3.2.1 sieht es als Verfügbarkeitsproblem: eine Delegation auf einen nicht existierenden Server macht eine Kindzone unerreichbar. Abschnitt 3.6.2 behandelt dieselbe Fehlkonfiguration als Übernahmeweg: Eine an einen DNS-Provider delegierte Subdomain, deren Vertrag abgelaufen ist, kann ein Angreifer durch Vertragsabschluss übernehmen. Ein Fehler, zwei völlig unterschiedliche Folgen – und meist wird nur nach der einen gesucht.

Zone drift und zone thrash in Abschnitt 3.2.2 sind die benannten Ausprägungen des Konsistenzproblems. Sind Refresh- und Retrywerte im SOA-Record auf häufig ändernden Zonen zu hoch, liefern Secondaries veraltete Daten aus. Sind sie zu niedrig, entsteht unnötige Transferlast. Beides verschlechtert den Dienst, ohne dass jemand einen Ausfall sieht.

Alles Weitere hängt davon ab – und dies ist meist der stille Scheiterpunkt. Ziel ist vollständige Abdeckung: jede Domain, Zone und jeder Eintrag, über alle Registrar, DNS-Provider, Cloud-Konten und Zertifizierungsstellen hinweg, unabhängig davon, ob das ursprüngliche Team noch existiert. Die größte Falle: Die Liste aus der Erinnerung zusammenzustellen. Die Einträge, die Vorfälle auslösen, sind genau diejenigen, an die sich niemand mehr erinnert – nach Übernahmen nie migrierte Domains, Subdomains ehemaliger Teams, Kampagnenseiten aus dem Marketing ohne Ticket. Eine Liste, die auf persönlicher Befragung basiert, ist garantiert falsch – und das genau an den entscheidenden Stellen. Unser Blog zu dangling DNS beschreibt, was mit solchen nie erfassten Einträgen passiert.

Wenn Sie wissen, was existiert, legen Sie fest, wie der Soll-Zustand aussieht, damit Abweichungen sichtbar werden. Dazu gehören: Welche Registrare und DNS-Anbieter sind zugelassen? Welche Cloudadressbereiche und Zertifizierungsstellen erwarten Sie? Welche Mail-Authentifizierungswerte gelten pro Domain? Welche Zonen sind mit DNSSEC signiert? Der Zweck: Vergleichbarkeit. Eine unautorisierte Nameserveränderung und eine geplante Migration erzeugen dasselbe DNS-Event – nur eine Baseline zeigt, was was ist. Ohne eine solche sieht man zwar Änderungen, aber nicht deren Bedeutung.

Vergleichen Sie den Live-Bestand fortlaufend mit der Baseline und klassifizieren Sie die Resultate. Bei großen Umgebungen ändern sich täglich etwa 1 % der Einträge – das sind in einem Bestand mit 37.500 Einträgen rund 375 Änderungen am Tag. Rohe Change-Feeds in dieser Menge werden nach spätestens zwei Wochen ignoriert – schlimmer als niemandes Überwachung, weil der Anschein von Monitoring entsteht. Operabel wird das erst durch Klassifikation: Routineänderungen durch Provider von echten Fehlleitungen trennen und Bekanntes automatisch ausblenden, damit Unbekanntes sichtbar bleibt.

Messen Sie den Bestand an NIST SP 800-81r3, indem Sie die Fehlerarten als Prüfstraßen aufsetzen. Täglich prüfen statt nur periodisch. Den Durchsatz über die Zeit verfolgen, anstatt jede Prüfung als eigene Momentaufnahme zu betrachten. Ein sauberes Ergebnis sagt nur etwas über den einen Moment. Ein sinkender Erfolgsquotient über sechs Wochen zeigt, dass Ihre Umgebung „driftet“ – dieser Trend ist der eigentlich wichtige Fund und tritt deutlich vor dem eigentlichen Ausfall auf.

Stufen Sie die Umgebung, damit das Modell tragfähig bleibt – und ordnen Sie die Änderungen wie auch die Assets. Eine Nameserver-Änderung auf einer produktiven Authentifizierungsdomain ist nicht mit der auf einer geparkten Verteidigungsdomain gleichzusetzen. Wer beides gleich behandelt, sorgt dafür, dass das Entscheidende übersehen wird. Ordnen Sie Änderungen offenen Findings zu. Ein Eintrag, der sich ändert und schon einen offenen Befund trägt, bekommt Priorität. Programme, die alles als ebenso kritisch einstufen, kollabieren unter ihrer eigenen Meldungsflut binnen eines Quartals.

Der entscheidende Sprung ist von Stufe 2 zu Stufe 3, weil ab dort die Erkennung nicht mehr davon abhängt, dass jemand bewusst hinschaut.

Gehen Sie dies für Ihre eigene Umgebung durch. Alles, was Sie nicht mit Gewissheit beantworten können, ist schon für sich ein Befund.

• Sie können eine Liste aller Domains erstellen, die Ihre Organisation besitzt – über alle Registrar hinaus
• Diese Liste umfasst auch Domains, die durch Fusionen und Übernahmen erworben wurden
• Sie wissen, welcher DNS-Provider jede Zone hostet
• Sie können alle Subdomains auflisten, die an einen Nameserver delegiert sind, den Sie nicht kontrollieren
• Jede Zone hat einen benannten Eigentümer, der noch im Unternehmen tätig ist

• Jeder NS-Eintrag in jeder übergeordneten Zone verweist auf einen Nameserver, der für die untergeordnete Zone autoritativ ist
• SOA-Seriennummern stimmen bei allen Nameservern einer Zone überein
• Der im Parent veröffentlichte NS-Satz entspricht dem NS-Satz innerhalb der Child-Zone
• Sie testen die Auflösung mit mehreren Resolvern aus verschiedenen Geografien, nicht nur einem

• Zone-Transfers sind auf benannte sekundäre IP-Adressen bei jedem Nameserver beschränkt
• Sie haben AXFR für jede delegierte Subdomain getestet, nicht nur für die Parent-Zone
• Keine Zone enthält Hostnamen, die interne Namenskonventionen oder nicht-öffentliche Infrastruktur verraten
• Entwicklungs- und Testumgebungen befinden sich nicht in Produktionszonen

• Sie können alle DNS-Einträge auflisten, die auf eine SaaS-Plattform, Cloud-Services oder einen Storage-Bucket von Dritten verweisen
• Das Entfernen des DNS-Eintrags ist ein verpflichtender Schritt bei der Stilllegung eines Drittanbieter-Services
• Sie wissen, welche dieser Plattformen die Domain-Inhaberschaft vor der Bindung prüfen
• Jemand überprüft diese Einträge regelmäßig geplant und nicht nur bei Vorfällen

• Sie wissen, welche Zonen mit DNSSEC signiert sind und welche nicht
• Das Ablaufdatum der Signaturen wird aktiv überwacht, nicht angenommen
• Jede Zone, die TLSA-Einträge für DANE veröffentlicht, ist DNSSEC-signiert
• DS-Einträge im Parent stimmen mit den aktuellen Keys in der Child-Zone überein
• Sie haben getestet, dass die Validierung tatsächlich fehlschlägt, wenn sie es soll

• Es gibt eine Baseline, die genehmigte Registrare, Anbieter, Cloud-Ranges und CAs definiert
• Änderungen an NS-, MX- und TXT-Einträgen lösen eine Alarmierung aus
• Die Umgebung ist nach Wichtigkeit gestuft statt einheitlich behandelt
• Jemand ist namentlich für die DNS-Hygiene verantwortlich, nicht nur abschnittweise

Die erste Stufe stoppt die meisten Programme, weil alles, was danach kommt, davon abhängt, zu wissen, was existiert. Cloud-native Konfigurationsprüfungen sind nützlich und bewusst auf ein einzelnes Konto ausgelegt. Open-Source-Scanner decken mehr ab, laufen aber nur, wenn sich jemand erinnert, sie zu starten. Keine dieser Methoden deckt eine Umgebung ab, die sich über mehrere Registrare, verschiedene DNS-Provider und Cloud-Konten von Teams erstreckt, die nicht an die IT-Sicherheit berichten.

Red Sift ASM erstellt diese Bestandsaufnahme, indem es sich direkt mit Ihren Registaren, DNS-Providern und Cloud-Konten verbindet, statt sich auf eine von jemand gepflegte Liste zu verlassen. Es überwacht die DNS- und DNSSEC-Konfiguration kontinuierlich, markiert verwaiste Einträge und beanspruchbare Ressourcen sofort beim Auftauen und prüft die DANE-Konfiguration, wodurch die Ausfallmodi in diesem Leitfaden als Befunde statt als Vorfälle sichtbar werden.

• [1] Richtlinie (EU) 2022/2555 des Europäischen Parlaments und des Rates vom 14. Dezember 2022 über Maßnahmen für ein hohes gemeinsames Cybersicherheitsniveau in der Union
• [2] Durchführungsverordnung (EU) 2024/2690 der Kommission vom 17. Oktober 2024
• [3] NIS2 Technische Implementierungsleitlinien
• [4] Secure Domain Name System (DNS) Deployment Guide, NIST SP 800-81r3
• [5] Threat Tactic Spotlight: Subdomain Takeover
• [6] Subdomain Takeover Prevention Cheat Sheet