Was das DNS-Modul an Ihrer Zone prüft: Nameserver-Ausfallsicherheit, Adress-Records, CAA, SOA-Hygiene, offene Zonentransfers und Routing-Sicherheit – mit Bewertung und konkreter Behebung.
Jetzt Domain prüfen →
Stand: Juli 2026 · 14 Checks dokumentiert
Anzahl autoritativer Nameserver #
Mehrere Nameserver sorgen für Ausfallsicherheit bei der DNS-Auflösung. Fällt der einzige NS aus, ist die gesamte Domain (Web + Mail) offline.
Bewertungpass bei ≥ 2 Nameservern; warn bei genau einem (Single Point of Failure); fail bei keinem oder einer Lame Delegation (ein NS ohne A/AAAA). Gewicht 2.
BehebungMindestens zwei Nameserver betreiben – möglichst getrennt nach Netz/Standort (RFC 2182).
Nameserver über IPv6 erreichbar #
IPv6-fähige Nameserver stellen die Auflösung auch für IPv6-only-Clients sicher.
Bewertungpass, wenn mindestens ein NS eine AAAA-Adresse hat; sonst warn. Gewicht 1.
BehebungMindestens einen Nameserver auch über IPv6 anbinden.
Nameserver-Adressen (Routbarkeit & Reverse DNS) #
Zwei Hygiene-Prüfungen auf Adressebene für die autoritativen Nameserver (Zonemaster ADDRESS01-03). Erstens muss jede Nameserver-IP global routbar sein – eine private/reservierte/Bogon-Adresse (z. B. eine im Glue zurückgebliebene RFC-1918-Adresse) ist aus dem öffentlichen Internet nicht erreichbar und bricht die Auflösung für externe Clients. Zweitens sollte jede IP Forward-Confirmed Reverse DNS (FCrDNS) haben: einen PTR-Record, dessen Hostname wiederum zurück auf dieselbe IP auflöst. FCrDNS auf einem Nameserver ist ein Best-Practice-Hygiene-Signal, keine Sicherheitskontrolle.
Bewertungfail (Gewicht 2), wenn eine Nameserver-Adresse nicht global routbar ist (privat/reserviert/Bogon). Andernfalls ein grüner Haken (good, nicht benotet), wenn jede Adresse Forward-Confirmed Reverse DNS hat, und info, wenn eine oder mehrere Adressen keinen bestätigten PTR haben – Letzteres ist nur Best Practice und wird nicht abgewertet, da es kein Sicherheitsgewicht trägt und große Anycast-Betreiber es häufig weglassen. Der Drill-down listet jede Nameserver-IP mit Routbarkeit, PTR und dem Ergebnis der Forward-Bestätigung.
BehebungFür autoritative Nameserver nur öffentliche, global routbare Adressen verwenden. Optional für jede Nameserver-IP einen PTR-Record anlegen, dessen Hostname zurück auf diese IP auflöst.
Offener Zonentransfer (AXFR) #
AXFR (RFC 5936) ist der DNS-Mechanismus, der eine komplette Zone vom Primary auf seine sekundären Nameserver kopiert. Er muss auf autorisierte Secondaries beschränkt sein. Ein Nameserver, der AXFR für jedermann beantwortet, lässt Fremde die vollständige Zone herunterladen – jeden Hostnamen, jede Sub-Delegation und jeden internen Record – ein klassisches Information-Disclosure-/Reconnaissance-Problem (Zonemaster NAMESERVER03). Der Scanner sendet eine echte AXFR-Anfrage über TCP/53 an jeden Nameserver über beide Adressfamilien (IPv4 und IPv6) – die Zugriffskontrolle gilt je Listener, ein Server kann also über eine Familie ablehnen und über die andere offen sein – und klassifiziert nur die Antwort; die Zoneninhalte werden nie gespeichert.
Bewertungfail (Gewicht 2), wenn eine Nameserver-Adresse auf die unauthentifizierte Anfrage Zonendaten zurückliefert. Ein grüner Haken (good, nicht benotet), wenn jede erreichbare Adresse ablehnt (REFUSED/NOTAUTH/FORMERR/leer). Übersprungen (skip), wenn kein Nameserver vom Scanner aus über TCP/53 erreichbar ist (z. B. gefilterter Egress) – so wird nie fälschlich ein pass oder fail gemeldet. Der Drill-down listet das Ergebnis pro Nameserver-Adresse (IPv4 und IPv6).
BehebungAXFR nur auf die vorgesehenen Secondaries beschränken (allow-transfer / TSIG / Firewall-ACL) oder ganz deaktivieren, wenn kein Secondary vom Server zieht.
Nameserver-Verteilung (RFC 2182) #
Teilen sich alle Nameserver dasselbe Netz/denselben Betreiber, ist die Redundanz nur scheinbar – ein Ausfall dort trifft alle gleichzeitig. RFC 2182 empfiehlt daher topologisch verteilte Secondaries. Das stärkste praktische Signal für ein gemeinsames Ausfallrisiko ist das autonome System (AS): Nameserver in verschiedenen AS teilen weder Routing- noch Betriebsrisiko (Zonemaster CONNECTIVITY03).
BewertungBewertet wird primär auf AS-Ebene: pass, wenn die Nameserver auf mindestens zwei verschiedene autonome Systeme auflösen; warn, wenn alle in einem einzigen AS sitzen (Gewicht 1). Gehören alle Nameserver zu einem bekannten globalen Anycast-Anbieter (Cloudflare, AWS Route 53, NS1, Google, Azure, Akamai, …), wird ein einzelnes AS weltweit announced und ist KEIN Single Point of Failure – dann wird info statt warn gemeldet. Die AS-Abfrage deckt beide Adressfamilien ab, sodass ein Nameserver, dessen IPv4 anycast-einzel-AS ist, dessen IPv6 aber in einem anderen AS liegt, für diese Diversität angerechnet wird. Sind keine AS-Daten verfügbar, fällt der Check auf den gröberen Netz-Näherungswert zurück, je Familie bewertet (IPv4 /24 und IPv6 /48; pass, wenn eine der Familien ≥ 2 verschiedene Netze umfasst, warn, wenn jede Familie in einem einzigen sitzt – ein v4 /24 und ein v6 /48 desselben Standorts teilen das Ausfallrisiko und werden nie gegeneinander gezählt). Informativ, wenn weniger als zwei Nameserver-Adressen auflösbar sind. Der Drill-down listet jeden Nameserver mit seinen IPv4- und IPv6-Adressen, autonomen System(en), /24- und /48-Netzen und erkanntem Anycast-Anbieter.
BehebungNameserver über verschiedene autonome Systeme verteilen (idealerweise verschiedene Anbieter oder ein Secondary-DNS-Dienst).
IP-Adressen (A / AAAA) #
Der A-Record zeigt auf die IPv4-Adresse des Webservers, der AAAA-Record auf seine IPv6-Adresse. IPv6-Erreichbarkeit wird zunehmend erwartet (und z. B. von internet.nl gefordert) – ohne AAAA bleiben IPv6-only-Clients ausgeschlossen. Der Drill-down zeigt IPv4- und IPv6-Adressen mit ihrem Reverse DNS (PTR).
Bewertungpass, wenn ein AAAA-Record (IPv6) vorhanden ist – auch bei IPv6-only-Domains, mit oder ohne A-Record; warn bei nur IPv4 (kein IPv6); info, wenn gar keine Adress-Records existieren (z. B. www-only-Setups). Gewicht 1.
BehebungEinen A-Record (oder ALIAS/ANAME) und einen AAAA-Record auf die Adressen des Servers setzen.
CNAME am Zonen-Apex #
RFC 2181 §10.1 verbietet einen CNAME neben anderen Daten am selben Namen. Der Apex muss SOA- und NS-Records tragen, ein CNAME am Apex erzeugt also eine widersprüchliche Zone. Je nach Resolver bricht das die Mailzustellung (MX-Lookups), DNSSEC und teilweise die Auflösung der gesamten Domain.
Bewertungfail (Gewicht 2) – wird nur angezeigt, wenn der gescannte Name die registrierbare Domain (Zonen-Apex) ist und tatsächlich einen CNAME hat. Ein CNAME auf einem Hostnamen wie www.example.com ist ein völlig normaler Alias (CDN-Setup) und wird nicht abgewertet.
BehebungDen CNAME am Apex durch reguläre A-/AAAA-Records ersetzen oder das ALIAS/ANAME/CNAME-Flattening-Feature des DNS-Providers nutzen, das am Apex echte Adressen ausliefert.
HTTPS-Record (SVCB, RFC 9460) #
Ein DNS-HTTPS-Record kündigt die Protokoll-Unterstützung (alpn=h3,h2) bereits bei der Namensauflösung an: Browser verbinden sich schon beim ALLERERSTEN Request per HTTP/3 (QUIC), statt es erst über Alt-Svc zu entdecken, und moderne Browser werten die bloße Existenz als authentifiziertes HTTPS-Upgrade-Signal (besonders mit DNSSEC).
Bewertunghellgrüner Haken (good, Gewicht 0), wenn vorhanden; info, wenn nicht vorhanden – der Record ist eine optionale Optimierung, keine Sicherheitsanforderung.
BehebungHTTPS 1 . alpn=h3,h2 (Service-Modus, Ziel . = gleicher Name) für die Domain und www veröffentlichen; h3 nur eintragen, wenn der Server tatsächlich HTTP/3 anbietet.
RPKI (Route Origin Validation) #
RPKI signiert kryptografisch, welches autonome System (AS) ein IP-Präfix per BGP announcen darf (ROA = Route Origin Authorization). Das schützt davor, dass Traffic zur Server-IP per Route-Hijacking umgeleitet wird. Geprüft über die öffentliche RIPEstat-API.
Bewertungpass bei RPKI „valid“ (ROA vorhanden, Announcement autorisiert); info bei „unknown“ (keine ROA) – häufig und vom Hosting-/Netzbetreiber kontrolliert, senkt die Note daher nicht; fail bei „invalid“ (Announcement widerspricht einer bestehenden ROA). Gewicht 1.
BehebungVom Netzbetreiber/Hosting-Provider eine gültige ROA für das IP-Präfix anlegen lassen (per RPKI signieren).
Mailserver (MX-Records) #
MX-Records benennen die Server, die E-Mail für die Domain annehmen.
Bewertungpass, wenn MX-Records vorhanden sind; sonst info (die Domain empfängt vermutlich keine Mail). Gewicht 1.
BehebungWenn die Domain Mail empfangen soll, MX-Records setzen; andernfalls Null MX erwägen.
MX-Ziele gültig #
Ein MX-Record muss auf einen Hostnamen mit eigenen Adress-Records zeigen. RFC 5321 §5.1 verbietet IP-Adress-Literale als MX-Ziel, RFC 2181 §10.3 verbietet CNAME-Aliasse – beides verwirrt oder bricht einen erheblichen Teil der sendenden MTAs. Ein Ziel ganz ohne A/AAAA-Record macht die Mailzustellung unmöglich.
Bewertungfail, wenn ein MX-Ziel ein IP-Literal ist oder auf gar keine Adresse auflöst; warn, wenn das Ziel ein CNAME-Alias ist; sonst pass. Gewicht 1. Geprüft werden bis zu 4 MX-Hosts; bei Null MX nicht anwendbar.
BehebungJeden MX auf einen einfachen Hostnamen mit eigenen A/AAAA-Records zeigen lassen – keine IP-Adressen, keine CNAMEs.
CAA-Records #
CAA legt fest, welche Zertifizierungsstellen Zertifikate für die Domain ausstellen dürfen – das senkt das Risiko von Fehlausstellung/Missbrauch. Die Records werden gemäß RFC 8659 geparst: issue beschränkt die reguläre Ausstellung, issuewild die Wildcard-Ausstellung, iodef benennt eine Meldeadresse für abgelehnte Anfragen.
Bewertungpass, wenn CAA gesetzt ist; info, wenn nicht vorhanden – CAA ist ein Härtungs-Bonus, keine Pflicht, ein fehlender Record senkt die Note daher nicht. Gewicht 1. Bei Hostnamen zählt auch ein von der registrierbaren Domain geerbtes CAA als pass – CAs steigen gemäß RFC 8659 §3 den DNS-Baum hinauf. Ein vorhandenes, aber fehlkonfiguriertes Set warnt weiterhin bei zwei Stolperfallen: einem Critical-Flag (128) auf einem unbekannten Tag (CAs, die es nicht verstehen, müssen JEDE Ausstellung verweigern, §4.1 – blockiert Verlängerungen) und issuewild ohne issue (die Nicht-Wildcard-Ausstellung bleibt dann unbeschränkt, §4.3).
BehebungCAA-Records setzen, z. B. 0 issue "letsencrypt.org" und ein 0 iodef "mailto:…", um über unautorisierte Ausstellungsversuche benachrichtigt zu werden.
CAA für S/MIME (issuemail) #
Die issuemail-Property (RFC 9495) legt fest, welche CAs S/MIME-(E-Mail-)Zertifikate für die Domain ausstellen dürfen. Sie ist unabhängig von issue/issuewild, die nur TLS-/sonstige Zertifikate regeln und S/MIME nicht abdecken. Ein leerer Wert – 0 issuemail ";" – verbietet die S/MIME-Ausstellung vollständig; ist keine issuemail-Property vorhanden, ist die S/MIME-Ausstellung per CAA nicht beschränkt. Die Wert-Syntax ist identisch zu issue (eine Aussteller-Domain, optional gefolgt von ;-Parametern).
BewertungNicht separat bewertet – das Einschränken von S/MIME-Ausstellern ist optional und spezifisch. Da issuemail ein registriertes CAA-Tag ist, wird ein kritischer (Flag 128) issuemail-Record nicht als kritisches unbekanntes Tag gewertet. Beachten Sie jedoch: jede CA, die issuemail nicht versteht, muss bei gesetztem Critical-Flag jede Ausstellung ablehnen – auch TLS (RFC 9495 §6). Belassen Sie das Flag daher bei 0, sofern nicht jede genutzte CA issuemail nachweislich versteht. Der CAA-Generator kann issuemail-Records erzeugen, und „Aktuellen Record laden“ zeigt die S/MIME-Aussteller.
BehebungNur Ihren S/MIME-Anbieter erlauben, z. B. 0 issuemail "certum.pl"; S/MIME komplett verbieten mit 0 issuemail ";". Das Flag bei 0 (non-critical) belassen, sofern nicht jede genutzte CA issuemail versteht.
SOA-Record (Zonen-Konfiguration) #
Der SOA-Record markiert den Beginn der Zone; sein Fehlen deutet auf eine fehlerhafte Delegation hin. Das letzte SOA-Feld ist die Negative-Cache-TTL (RFC 2308) – so lange merkt sich JEDER Resolver „dieser Record existiert nicht“, ein riesiger Wert verzögert also tatsächlich neu angelegte Records. Die refresh-/retry-/expire-Timer steuern dagegen nur den klassischen Primary→Secondary-Zonentransfer (AXFR); Anycast- und API-getriebenes Managed DNS (Google, Cloudflare, Route 53, …) setzt sie beliebig und funktioniert einwandfrei – sie werden daher nur als informative Hinweise gemeldet und nicht abgewertet.
Bewertungpass, wenn der SOA vorhanden und die Negative-Cache-TTL vernünftig ist; warn nur bei einer Negative-Cache-TTL über einem Tag; fail, wenn kein SOA-Record existiert. Das Verhältnis von refresh/retry/expire und eine Serial von null werden nur als informative Hinweise angezeigt (sie sind ausschließlich für zonentransfer-basierte Secondaries relevant). Gewicht 1.
BehebungPrüfen, ob die Zonen-Delegation korrekt ist. Die Negative-Cache-TTL (letztes SOA-Feld) bei etwa 1–3 h halten (RFC 2308 §5); die übrigen Timer sind nur relevant, wenn traditionelle AXFR-basierte Secondaries betrieben werden.