Wichtigste Erkenntnisse
- Echte DNS-Sicherheit umfasst Zugriffskontrollen bei Registraren, die Verfügbarkeit autoritativer Nameserver, Transportverschlüsselung (DoH/DoT) sowie die Validierung öffentlicher Einträge.
- Domain-Hijacking und die Übernahme von Subdomains führen zu einem sofortigen Verlust der Perimeterintegrität. Setzen Sie Registry-Locks durch, verlangen Sie bei Ihrem Registrar eine FIDO2-MFA per Hardware und schränken Sie AXFR-Zonentransfers unverzüglich ein.
- Setzen Sie DNSSEC unter Verwendung der ECDSA-Kurven-Algorithmen P-256 oder Ed25519 gemäß NIST SP 800-81r3 ein, um Cache-Poisoning zu verhindern, ohne dass es zu einer Fragmentierung der DNS-Antwortpakete kommt.
- SPF, DKIM und DMARC (mit der Einstellung „p=reject“) werden im DNS veröffentlicht. Wenn Sie Ihre Nameserver absichern, dabei aber die E-Mail-Einträge außer Acht lassen, ist Ihre Domain anfällig für direktes Spoofing.
- Richten Sie rund um die Uhr automatische Benachrichtigungen bei Änderungen an MX- und NS-Einträgen ein und leiten Sie die Protokolle des Protective DNS (PDNS)-Resolvers direkt in Ihre SIEM-Plattform weiter.
Die DNS-Infrastruktur (Domain Name System) ist oft die vertrauenswürdigste Komponente in einem Unternehmensnetzwerk, wird jedoch nach wie vor am wenigsten überwacht. Wenn Systemadministratoren Domain-Einträge einrichten, widmen sie sich anschließend in der Regel den Firewalls, der Endgerätesicherheit oder dem Identitätsmanagement. Angreifer wissen um diese Lücke und nutzen sie voll aus.
Wenn ein Angreifer die Kontrolle über die Auflösung Ihrer Domainnamen erlangt, kann er den Webverkehr unbemerkt umleiten, Unternehmens-E-Mails abfangen und gültigeTLS-Zertifikate (Transport Layer Security ) in Ihrem Namen erstellen. All dies gelingt ihm, ohne auch nur einen einzigen Server in Ihrem internen Netzwerk zu kompromittieren.
Die Implementierung einer robusten DNS-Sicherheit ist für moderne Infrastrukturen unverzichtbar. Dieser Leitfaden enthält eine umfassende Sammlung von Best Practices für die DNS-Sicherheit, die Ihnen dabei helfen sollen, häufige Probleme und Fehler zu vermeiden.
Was ist DNS-Sicherheit?
DNS-Sicherheit ist das System aus technischen Kontrollmaßnahmen, kryptografischen Protokollen und administrativen Richtlinien, das darauf ausgelegt ist, die Integrität, Verfügbarkeit und Vertraulichkeit von Domainnamen-Auflösungsdiensten zu schützen.
Anstatt sich auf ein einziges Tool zu verlassen, erfordert eine wirksame DNS-Sicherheit Abwehrmaßnahmen auf vier verschiedenen Ebenen:

- Die Registrierungs- und Kontoebene: Dazu gehören administrative Sicherheitsmaßnahmen bei Ihrem Domain-Registrar, die unbefugte Domain-Übertragungen und den Diebstahl von Zugangsdaten verhindern.
- Die Ebene der autoritativen Nameserver: Hierbei handelt es sich um Infrastrukturmaßnahmen, die sicherstellen, dass Ihre offiziellen Zonendateien verfügbar und unverändert bleiben und gegen DDoS-Angriffe (Distributed Denial of Service) gewappnet sind.
- Die Auflösungs- und Transportschicht: Diese Schicht umfasst Protokolle, die DNS-Anfragen während der Übertragung zwischen Endbenutzer-Clients, rekursiven Resolvern und autoritativen Servern schützen.
- Die Ressourcen- und Identitätsschicht: In Ihrer Zonendatei veröffentlichte kryptografische Einträge, wie beispielsweise DNS-Sicherheitserweiterungen (DNS Security Extensions) und E-Mail-Authentifizierungseinträge, die die Echtheit Ihrer Domänendaten überprüfen.
Warum das DNS ein Angriffsziel ist: Die Angriffsfläche
Da das DNS als vertrauenswürdige Hintergrundinfrastruktur fungiert, ermöglichen veraltete Konfigurationen es Angreifern, verschiedene Angriffe durchzuführen.
DNS-Hijacking und Kompromittierung von Registrierstellen
Bei einem Domain-Hijacking-Angriff verschafft sich ein Angreifer Zugriff auf Ihr Konto beim Domain-Registrar oder nutzt Schwachstellen in den Verfahren des Registrars aus, um Ihre Nameserver-Delegierungen zu ändern. Sobald ein Angreifer Ihre NS-Einträge so ändert, dass sie auf seine eigenen betrügerischen Server verweisen, kontrolliert er den gesamten eingehenden Datenverkehr für Ihre Domain.
In jüngster Zeit richteten sich Kampagnen gegen Domain-Registrare, bei denen „Credential Stuffing“ und gezieltes Social Engineering zum Einsatz kamen. Wenn Angreifern ein DNS-Hijacking gelingt, können sie mithilfe automatisierter Validierungsprotokolle der Zertifizierungsstelle (CA) sofort gültige Zertifikate für Ihre Root-Domain ausstellen.
DNS-Spoofing und Cache-Poisoning
Herkömmliche DNS-Abfragen werden über unverschlüsseltes UDP auf Port 53 übertragen. Da Standardabfragen keine integrierte Transaktionsauthentifizierung verfügen, kann ein Angreifer auf dem Netzwerkpfad Antwortpakete fälschen und diese an einen rekursiven Resolver zurücksenden, bevor der legitime autoritative Server antwortet.
Diese als „DNS-Spoofing“ bezeichnete Technik zwingt rekursive Server dazu, gefälschte IP-Adressen für bestimmte Hostnamen zu akzeptieren. Wenn ein Resolver diese gefälschten Antworten in seinem lokalen Speicher ablegt, kommt es zu einem DNS-Cache-Poisoning. Jeder Nutzer, der sich auf diesen Resolver verlässt, wird auf bösartige Websites weitergeleitet, bis der zwischengespeicherte Eintrag abläuft. Das Verständnis dieser Angriffsvektoren ist bei der Analyse gängiger Arten von DNS-Angriffen von großer Bedeutung.
DNS-Amplifikation und DDoS
Autoritative Nameserver sind bevorzugte Ziele für volumenbasierte DDoS-Angriffe. Angreifer nutzen häufig offene rekursive Resolver aus, um einen DNS-Amplifikationsangriff zu starten.
Durch das Senden kleiner gefälschter Anfragen (wie beispielsweise ANY- oder TXT-Abfragen ) mit der gefälschten Quell-IP-Adresse des Opfers an anfällige Resolver senden diese massive Antwortdatenmengen an das Opfer zurück. Diese Datenflut überlastet die Netzwerkbandbreite und führt zu weitreichenden Dienstausfällen.
„Dangling Records“ und die Übernahme von Subdomains
Wenn Unternehmen Dienste zwischen Cloud-Anbietern migrieren, löschen Systemingenieure häufig Cloud-Ressourcen wie Amazon S3-Buckets, GitHub Pages oder Azure App Services, ohne die entsprechenden CNAME-Einträge in ihrer DNS-Zone zu entfernen.
Dieses Versehen führt zu einem „dangling DNS -Eintrag“. Ein externer Angreifer kann den aufgegebenen Bucket oder die App-Instanz auf der Plattform des Cloud-Anbieters für sich beanspruchen und so sofort die Kontrolle über Ihre Subdomain erlangen. Durch die Übernahme von Subdomains können Angreifer Phishing-Formulare hosten, Cross-Site-Scripting (XSS) ausführen und Sitzungs-Cookies stehlen.
E-Mail-Spoofing durch schwache DNS-Einträge
Die E-Mail-Zustellung hängt in hohem Maße vom DNS ab. Wenn Ihr Unternehmen keine ordnungsgemäß konfigurierten Authentifizierungsdatensätze veröffentlicht, können Cyberkriminelle ausgehende E-Mails versenden, die so gefälscht sind, dass sie den Anschein erwecken, als stammten sie von Ihrer Domain. Dadurch sind Ihre Geschäftspartner, Kunden und Mitarbeiter direkten Phishing-Kampagnen ausgesetzt.
Bewährte Verfahren für die DNS-Sicherheit: Die Checkliste zur Absicherung
Nutzen Sie diese Schritt-für-Schritt-Checkliste, um Ihre Domain-Infrastruktur systematisch gegen Abfangen und Missbrauch abzusichern.
1. Sperren Sie Ihre Domain auf Ebene des Registrars
Nicht authentifizierte Übertragungsanfragen stellen eine der größten Sicherheitslücken für wichtige Domain-Ressourcen dar. Wenden Sie die Statuscodes „clientTransferProhibited“ und „clientUpdateProhibited“ auf Ihre Domains an.
Für hochwertige Unternehmensdomains sollten Sie bei Ihrem Registrar eine Registry-Sperre beantragen. Eine Registry-Sperre erfordert eine Offline-Überprüfung, beispielsweise eine telefonische Bestätigung durch zuständige Mitarbeiter, bevor Änderungen an den Nameserver-Delegierungen oder den administrativen WHOIS-Ansprechpartnern vorgenommen werden können.
2. Setzen Sie bei Ihrer Registrierungsstelle die Zwei-Faktor-Authentifizierung (MFA) und den rollenbasierten Zugriff durch
Stellen Sie sicher, dass Administratorkonten bei Ihrem Domain-Registrar und Ihrem DNS-Hosting-Anbieter nicht ausschließlich auf Passwörtern basieren. Setzen Sie eine hardwarebasierte Multi-Faktor-Authentifizierung (MFA) unter Verwendung von FIDO2-/WebAuthn-Sicherheitsschlüsseln durch.
Bewahren Sie die Anmeldedaten für die Registrierungsstelle nicht in gemeinsam genutzten Team-Posteingängen auf. Führen Sie eine strenge rollenbasierte Zugriffskontrolle (RBAC) ein, sodass normale IT-Mitarbeiter nur Lesezugriff haben und die Berechtigungen zur Domainverwaltung ausschließlich bestimmten Domain-Administratoren vorbehalten sind.
3. Zonenübertragungen einschränken (AXFR)
Autoritative DNS-Server nutzen vollständige Zonentransfers (AXFR), um DNS-Daten zwischen Primär- und Sekundärservern zu replizieren. Wenn Ihr Nameserver uneingeschränkte AXFR-Anfragen von beliebigen IP-Adressen zulässt, können Angreifer Ihre gesamte Zonendatei herunterladen. Dadurch werden interne Hostnamenstrukturen, Staging-Server und versteckte Netzwerkinfrastruktur offengelegt.
Konfigurieren Sie Ihre primären Nameserver so, dass AXFR-Übertragungen nur an die ausdrücklich angegebenen IP-Adressen Ihrer autorisierten sekundären Nameserver zugelassen werden. Sie können Ihre Konfiguration über die Terminaleingabe überprüfen:
Keine
dig AXFR yourdomain.com @ns1.yourdomain.com
dig AXFR deine-domain.com @ns1.deine-domain.com
Wenn der Server Ihre vollständige Liste der DNS-Einträge zurückgibt, anstatt einen „Transfer Failed“- oder „REFUSED“-Fehler anzuzeigen, sind Ihre Zonentransfer-Einstellungen offen und müssen umgehend eingeschränkt werden.
4. Redundante autoritative Nameserver in verschiedenen Netzwerken bereitstellen
Die Abhängigkeit von einem einzigen DNS-Anbieter oder einem einzigen physischen Rechenzentrum führt zu einem Single Point of Failure. Sollte Ihr Anbieter Opfer eines DDoS-Angriffs oder eines Netzwerkausfalls werden, ist Ihr gesamter Online-Auftritt nicht mehr erreichbar.
Stellen Sie mindestens zwei autoritative Nameserver bereit, die über separate ASN (Autonomous System Numbers) und geografisch verteilte Netzwerke gehostet werden. Durch den Einsatz eines autoritativen DNS-Modells mit zwei Anbietern wird sichergestellt, dass Ihr sekundärer Anbieter die Abfragen nahtlos weiterbearbeitet, falls bei einem Anbieter ein Infrastrukturausfall auftritt.
5. DNSSEC mit moderner Kryptografie implementieren
DNSSEC versieht Ihre DNS-Einträge mit digitalen Signaturen. Wenn ein rekursiver Resolver eine DNSSEC-fähige Zone abfragt, überprüft er die kryptografischen Signaturen (RRSIG-Einträge) anhand einer Vertrauenskette, die bis zur Root-Zone zurückreicht. Dadurch wird sichergestellt, dass die Antwort während der Übertragung nicht verändert wurde.
Befolgen Sie bei der Implementierung von DNSSEC die aktualisierten Richtlinien gemäß NIST SP 800-81r3:
- Verwenden Sie moderne Kryptografie auf Basis elliptischer Kurven wie ECDSA mit der Kurve P-256 oder Ed25519 anstelle veralteter RSA-Schlüssel. Kleinere Schlüsselgrößen verringern das Risiko der Paketfragmentierung bei UDP.
- Halten Sie die Gültigkeitsdauer von Signaturen zwischen 5 und 7 Tagen ein, um das Zeitfenster zu begrenzen, in dem ein kompromittierter Schlüssel Missbrauch ermöglichen könnte.
- Planen Sie alle 1 bis 3 Jahre eine Erneuerung der Zone-Signing-Schlüssel (ZSK) ein und speichern Sie die Key-Signing-Schlüssel (KSK) nach Möglichkeit in sicheren Hardwarekonfigurationen.
Sie können überprüfen, ob die kryptografische Kette Ihrer Domain intakt ist, indem Sie Ihre Domain mit einem speziellen DNSSEC-Checker überprüfen.
6. Einen CAA-Eintrag (Certificate Authority Authorization) veröffentlichen
Ein CAA-Eintrag ist ein DNS-Eintrag im TXT-Format, der ausdrücklich festlegt, welche Zertifizierungsstellen berechtigt sind, öffentliche TLS-Zertifikate für Ihren Domainnamen auszustellen.
Wenn ein Angreifer versucht, bei einer automatisierten Zertifizierungsstelle ein nicht autorisiertes Zertifikat für Ihre Domain anzufordern, muss die Zertifizierungsstelle vor der Ausstellung Ihren öffentlichen CAA-Eintrag überprüfen. Ist die Zertifizierungsstelle nicht aufgeführt, wird die Ausstellung blockiert.
Um die Zertifikatsausstellung auf bestimmte Anbieter zu beschränken, fügen Sie Ihrer Root-Domain einen CAA-Eintrag hinzu:
Keine
yourdomain.com. IN CAA 0 issue „letsencrypt.org“
yourdomain.com. IN CAA 0 issue „digicert.com“
yourdomain.com. IN CAA 0 iodef „mailto:[email protected]“
Der Parameter „iodef“ weist konforme Zertifizierungsstellen an, Ihrem Sicherheitsteam E-Mails mit Echtzeitbenachrichtigungen zu senden, wenn jemand versucht, ein nicht autorisiertes Zertifikat anzufordern.
7. Überprüfung auf fehlende und verwaiste Datensätze
Überprüfen Sie regelmäßig Ihren Bestand an veröffentlichten Einträgen, um veraltete Hostnamen zu identifizieren. Achten Sie dabei besonders auf CNAME-Einträge, die auf Cloud-Hosts von Drittanbietern verweisen, auf Subdomains, die auf stillgelegte E-Mail-Anbieter verweisen, sowie auf veraltete A-Einträge, die auf nicht mehr verwendete IP-Adressen verweisen.
Bevor Sie strukturelle Änderungen vornehmen, überprüfen Sie Ihre veröffentlichten Einträge mit einem zuverlässigen Tool zur DNS-Abfrage. Die Überprüfung verschiedener Arten von DNS-Einträgen über alle aktiven Subdomains hinweg hilft dabei, eine versehentliche Anfälligkeit für Subdomain-Übernahmeangriffe zu vermeiden.
8. Sinnvolle TTL-Werte festlegen und die Ausbreitungsfenster verfolgen
Die Time-To-Live-Einstellungen (TTL) legen fest, wie lange rekursive Resolver einen DNS-Eintrag zwischenspeichern, bevor sie eine neue Kopie von Ihrem autoritativen Nameserver anfordern.
- Standardvorgehensweise: Legen Sie Standard-TTL-Werte zwischen 3.600 Sekunden (1 Stunde) und 86.400 Sekunden (24 Stunden) fest. Dadurch werden die Serverauslastung und die Abfragelatenz ausgeglichen.
- Vor der Migration oder bei der Reaktion auf Vorfälle: Senken Sie Ihre TTL-Werte mindestens 24 bis 48 Stunden vor geplanten Infrastrukturänderungen auf 300 Sekunden (5 Minuten).
Durch die vorzeitige Verkürzung der TTL-Zeiten wird sichergestellt, dass die Cache-Einträge auf allen globalen Resolvern schnell ablaufen, falls Sie den Datenverkehr von einem betroffenen Server umleiten müssen. Mit einem Echtzeit-DNS-Propagations-Checker können Sie überwachen, wie sich die Änderungen auf die globalen Resolver ausbreiten.
9. Verschlüsselung des Datenverkehrs zwischen Client und Resolver (DoH / DoT / DoQ)
Standardmäßige DNS-Abfragen im Klartext über den UDP-Port 53 legen die Surfgewohnheiten der Clients gegenüber lokalen Lauscher, betrügerischen WLAN-Betreibern und Transit-ISPs offen. Die Verschlüsselung des Abfragepfads schützt die Privatsphäre der Endnutzer und verhindert Manipulationen im lokalen Netzwerk.
Moderne Unternehmensnetzwerke unterstützen drei wichtige Standards für den verschlüsselten Datenverkehr:
- DNS über TLS (DoT) – Läuft über den dedizierten TCP-Port 853. DoT wird häufig zur Absicherung der Datenübertragung zwischen internen Endpunkten, lokalen rekursiven Resolvern und Upstream-Servern eingesetzt.
- DNS über HTTPS (DoH) – Kapseln DNS-Abfragen in den HTTPS-Datenverkehr auf Port 443 ein, wodurch sich der Abfrageverkehr nicht mehr vom normalen Webdatenverkehr unterscheiden lässt.
- DNS over QUIC (DoQ) – Nutzt das QUIC-Protokoll, um die Latenz zu verringern und die Leistung bei instabilen Netzwerkverbindungen zu verbessern.
Wenn Sie verschlüsseltes DNS in Unternehmensumgebungen einsetzen, konfigurieren Sie lokale Client-Endpunkte über Mobile Device Management (MDM)-Tools so, dass sie Ihre festgelegten internen verschlüsselten Resolver verwenden. Blockieren Sie nicht autorisierte ausgehende DoT-Verbindungen (Port 853) und öffentliche DoH-Endpunkte an Ihrer Netzwerk-Firewall, um zu verhindern, dass Anwendungen die lokale Sicherheitsprotokollierung umgehen.
10. Lokale Resolver- und Nameserver-Software absichern
Wenn Ihre Organisation selbst gehostete rekursive Resolver oder interne BIND-, Unbound- oder PowerDNS-Instanzen betreibt, befolgen Sie strenge Maßnahmen zur Serverabsicherung:
- Beschränken Sie die rekursive Auflösung auf autorisierte interne IP-Bereiche. Offene Resolver im öffentlichen Internet werden häufig für DDoS-Amplifikationsangriffe missbraucht.
- Implementieren Sie die QNAME-Minimierung und konfigurieren Sie die Resolver so, dass sie nur die minimal erforderlichen Domänenbezeichnungen an die übergeordneten autoritativen Server senden (RFC 7816). Dadurch wird verhindert, dass autoritative Root-Server die vollständigen Zielhostnamen sehen können.
- Platzieren Sie autoritative Primärserver hinter versteckten IP-Adressen, die nicht in öffentlichen NS- Einträgen aufgeführt sind. Öffentliche Sekundärserver beziehen Zonenaktualisierungen vom versteckten Primärserver.
11. Response Policy Zones (RPZ) implementieren
Response Policy Zones, oft auch als DNS-Firewalls bezeichnet, ermöglichen es Administratoren rekursiver Resolver, benutzerdefinierte Bedrohungsdaten-Feeds über die standardmäßige Namensauflösung zu legen.
Wenn ein Client-Gerät versucht, eine Domain aufzulösen, von der bekannt ist, dass sie Malware, Command-and-Control-Server (C2) oder Phishing-Seiten hostet, unterbrechen die RPZ-Regeln die Auflösung. Der Resolver gibt eine NXDOMAIN-Antwort zurück oder leitet den Nutzer auf eine interne Sperrseite weiter.
12. E-Mail-Authentifizierungsprotokolle durchsetzen: SPF, DKIM und DMARC
E-Mail-Authentifizierungsprotokolle sind DNS-Einträge. Ohne die Durchsetzung von SPF, DKIM und DMARC kann ein Angreifer die Identität Ihrer Domain in Phishing-E-Mails vortäuschen, selbst wenn Ihr Registrar und Ihre Nameserver vollständig abgesichert sind.
DNS-Überwachung: Eine Maßnahme, die die meisten Teams vernachlässigen
Sicherheitsteams entdecken DNS-Manipulationen oft erst, wenn der Kundensupport Ausfälle der Website oder Störungen im E-Mail-Verkehr meldet. Passive Konfigurationen führen zu massiven blinden Flecken.
Eine effektive DNS-Überwachung erfordert drei aktive Kontrollmaßnahmen:
- Automatisierte Überwachung der Integrität von Zonendateien: Richten Sie automatische Abfrageprogramme ein, die Ihre maßgeblichen Zonendateien rund um die Uhr überwachen. Ihr Team sollte sofort benachrichtigt werden, wenn sich kritische Einträge (wie z. B. NS-, MX-, A- oder Root-TXT-Einträge) unerwartet ändern.
- Warnmeldungen bei Änderungen an MX- und NS-Einträgen: Durch das Ändern eines MX-Eintrags kann ein Angreifer eingehende E-Mails über seine Server umleiten, um sensible Tokens zur Passwortzurücksetzung abzugreifen. Warnmeldungen zu Änderungen an MX- und NS-Einträgen sollten sofortige Workflows für Vorfälle mit hoher Priorität auslösen.
- Analyse von DNS-Abfrageprotokollen: Integrieren Sie Protective DNS (PDNS)-Protokolle in Ihre SIEM-Plattform (Security Information and Event Management). Durch die Korrelation von DNS-Abfrageprotokollen mit DHCP-Lease-Verläufen können Analysten böswillige Domain-Abfragen direkt auf kompromittierte interne Geräte zurückverfolgen.
E-Mail-Authentifizierung als DNS-Kontrolle
Ein häufiger Fehler bei der DNS-Sicherheit besteht darin, die Kontrollen des Webverkehrs von den E-Mail-Kontrollen zu trennen. SPF, DKIM und DMARC stützen sich vollständig auf DNS-TXT-Einträge, um öffentliche Schlüssel und Absenderrichtlinien zu veröffentlichen.
- SPF: Veröffentlicht eine Whitelist mit IP-Adressen und Mailservern, die berechtigt sind, ausgehende E-Mails im Namen Ihrer Domain zu versenden.
- DKIM: Fügt den Kopfzeilen ausgehender E-Mails kryptografische Signaturen hinzu. Die Empfänger rufen den entsprechenden öffentlichen Schlüssel aus dem DNS Ihrer Domain ab, um zu überprüfen, ob die Nachricht während der Übertragung nicht verändert wurde.
- DMARC: Verbindet SPF und DKIM miteinander. DMARC gibt den empfangenden Mail-Servern Anweisungen, wie sie mit E-Mails umgehen sollen, die die Authentifizierung nicht bestehen.
Wenn Sie Ihre Richtlinie auf „p=reject“ setzen, werden empfangende Mailserver angewiesen, nicht authentifizierte Nachrichten automatisch zu verwerfen. Das Verständnis Ihrer aktiven DMARC-Richtlinie schützt den Ruf Ihrer Marke in globalen Empfängernetzwerken.
Sie können den aktuellen Stand Ihrer E-Mail-Authentifizierung sofort mit einem Online -DMARC-Record-Checker überprüfen.
DMARC verhindert zwar die Nachahmung von Domänen in E-Mails, doch sollten Sie bedenken, dass DMARC keinen Schutz vor Cache-Poisoning oder der Übernahme von Subdomänen bietet. Eine umfassende Abwehrstrategie erfordert die Absicherung sowohl der DNS-Auflösung im Netzwerk als auch der DNS-Einträge für E-Mails.
Managed DNS und Filterung auf DNS-Ebene: Wo sie zum Einsatz kommen
Moderne Unternehmen setzen häufig verwaltete DNS-Plattformen und Sicherheitsfilter auf DNS-Ebene ein, um den Betrieb zu vereinfachen und die Transparenz hinsichtlich von Bedrohungen zu verbessern.
Renommierte Anbieter von Managed-DNS-Diensten
Anbieter von verwalteten DNS-Diensten für Unternehmen betreiben globale Anycast-Netzwerke, die Ihre autoritative Zonendatei auf Hunderte von Edge-Standorten verteilen. Die Anycast-Infrastruktur bietet integrierten DDoS-Schutz und fängt massive volumetrische Angriffe ab, bevor diese Ihr Kernnetzwerk erreichen. Verwaltete Plattformen automatisieren zudem die DNSSEC-Schlüsselverwaltung und die Pflege der DNS-Einträge.
Rekursive Filterung auf DNS-Ebene (Protective DNS)
PDNS-Lösungen (Protective DNS) arbeiten auf der Ebene des rekursiven Resolvers. Anstatt Anfragen lediglich zu beantworten, gleichen PDNS-Lösungen jede Anfrage mit dynamischen Bedrohungsdatenbanken ab.
Wenn ein Mitarbeiter auf einen Link klickt, der zu einer neu registrierten Phishing-Domain führt, oder wenn eine infizierte Nutzlast versucht, Kontakt zu einem C2-Server aufzunehmen, blockiert der Schutz-Resolver die Auflösung auf Netzwerkebene.
Weder verwaltetes DNS noch DNS-Filterung ersetzen die ordnungsgemäße Verwaltung durch den Domain-Registrar oder die korrekte Konfiguration der Einträge. Sie dienen als ergänzende Ebenen innerhalb einer umfassenderen Zero-Trust-Sicherheitsarchitektur.
Was zuerst geprüft werden sollte: Priorisierter Aktionsplan
Falls Ihr Sicherheitsteam in diesem Quartal nicht alle zwölf Punkte der Checkliste umsetzen kann, konzentrieren Sie sich zunächst auf Maßnahmen mit großer Wirkung. Führen Sie diese fünf Aufgaben der Reihe nach durch:
- Aktivieren Sie „clientTransferProhibited“ und Registrierungssperren für alle primären Domains. Verlangen Sie von allen Nutzern von Registrar-Konten die Verwendung von FIDO2-Hardware-Schlüsseln, um das Risiko einer Kontoübernahme auszuschließen.
- Beschränken Sie AXFR-Zonenübertragungen, indem Sie autoritative Nameserver überwachen, um uneingeschränkte Zonenübertragungen sofort zu blockieren.
- Erstellen Sie eine Bestandsaufnahme aller veröffentlichten CNAME-Einträge, vergleichen Sie diese mit den aktiven Cloud-Ressourcen und löschen Sie alle verwaisten Einträge.
- Richten Sie automatisierte MX- und NS-Benachrichtigungen ein, indem Sie eine kontinuierliche Überwachung der Einträge in der Root-Zone konfigurieren, damit Ihr Team bei unbefugten Änderungen sofort benachrichtigt wird.
- Überprüfen Sie aktive E-Mail-Quellen, beheben Sie Abweichungen bei der Konfiguration und aktualisieren Sie Ihre DMARC-Richtlinie, um gefälschte Nachrichten abzufiltern.
Häufig gestellte Fragen
Was versteht man unter DNS-Sicherheit, einfach ausgedrückt?
Die DNS-Sicherheit umfasst die technischen Protokolle, Zugriffskontrollen und administrativen Maßnahmen, die zum Schutz des Domain-Name-Auflösungssystems eingesetzt werden. Sie stellt sicher, dass Nutzer, wenn sie Ihren Domainnamen in einen Browser eingeben, eine Verbindung zu Ihren tatsächlichen Servern herstellen und nicht zu einer böswilligen Website, die von einem Angreifer erstellt wurde.
Verschlüsselt DNSSEC den DNS-Datenverkehr?
Nein, DNSSEC verschlüsselt weder DNS-Abfragen noch -Antworten. Standardmäßige DNSSEC-Abfragen werden im Klartext übertragen. DNSSEC nutzt digitale Signaturen, um zu überprüfen, ob die empfangenen DNS-Daten authentisch sind und während der Übertragung nicht verändert wurden. Um DNS-Abfragen zu verschlüsseln, müssen Sie DNS über HTTPS (DoH), DNS über TLS (DoT) oder DNS über QUIC (DoQ) einsetzen.
Was ist der Unterschied zwischen DNSSEC und DNS über HTTPS (DoH)?
DNSSEC überprüft die Datenintegrität auf Zonenebene und stellt sicher, dass eine Antwort unverändert vom tatsächlichen Domaininhaber stammt. DoH verschlüsselt die Übertragungsstrecke zwischen dem Endgerät eines Benutzers und dem rekursiven Resolver.
Ist DNS-Hijacking dasselbe wie DNS-Spoofing?
Nein. Beim DNS-Hijacking wird der Administratorzugriff beim Domain-Registrar oder beim Nameserver-Betreiber kompromittiert, um Ihre offiziellen DNS-Einstellungen zu ändern. Beim DNS-Spoofing (oder Cache-Poisoning) wird ein rekursiver Resolver dazu gebracht, gefälschte IP-Adressen in seinem Cache zu speichern, ohne dass Ihre offiziellen Registrar-Einstellungen verändert werden.
Wie kann ich feststellen, ob die DNS-Einstellungen meiner Domain kompromittiert wurden?
Zu den typischen Anzeichen zählen unerwartete Weiterleitungen der Website, plötzliche Einbrüche bei der E-Mail-Zustellung, unbefugt für Ihre Domain ausgestellte TLS-Zertifikate oder unerwartete Änderungen an Ihren NS-, A- oder MX-Einträgen im Rahmen routinemäßiger Überprüfungen.
Zählen SPF, DKIM und DMARC zur DNS-Sicherheit?
Ja. SPF-, DKIM- und DMARC-Einträge werden direkt in der öffentlichen DNS-Zone Ihrer Domain veröffentlicht. Da empfangende Mailserver das DNS abfragen, um die Authentizität des Absenders einer Nachricht zu überprüfen, sind korrekte E-Mail-Authentifizierungseinträge ein wesentlicher Bestandteil der DNS-Absicherung Ihrer Domain.
Schlussfolgerung
DNS-Sicherheit ist kein einzelnes Produkt, das man kauft und installiert. Es handelt sich um ein mehrschichtiges Konzept, das die Verwaltung durch die Domain-Registrare, die Absicherung autoritativer Nameserver, die Verschlüsselung des Abfrageverkehrs und die Überprüfung der Integrität von Einträgen umfasst.
Wenn eine Ebene nicht überwacht wird, eröffnet dies Angreifern die Möglichkeit, Datenverkehr zu kapern, Man-in-the-Middle-Angriffe durchzuführen oder Unternehmenskommunikation zu fälschen.
Beginnen Sie noch heute mit der Absicherung Ihrer Domain-Infrastruktur, indem Sie eine vollständige Bestandsaufnahme Ihrer aktiven Zonendateien durchführen. Nutzen Sie eine kostenlose DNS-Eintragssuche, um veröffentlichte Einträge zu überprüfen, und testen Sie Ihre Domain mit einem DMARC-Eintragsprüfer, um sicherzustellen, dass Ihre Marke geschützt bleibt.

- Bewährte Verfahren für die DNS-Sicherheit: Eine umfassende Checkliste zur Absicherung – 7. September 2026
- Dynamischer SPF vs. automatischer SPF vs. gehosteter SPF: Welche Variante korrigiert Ihren SPF-Eintrag tatsächlich? – 25. August 2026
- „Antworten“ vs. „Allen antworten“: Verhaltensregeln und Sicherheitsrisiken – 14. August 2026
