Was ist ein DNS-Zonentransfer und warum stellt er eine Sicherheitslücke dar?

Redundanz ist das Rückgrat des Domain Name Systems. Wenn ein autoritativer Nameserver ausfällt oder nicht mehr erreichbar ist, müssen Backup-Server bereitstehen, um Anfragen für Ihre Domain ohne Unterbrechung zu bearbeiten. Um diese sekundären Server synchron zu halten, nutzt das DNS Zonentransfers, um Einträge automatisch zu replizieren.

Bei korrekter Konfiguration laufen Zonentransfers unauffällig zwischen vertrauenswürdigen Servern ab. Doch schon eine einzige Standard-Einstellung oder ein Versäumnis bei der Zugriffskontrolle kann dazu führen, dass dieser Replikationskanal für das gesamte Internet offen steht. In diesem Fall wird aus einer üblichen administrativen Erleichterung ein offenes Informationsleck.

In diesem Leitfaden wird erläutert, was DNS-Zonentransfers sind, welche betrieblichen Unterschiede zwischen AXFR und IXFR bestehen, warum offene Transfers ein akutes Sicherheitsrisiko darstellen und wie Sie Ihre Nameserver vor unbefugten Erkundungsversuchen schützen können.

Was ist ein DNS-Zonentransfer?

Ein DNS-Zonentransfer ist die Replikation einer Zonendatei von einem primären autoritativen Nameserver auf einen oder mehrere sekundäre Nameserver über den TCP-Port 53. Er stellt sicher, dass die sekundären Nameserver über identische Kopien aller Ressourceneinträge verfügen, die erforderlich sind, um Client-Anfragen autoritativ zu beantworten.

Um zu verstehen, warum diese Replikation existiert, betrachten Sie zunächst, wie das autoritative DNS funktioniert. Eine DNS-Zone stellt einen eigenständigen Verwaltungsbereich innerhalb der globalen Domänenhierarchie dar. Die Zonendatei enthält den vollständigen Katalog der Ressourceneinträge, die diesen Bereich definieren, einschließlich Adresszuordnungen (A- und AAAA-Einträge), Mail-Exchanger (MX-Einträge), Dienststandorte (SRV-Einträge) und Validierungszeichenfolgen (TXT-Einträge).

Die Nutzung eines einzigen Nameservers führt zu einem inakzeptablen Single Point of Failure. Sollte dieser Server von einem Hardwareausfall, einer Netzwerküberlastung oder Störungen durch Distributed-Denial-of-Service-Angriffe (DDoS) betroffen sein, können Besucher Ihre Domain nicht auflösen.

Um Ausfallzeiten zu vermeiden, setzen Unternehmen sekundäre Nameserver ein. Eine manuelle Verwaltung dieser Server wäre ineffizient und fehleranfällig, da Administratoren jede Änderung an den Einträgen auf mehreren Hosts duplizieren müssten. DNS-Zonenübertragungen automatisieren diesen Prozess und ermöglichen es den sekundären Servern, aktualisierte Zonendaten direkt vom Master-Host abzurufen. Dies gewährleistet eine hohe Verfügbarkeit und verteilt das Abfragevolumen gleichmäßig auf geografisch verteilte Nameserver.

So funktionieren DNS-Zonenübertragungen

DNS-Zonentransfers basieren auf einer Client-Server-Architektur, bei der der sekundäre Nameserver als Client fungiert, der Daten anfordert, und der primäre Nameserver als Server, der diese bereitstellt.

Standardmäßige DNS-Abfragen von Webbrowsern werden in der Regel über den UDP-Port 53 (User Datagram Protocol) abgewickelt, um eine hohe Geschwindigkeit und geringen Overhead zu gewährleisten. Im Gegensatz dazu erfolgen Zonentransfers über den TCP-Port 53 (Transmission Control Protocol). TCP bietet die zuverlässige, zustandsbehaftete Verbindung und die Fehlerprüfung, die für die Übertragung großer Mengen strukturierter Daten ohne Paketverlust erforderlich sind.

Der Synchronisationsprozess stützt sich auf den Start-of-Authority-Eintrag (SOA), insbesondere auf dessen Feld für die Seriennummer:

1. Vergleich der Seriennummern: Der sekundäre Nameserver fragt regelmäßig den primären Server nach dessen SOA-Eintrag ab. Alternativ kann der primäre Nameserver, wenn ein Administrator eine Zone aktualisiert, eine unaufgeforderte DNS-NOTIFY-Nachricht (RFC 1996) senden, um die sekundären Nameserver über eine Aktualisierung zu informieren.
2. Übertragungsentscheidung: Der sekundäre Server vergleicht die Seriennummer des primären Servers mit seiner eigenen lokalen Kopie. Ist die Seriennummer des primären Servers höher, erkennt der sekundäre Server, dass sich Datensätze geändert haben, und initiiert eine Übertragungsanforderung.
3. Datenübertragung: Der Primärserver überprüft die Anfrage und überträgt die aktualisierten Datensätze über die hergestellte TCP-Verbindung.

Je nach Konfiguration und Umfang der Änderungen führen die Server diese Synchronisierung mithilfe einer von zwei Methoden durch: AXFR oder IXFR.

AXFR (Vollständiger Zonentransfer)

Der in RFC 1035 definierte und in RFC 5936 aktualisierte „Authoritative Transfer“ (AXFR) stellt den ursprünglichen Übertragungsmechanismus dar. Bei der Ausführung einer AXFR-Anfrage sendet der primäre Nameserver die gesamte Zonendatei von Anfang bis Ende, beginnend und endend mit dem SOA-Eintrag.

AXFR ist zwar unkompliziert und zuverlässig, bei großen Zonen jedoch ineffizient. Wenn ein Unternehmen eine Zone mit 50.000 Ressourceneinträgen verwaltet und eine einzige IP-Adresse ändert, werden bei einer AXFR-Übertragung alle 50.000 Einträge erneut übertragen. In Netzwerken mit hohem Datenvolumen verbrauchen wiederholte vollständige Übertragungen unnötig Netzwerkbandbreite und Rechenleistung.

IXFR (Incremental Zone Transfer)

Um den Aufwand für vollständige Übertragungen zu vermeiden, wurde mit RFC 1995 der inkrementelle Zonentransfer (IXFR) eingeführt. Anstatt die gesamte Datenbank zu kopieren, übermittelt IXFR nur die konkreten Unterschiede zwischen der aktuellen Version des sekundären Servers und der aktualisierten Version des primären Servers.

Bei einem IXFR-Austausch übermittelt der sekundäre Server in seiner Anfrage seine aktuelle SOA-Seriennummer. Der primäre Server wertet sein Änderungsprotokoll aus, ermittelt, welche Datensätze zwischen den einzelnen Versionen gelöscht und hinzugefügt wurden, und überträgt ausschließlich diese Deltas. Dies reduziert den Bandbreitenverbrauch erheblich und beschleunigt die Synchronisation in verteilten Architekturen.

Vergleich zwischen AXFR und IXFR

Wenn ein sekundärer Server über einen längeren Zeitraum offline war und seine Seriennummer nicht im Transaktionsverlauf des primären Servers enthalten ist, kann IXFR diese Lücke nicht schließen. In diesem Fall weicht das System nahtlos auf eine vollständige AXFR-Übertragung aus, um die Zone wiederherzustellen.

Warum Open-Zone-Transfers eine Sicherheitslücke darstellen

Zonentransfers sind für die administrative Synchronisation unerlässlich, wurden jedoch eher unter dem Gesichtspunkt der Verfügbarkeit als unter dem der Vertraulichkeit konzipiert. Standardmäßig wurden in älteren Nameserver-Konfigurationen eingehende AXFR-Anfragen oft als legitim behandelt.

Ein „Open Zone Transfer“ liegt vor, wenn ein autoritativer Nameserver auf AXFR-Anfragen reagiert, die von nicht autorisierten IP-Adressen stammen. Bei dieser Fehlkonfiguration kann jeder, der mit dem Internet verbunden ist, den Nameserver abfragen und eine vollständige Kopie der Zonendatei erhalten.

Diese Sicherheitslücke stellt eine kritische Schwachstelle hinsichtlich der Offenlegung von Informationen dar. Anstatt sich auf Brute-Force-Angriffe nach dem Prinzip „Versuch und Irrtum“ zu verlassen, erhält ein Angreifer eine autorisierte, strukturierte Bestandsaufnahme des digitalen Fußabdrucks einer Organisation. Dadurch wird eine manuelle Erkundungsphase in eine sofortige, umfassende Systemerkennung umgewandelt. Offene Zonentransfers gehören nach wie vor zu den am häufigsten dokumentierten häufigen DNS-Schwachstellen , da sie interne Betriebsabläufe der öffentlichen Einsicht aussetzen.

Was Angreifer aus einem Zonentransfer erfahren

Wenn ein Angreifer über eine offene AXFR-Abfrage eine Zonendatei abfängt, erhält er Zugriff auf Daten, die bei Standard-DNS-Abfragen in der Regel nicht sichtbar sind:

• Vollständige Subdomain-Verzeichnisse: Angreifer entdecken jede registrierte Subdomain, einschließlich Hosts, die nach internen Funktionen, Abteilungen oder firmeneigenen Technologien benannt sind.
• Entwicklungs- und Staging-Hosts: Auf Subdomains wie dev.example.com, test-api.example.com oder qa-vpn.example.com wird häufig Software vor der Veröffentlichung ausgeführt, bei der es an produktionsreifen Firewalls, aktuellen Sicherheitspatches oder strengen Zugriffskontrollen mangelt.
• Verwaltungs- und Fernzugriffsportale: Intranet-Links, Mitarbeiterportale, VPN-Zugangspunkte und Schnittstellen zur Datenbankverwaltung tauchen oft direkt in der Datensatzliste auf.
• E-Mail- und Routing-Architektur: MX-Einträge und die zugehörigen IP-Adressen der E-Mail-Hosts geben Aufschluss über die E-Mail-Filtertopologie, die Routing-Sprungpunkte und die Zustelldienste von Drittanbietern einer Organisation.
• Daten zur Überprüfung durch Dritte: Ungeprüfte TXT-Einträge enthalten häufig Verifizierungstoken für Cloud-Plattformen, SaaS-Integrationen, Analysetools sowie historische Verifizierungszeichenfolgen, die auf Abhängigkeiten der internen Infrastruktur hindeuten.

Wie eine Zone-Transfer-Sicherheitslücke andere Angriffe begünstigt

Die durch einen Open-Zone-Transfer gewonnenen Informationen dienen als operative Ausgangsbasis für ausgeklügelte Folgeangriffe:

• Übernahme von Subdomains: Zonendateien enthalten häufig verwaisten CNAME-Einträge, die auf stillgelegte Cloud-Ressourcen verweisen, wie beispielsweise aufgegebene Amazon S3-Buckets, GitHub Pages oder Microsoft Azure-Instanzen. Mit einer vollständigen Liste dieser CNAME-Einträge können Angreifer die verwaisten Ressourcen beim Drittanbieter für sich beanspruchen und unter der verifizierten Domain des Opfers unbefugte Inhalte bereitstellen.
• Spear-Phishing und Social Engineering: Durch das Aufdecken interner Server-Namenskonventionen, Adressen von Mitarbeiterportalen und Lieferantenbeziehungen können Angreifer äußerst glaubwürdige Social-Engineering-Köder erstellen. Wenn Angreifer in einer gezielten E-Mail echte interne Hostnamen angeben, ist die Wahrscheinlichkeit, dass Empfänger der Kommunikation vertrauen, deutlich höher. Um zu erfahren, wie Angreifer Infrastrukturdaten für das gezielte Sammeln von Anmeldedaten nutzen, lesen Sie unsere Analyse zu Spear-Phishing.
• Erweiterte Angriffsflächen: Bei Zonentransfers werden interne IP-Adressierungsschemata häufig offengelegt, wenn private Netzwerke versehentlich in öffentliche Zonen integriert werden. Dadurch erhalten Angreifer die erforderlichen Routing-Informationen, um Perimeter-Firewalls zu sondieren und interne Verwaltungsschnittstellen ins Visier zu nehmen.

Zudem führen Zonentransfers zwar an sich keine Manipulationen des Datenverkehrs durch, doch das Verständnis der Caching- und Routing-Topologie eines Unternehmens kann sekundäre Angriffe wie DNS-Cache-Poisoning.

So überprüfen Sie, ob Ihre Domain Zonenübertragungen zulässt

Sicherheitsadministratoren müssen überprüfen, ob autoritative Nameserver unbefugte Zonenübertragungen zulassen. Damit soll sichergestellt werden, dass externe Abfragen, die vollständige Zonenkopien anfordern, eine ausdrückliche Ablehnung erhalten und nicht die vollständigen Datensätze.

Administratoren bewerten diese Sicherheitslage, indem sie von einem externen, nicht vertrauenswürdigen Netzwerkstandort aus eine AXFR-Abfrage an jeden autoritativen Nameserver senden, der in den NS-Einträgen der Domain aufgeführt ist:

• Sicheres Verhalten: Der Nameserver lehnt die Anfrage sofort ab und gibt den Status „REFUSED“ oder „SERVFAIL“ zurück. Es werden keine Zonen-Einträge übertragen.
• Sicherheitslücke: Der Nameserver akzeptiert die Verbindung, bestätigt die AXFR-Anfrage und sendet die vollständige Liste der Domain-Ressourceneinträge zurück.

Neben regelmäßigen Stichprobenkontrollen profitieren Unternehmensumgebungen von einer automatisierten Überwachung. Automatisierte Konfigurationsprüfungen erkennen, wenn durch Aktualisierungen der Nameserver versehentlich Übertragungsbeschränkungen aufgehoben werden. 

PowerDMARC umfasst automatisierte AXFR-Exposure-Prüfungen im Rahmen seiner DNS-Sicherheitsüberwachung und benachrichtigt Administratoren sofort, sobald ein autoritativer Server beginnt, öffentliche Zonenübertragungsanfragen zu beantworten.

So sichern Sie DNS-Zonenübertragungen

Um Ihre Domain vor unbefugten Zonentransfers zu schützen, müssen strenge Zugriffsbeschränkungen und moderne kryptografische Sicherheitsmaßnahmen implementiert werden. Befolgen Sie die offiziellen NIST-Richtlinien zur DNS-Sicherheit bildet eine zuverlässige Grundlage für die Integrität Ihrer Domain.

Implementieren Sie die folgenden Abwehrmaßnahmen in Ihrer gesamten DNS-Infrastruktur:

1. Übertragungen nach IP-Adresse einschränken: Erlauben Sie niemals uneingeschränkte AXFR- oder IXFR-Abfragen. Geben Sie autorisierte IP-Adressen von sekundären Nameservern explizit in Ihren Nameserver-Konfigurationsblöcken an (z. B. über die „allow-transfer“-Anweisung von BIND) und lehnen Sie alle Anfragen ab, die von außerhalb dieser Whitelist stammen.
2. Authentifizierung mit TSIG: Die Beschränkung des Zugriffs allein anhand der IP-Adresse bietet zwar einen grundlegenden Schutz, doch in bestimmten Netzwerktopologien können IP-Adressen gefälscht werden. Implementieren Sie Transaktionssignaturen (TSIG), um die Kommunikation zwischen Nameservern mithilfe gemeinsamer kryptografischer Geheimnisse zu authentifizieren.
3. Zonenübertragungen auf eigenständigen Systemen deaktivieren: Wenn Ihre Domain auf einen einzigen Nameserver angewiesen ist oder einen modernen Managed-DNS-Anbieter nutzt, der die Synchronisierung über proprietäre API-Schnittstellen vornimmt, deaktivieren Sie Zonentransfers vollständig.
4. Implementieren Sie Split-Horizon-DNS: Verwalten Sie separate Zonendateien für interne Unternehmensnetzwerke und externe öffentliche Dienste. Interne Hostnamen, Testumgebungen und Staging-Subdomains sollten niemals in einer öffentlich zugänglichen Zonendatei enthalten sein.
5. Halten Sie Nameserver-Daemons auf dem neuesten Stand: Sicherheitslücken in DNS-Software können es Angreifern ermöglichen, ACL-Regeln zu umgehen oder eine Ressourcenerschöpfung auszulösen. Verwenden Sie aktualisierte, gepatchte Versionen von Server-Software wie BIND, PowerDNS, Knot DNS oder NSD, um das Risiko von Zero-Day-Schwachstellen und DNS-Amplifikationsangriffenzu minimieren.
6. Protokollierung und Warnmeldungen zu Übertragungsanfragen: Überwachen Sie die Abfrageprotokolle der Nameserver auf unaufgeforderte AXFR- oder IXFR-Anfragen. Wiederholte Übertragungsversuche von unbekannten IP-Adressen deuten häufig auf aktive Erkundungsversuche durch Angreifer hin.
7. Überprüfen Sie Ihre Zoneneinträge regelmäßig: Überprüfen Sie Ihre Zonendateien regelmäßig, um veraltete Einträge zu identifizieren und zu entfernen, insbesondere veraltete CNAME-Einträge, die auf abgelaufene Cloud-Hosting-Ressourcen von Drittanbietern verweisen.

Authentifizierung von Übertragungen mit TSIG und Verschlüsselung mit XoT

Transaktionssignaturen (TSIG), die in RFC 2845 standardisiert und in RFC 8945 überarbeitet wurden, ergänzen den DNS-Nachrichtenaustausch um eine kryptografische Authentifizierung. TSIG basiert auf symmetrischen gemeinsamen Geheimnissen, die zwischen dem primären und dem sekundären Nameserver vereinbart werden.

Nach der Konfiguration signiert der sekundäre Nameserver seine AXFR- oder IXFR-Anfrage mit einem kryptografischen Hash, der aus dem gemeinsamen Schlüssel und dem aktuellen Zeitstempel abgeleitet wird. Der primäre Nameserver überprüft die Signatur anhand seines eigenen Schlüssels. Stimmt die Signatur überein und liegt sie innerhalb eines zulässigen Zeitfensters, wird die Übertragung fortgesetzt; fehlt der Schlüssel oder ist er ungültig, lehnt der primäre Server die Verbindung ab.

TSIG dient zwar dem Identitätsnachweis und gewährleistet die Datenintegrität, verschlüsselt jedoch den Inhalt der Zone während der Übertragung nicht. Um diese Sicherheitslücke hinsichtlich der Vertraulichkeit zu schließen, veröffentlichte die Internet Engineering Task Force (IETF) RFC 9103veröffentlicht, der den DNS-Zonentransfer über TLS (XoT) spezifiziert. XoT bündelt AXFR- und IXFR-Sitzungen in einem verschlüsselten Transport Layer Security (TLS)-Tunnel und verhindert so das Abhören, Man-in-the-Middle-Angriffe und Manipulationen in den Transitnetzwerken.

Überwachung der Zone-Transfer-Belichtung mit PowerDMARC

Die Absicherung der Nameserver-Infrastruktur erfordert sowohl defensive Serverkonfigurationen als auch eine kontinuierliche externe Überwachbarkeit. Während Infrastrukturteams die Zugriffslisten für Zonen verwalten, benötigen Sicherheitsanalysten einen kontinuierlichen Überblick, um sicherzustellen, dass Verwaltungsfehler oder Cloud-Migrationen nicht unbemerkt zu einer Offenlegung von Einträgen führen.

PowerDMARC integriert eine spezielle Erkennung von AXFR-Sicherheitslücken in seine umfassenden beste DNS-Sicherheitslösungen .

Der DNS-Sicherheitsüberwachungs- und Compliance-Dienst von PowerDMARC ist nicht als Inline-Filter-Proxy oder Firewall konzipiert, sondern als Plattform zur Überwachung externer DNS-Einträge und zur Einhaltung von Sicherheitsvorschriften. Er führt automatisierte Überprüfungen Ihrer autoritativen Nameserver durch:

• AXFR-Sicherheitsprüfungen: Prüft kontinuierlich autoritative Nameserver von externen Standorten aus, um sicherzustellen, dass unbefugte Zonenübertragungen verhindert werden.
• Protokollierung von Zonenlecks: Markiert und protokolliert sofort Fälle, in denen ein sekundärer oder primärer Nameserver fälschlicherweise AXFR-Datenausgaben zulässt.
• Erkennung von Datensatzänderungen: Überwacht die seriellen Bewegungen von SOA und verfolgt Hinzufügungen, Änderungen oder Löschungen in öffentlichen Datensätzen.
• Überprüfung der Nameserver-Synchronisation: Überprüft, ob die sekundären Nameserver identische, synchronisierte Einträge im Vergleich zu den primären Autoritäten enthalten.
• DNSSEC und die Überwachung von „Dangling CNAME“-Einträgen: Warnt Administratoren vor unterbrochenen DNSSEC-Ketten und identifiziert veraltete CNAME-Einträge, bevor diese für die Übernahme von Subdomains ausgenutzt werden können.

Durch die Kombination strenger Zugriffskontrollen für Nameserver mit einer kontinuierlichen, automatisierten Überwachung der Einträge wird sichergestellt, dass Ihre DNS-Topologie vertraulich und ausfallsicher bleibt und den Sicherheitsstandards Ihres Unternehmens entspricht.

Häufig gestellte Fragen

Was ist der Zweck eines DNS-Zonentransfers?

Bei einem DNS-Zonentransfer werden Zonendaten von einem primären autoritativen Nameserver über den TCP-Port 53 an sekundäre Nameserver repliziert. Diese Replikation gewährleistet hohe Verfügbarkeit, Lastenausgleich und Fehlertoleranz in verteilten Netzwerken und verhindert so Fehler bei der Domänenauflösung, falls der primäre Server ausfällt.

Was ist der Unterschied zwischen AXFR und IXFR?

AXFR führt eine vollständige Zonentransfer durch, bei der die gesamte Zonendatei und alle zugehörigen Ressourceneinträge übertragen werden, unabhängig davon, ob Änderungen vorgenommen wurden. IXFR führt eine inkrementelle Übertragung durch, bei der nur die spezifischen Eintragserweiterungen und -löschungen übertragen werden, die seit der letzten synchronisierten Seriennummer des sekundären Servers vorgenommen wurden.

Ist ein DNS-Zonentransfer ein Angriff?

Nein, ein Zonentransfer ist ein standardmäßiger Verwaltungsmechanismus, der durch Internetstandards definiert ist. Er wird erst dann zu einem Sicherheitsvorfall, wenn ein autoritativer Nameserver so falsch konfiguriert ist, dass offene, uneingeschränkte AXFR-Transfers an unbefugte öffentliche Clients zugelassen werden, wodurch Angreifer die vollständige Domäneninfrastruktur einer Organisation herunterladen können.

Welchen Port nutzt ein Zonentransfer?

Zonenübertragungen nutzen den TCP-Port 53. Während standardmäßige rekursive DNS-Abfragen aus Geschwindigkeitsgründen auf den UDP-Port 53 zurückgreifen, erfordern Zonenübertragungen TCP, um eine zuverlässige Verbindung herzustellen, über die große, aus mehreren Paketen bestehende Zoneneinträge ohne Datenverkürzung oder Paketverlust übertragen werden können.

Was ist TSIG und wie sorgt es für die Sicherheit von Zonentransfers?

TSIG (Transaction Signatures) ist ein in RFC 8945 definierter DNS-Authentifizierungsmechanismus. Er nutzt gemeinsam genutzte symmetrische kryptografische Schlüssel, um Zonenübertragungsanfragen und -antworten zu signieren, und stellt so sicher, dass sich primäre und sekundäre Nameserver gegenseitig authentifizieren und die Datenintegrität überprüfen, bevor Zoneneinträge übertragen werden.

Erlauben Managed-DNS-Anbieter Zonentransfers?

Die meisten modernen Anbieter von verwalteten Cloud-DNS-Diensten deaktivieren standardmäßig herkömmliche öffentliche AXFR-Übertragungen und nutzen stattdessen proprietäre APIs und interne Anycast-Netzwerke zur Replikation von Einträgen. Einige Cloud-Anbieter bieten jedoch optionale, sichere AXFR-Konfigurationen an, um Hybridumgebungen bei der Anbindung benutzerdefinierter externer sekundärer Nameserver zu unterstützen.

Abschließende Worte

DNS-Zonentransfers sind für die Aufrechterhaltung einer kontinuierlichen Netzwerkverfügbarkeit und einer zuverlässigen Domänenauflösung von entscheidender Bedeutung. Werden sie jedoch nicht eingeschränkt, werden sie zu einem offenen Fenster in Ihr Unternehmensnetzwerk und liefern Angreifern eine detaillierte Übersicht über Subdomänen, Verwaltungsportale und vergessene Testumgebungen.

Um Zonentransfers zu sichern, muss nicht auf Redundanz verzichtet werden. Indem Sie die Übertragungen auf autorisierte sekundäre IP-Adressen beschränken, den Datenaustausch mit TSIG-Schlüsseln authentifizieren, Sitzungen mit XoT verschlüsseln und strenge Zonenhygiene wahren, können Sie Ihre Namensressourcen schützen, ohne dabei die Verfügbarkeit zu beeinträchtigen.

Machen Sie noch heute den ersten Schritt zur Sicherung Ihrer Domain-Infrastruktur: Nutzen Sie unseren kostenlosen Domain-Analyzer , um den Zustand Ihres öffentlichen DNS zu überprüfen, oder setzen Sie die DNS-Sicherheitsüberwachung von PowerDMARC ein, um Ihre Infrastruktur vor unbefugtem Zugriff zu schützen.