20 DNS-Sicherheits-Checks, die jede Domain bestehen sollte

Die meisten Domain-Kompromittierungen beginnen nicht mit einem gestohlenen Passwort, sondern mit einer DNS-Fehlkonfiguration, die niemandem aufgefallen ist. Eine Domain besteht eine echte DNS-Sicherheitsprüfung, wenn ihre DNSSEC-Vertrauenskette validiert, ihr CAA-Eintrag die ausstellenden CAs einschränkt, ihre SPF-, DKIM- und DMARC-Einträge korrekt abgegrenzt und durchgesetzt sind und ihre Nameserver- und Zonen-Hygiene weder verwaiste Einträge noch offene Zonentransfers zulässt. Im Folgenden findest du 20 konkrete Checks, die du für jede Domain durchführen kannst – nach Kategorien gruppiert und mit Beispielen zum Kopieren.

Warum eine DNS-Sicherheits-Checkliste wichtig ist

DNS liegt unter allem anderen – E-Mail-Zustellung, TLS-Zertifikatsausstellung, Namensauflösung der Website. Ein einziger veralteter CNAME oder ein fehlender CAA-Eintrag kann es einem Angreifer ermöglichen, eine Subdomain zu übernehmen oder ein gefälschtes Zertifikat für deine Domain ausstellen zu lassen, ohne jemals deine Server anzurühren. Wer eine feste Checkliste abarbeitet, findet die unspektakulären, aber folgenreichen Probleme, die Ad-hoc-Audits übersehen.

DNSSEC-Checks (1–2)

1. DNSSEC ist aktiviert und die Vertrauenskette validiert. Die DNS Security Extensions (DNSSEC) signieren deine Zone, damit Resolver überprüfen können, dass Einträge auf dem Übertragungsweg nicht manipuliert wurden. Prüfe, ob der DS-Eintrag deiner Domain beim Registrar mit dem in deiner Zone veröffentlichten DNSKEY übereinstimmt – eine Abweichung führt bei jedem validierenden Resolver zu SERVFAIL, wodurch die Website in sicherheitsbewussten Netzwerken stillschweigend nicht mehr erreichbar ist. Überprüfe das mit dig +dnssec yourdomain.com oder mit unserem DNS-Lookup-Tool.

2. NSEC3 wird statt einfachem NSEC verwendet. Mit Standard-NSEC-Antworten kann jeder deine Zone „ablaufen“ und alle darin enthaltenen Eintragsnamen auflisten – damit liefert man einem Angreifer die Aufklärung gratis. NSEC3 hasht die Namen in Antworten zur Nichtexistenz, sodass eine Zonenaufzählung nicht mehr trivial ist. Wenn dein DNS-Provider es unterstützt, solltest du NSEC3 bevorzugen.

CAA-Eintrag prüfen (3)

3. Ein CAA-Eintrag legt fest, welche Zertifizierungsstellen für deine Domain ausstellen dürfen. Ohne einen Certificate Authority Authorization (CAA)-Eintrag kann jede öffentliche CA ein Zertifikat für deine Domain ausstellen, wenn sie getäuscht oder kompromittiert wird. Veröffentliche einen, um die Ausstellung einzuschränken:

yourdomain.com.  IN  CAA  0 issue "letsencrypt.org"
yourdomain.com.  IN  CAA  0 issuewild ";"
yourdomain.com.  IN  CAA  0 iodef "mailto:security@yourdomain.com"

Dieses Beispiel erlaubt nur Let's Encrypt die Ausstellung von Standardzertifikaten, blockiert jede Wildcard-Ausstellung und teilt CAs mit, wohin sie Verstoßversuche melden sollen. Hintergründe dazu, wie Ausstellung und Vertrauenskette tatsächlich funktionieren, findest du in SSL-Zertifikate erklärt.

E-Mail-Authentifizierung prüfen (4–7)

4. SPF hat genau einen TXT-Eintrag und bleibt unter dem Limit von 10 Lookups. Das Sender Policy Framework (SPF) ist in RFC 7208 definiert. Zwei SPF-TXT-Einträge auf derselben Domain sind bereits ein Fehlerzustand, und mehr als 10 Mechanismen, die DNS-Lookups auslösen (include, a, mx, ptr, exists, redirect), führen zu einem permanenten Fehler, durch den die gesamte Prüfung fehlschlagen kann. Validiere deinen Eintrag mit dem SPF-Generator und lies So erstellst du einen sicheren SPF-Eintrag, wenn du Lookups reduzieren musst.

5. DKIM-Schlüssel haben mindestens 2048 Bit und verwenden kein rsa-sha1. DomainKeys Identified Mail (DKIM, RFC 6376) signiert ausgehende E-Mails, damit Empfänger prüfen können, dass sie nicht verändert wurden. RFC 8301 hat den Algorithmus rsa-sha1 als veraltet eingestuft und empfiehlt RSA-Schlüssel mit 2048 Bit oder mehr – 1024-Bit-Schlüssel sind Altlasten und sollten ausgetauscht werden.

6. DMARC ist mit Durchsetzung veröffentlicht, nicht nur im Monitoring-Modus. Domain-based Message Authentication, Reporting and Conformance (DMARC, RFC 7489) verwendet ein p=-Tag mit none, quarantine oder reject. Eine Domain, die dauerhaft auf p=none steht, erhält zwar Berichte, aber keinen echten Schutz vor Spoofing – wechsle zu quarantine oder reject, sobald deine rua-Sammelberichte ein sauberes SPF/DKIM-Alignment zeigen. Erstelle oder prüfe einen Eintrag mit dem DMARC-Generator.

7. Der DMARC-Alignment-Modus entspricht deiner Absicht. Die Tags adkim/aspf steuern, ob die SPF- und DKIM-Domains exakt mit der Domain im From:-Header übereinstimmen müssen (s, strikt) oder nur dieselbe Organisationsdomain teilen müssen (r, entspannt, der Standard). Entspanntes Alignment ist für die meisten Setups in Ordnung, du solltest es aber überprüfen, wenn du von vielen Subdomains aus versendest.

Nameserver- und Zonen-Hygiene prüfen (8–14)

8. Die NS-Einträge stimmen zwischen Registrar und Zone überein. Wenn die bei deinem Registrar hinterlegten Nameserver nicht mit denen übereinstimmen, die tatsächlich in der Zone ausgeliefert werden, kann die Auflösung inkonsistent werden oder sich aufspalten – je nachdem, welchem Eintrag ein Resolver vertraut.

9. Glue-Einträge sind für In-Bailiwick-Nameserver korrekt. Wenn deine Nameserver Subdomains der Domain selbst sind (z. B. ns1.yourdomain.com), braucht die übergeordnete Zone Glue-Einträge, die direkt auf deren IPs zeigen – sonst kann die Auflösung in eine Schleife geraten oder fehlschlagen.

10. Zonentransfers (AXFR) sind auf autorisierte Secondary-Server beschränkt. Ein offener Zonentransfer liefert deine gesamte DNS-Zone an jeden, der danach fragt. Teste das von extern:

dig axfr yourdomain.com @ns1.yourdomain.com

Wenn das von außerhalb deiner Infrastruktur deinen vollständigen Eintragssatz zurückgibt, sperre es sofort – der Transfer sollte nur für deine eigenen registrierten Secondary-Server funktionieren.

WarningEine offene AXFR-Antwort ist für einen Angreifer einer der schnellsten Wege, jede Subdomain, jeden Mailserver und jeden internen Hostnamen zu kartieren, den du hast – behandle jeden erfolgreichen externen Zonentransfer als kritischen Befund.

11. Keine verwaisten Einträge zeigen auf stillgelegte Ressourcen. Ein CNAME, der noch auf einen gelöschten Cloud-Storage-Bucket, Load Balancer oder SaaS-Endpunkt zeigt, ist ein klassischer Angriffsvektor für Subdomain-Takeovers. Gleiche jeden CNAME- und A-Eintrag mit dem ab, was tatsächlich noch bereitgestellt ist. Unser Leitfaden zu DNS-Eintragstypen ist eine nützliche Referenz, wenn du prüfst, was jeder Eintrag eigentlich tun sollte.

12. Wildcard-Einträge sind gewollt und keine Überbleibsel. Ein *.yourdomain.com-Eintrag fängt jede nicht registrierte Subdomain ab, was Phishing-Lookalikes unbemerkt auf deine Infrastruktur auflösen oder Tippfehler als legitim erscheinen lassen kann. Entferne Wildcards, die du nicht bewusst konfiguriert hast.

13. TTLs sind abgestimmt und nicht auf Standardwerten belassen. Die Time to live (TTL) steuert, wie lange Resolver einen Eintrag zwischenspeichern. Ist sie zu hoch, kannst du bei einem Vorfall kein schnelles Failover durchführen; ist sie zu niedrig, erzeugst du unnötige Abfragelast. Einige hundert bis einige tausend Sekunden sind für die meisten Einträge ein vernünftiger Ausgangswert, der vor geplanten Änderungen gesenkt wird.

14. Die Nameserver sind geografisch und topologisch verteilt. Laufen alle deine autoritativen Nameserver in einem Netzwerk oder bei einem Provider, legt ein einziger Ausfall deine gesamte Domain lahm. Verteile sie auf unabhängige Netzwerke bzw. ASNs.

Betrieb und Monitoring prüfen (15–20)

15. Reverse DNS (PTR) ist für jede IP konfiguriert, die E-Mails versendet. Viele empfangende Mailserver lehnen E-Mails von IPs ohne passenden PTR-Eintrag ab oder markieren sie als Spam, und PTR ist ein grundlegendes Anti-Spoofing-Signal.

16. Transfersperre und 2FA sind beim Registrar aktiviert. Eine Transfersperre verhindert unautorisierte Transfers weg von deinem Registrar, und die Zwei-Faktor-Authentifizierung (2FA) für das Konto verhindert Übernahmen durch Credential Stuffing.

17. Der Zugriff auf den DNS-Provider ist kontrolliert und protokolliert. Jeder mit Schreibzugriff auf deine Zone kann Traffic oder E-Mails umleiten. Nutze Rollen nach dem Least-Privilege-Prinzip und prüfe, ob Änderungen an Einträgen in einem Audit-Log erfasst werden.

18. Certificate-Transparency-Logs werden auf gefälschte Ausstellungen überwacht. Jedes öffentlich vertrauenswürdige Zertifikat wird in Certificate-Transparency (CT)-Logs protokolliert. Wenn du die CT-Logs für deine Domain beobachtest, fällt dir ein ohne dein Wissen ausgestelltes Zertifikat auf – selbst eines von einer zugelassenen CA.

19. Ablauf von Domain und DNSSEC-Schlüsseln wird proaktiv verfolgt. Eine abgelaufene Domain und ein nicht rotierter DNSSEC-Signaturschlüssel legen beide eine Live-Website lahm. In unserem Leitfaden So sicherst du dir eine auslaufende Domain erfährst du, was passiert, wenn du das Zeitfenster verpasst.

20. Die DNS-Gesundheit wird regelmäßig geprüft, nicht erst nach einem Vorfall. Führe regelmäßig einen vollständigen Lookup-Durchlauf – A, AAAA, MX, TXT, NS, CAA – gegen deine Live-Zone durch, statt nur dann, wenn etwas kaputtgeht. Kombiniere das mit Uptime- und Zertifikats-Monitoring, damit ein Ausfall auf DNS-Ebene sofort sichtbar wird; wie das zusammenpasst, erfährst du in Website-Monitoring erklärt.

Übersichtstabelle: alle 20 DNS-Checks

TipFühre die Checks 3, 4, 6 und 10 zuerst durch – CAA, SPF, DMARC und offene Zonentransfers sind die Punkte auf dieser Liste mit der größten Wirkung und dem schnellsten Fix.

Alle 20 Checks manuell für mehrere Domains durchzugehen, wird schnell mühsam – besonders, wenn du Einträge bei mehreren Registraren und Providern verwaltest. Mit den DNS-Funktionen von InfraNest prüfst und verwaltest du Einträge, DNSSEC und CAA-Richtlinien in einem einzigen Dashboard – starte mit einem schnellen Durchlauf über das kostenlose DNS-Lookup-Tool für jede Domain, für die du verantwortlich bist.