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: September 2026 · 20 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. RFC 2182 §5 sagt es ausdrücklich: „The DNS specification and domain name registration rules require at least two servers for every zone“ — und rät zu mehr, weil eine Zone mit zwei eingetragenen Servern schon beim Ausfall eines einzigen nur noch auf einem läuft.
Bewertungpass bei ≥ 2 Nameservern; warn bei genau einem (Single Point of Failure); fail bei keinem — oder wenn ein delegierter Nameserver weder einen eigenen A- noch einen AAAA-Record hat und beide Abfragen eindeutig zurückkamen: Ein Resolver, der diesen Namen nachschlägt, erreicht ihn dann nicht (die Ausnahme ist eine Adresse, die nur als Glue in der Elternzone steht). Der Begriff „Lame Delegation“ wird hier bewusst vermieden: RFC 9499 §7 hält fest, dass er sich von seiner ursprünglichen Bedeutung entfernt hat, nicht mehr eindeutig ist und „should be considered historic and avoided in favor of terms that are specific and clear“ — und führt sowohl einen nicht auflösbaren Nameserver als auch einen Server, der ohne Authoritative-Answer-Flag antwortet, unter den abgedrifteten Verwendungen auf. Ob die erreichbaren Server autoritativ antworten, wird getrennt gemessen, bei den Direktabfragen an die Nameserver der Zone. Gewicht 2.
BehebungMindestens zwei Nameserver betreiben – möglichst getrennt nach Netz/Standort (RFC 2182).
Nameserver mit IPv6-Adresse (AAAA) #
Ein IPv6-only-Resolver erreicht eine Zone nur, wenn ihre Nameserver AAAA-Adressen haben. Diese Prüfung liest die AAAA-Records der delegierten Nameserver — sie öffnet keine Verbindung und zeigt damit Veröffentlichung, nicht Erreichbarkeit: Eine Adresse, die veröffentlicht ist, aber auf Port 53 nicht antwortet, besteht hier trotzdem. Kein RFC verlangt AAAA für autoritative Nameserver, und es wird hier auch nicht als Verstoß benotet; standardisiert ist die Gegenrichtung, in RFC 3901 (BCP 91) §4: „every DNS zone SHOULD be served by at least one IPv4-reachable authoritative name server“ — damit eine IPv6-only-Delegation den Namensraum nicht fragmentiert.
Bewertungpass, wenn mindestens ein Nameserver einen AAAA-Record veröffentlicht; warn, wenn mindestens eine AAAA-Abfrage eindeutig zurückkam und kein Nameserver einen hat; übersprungen („nicht messbar“, ohne Abzug), wenn keine einzige AAAA-Abfrage zu den Nameservern eindeutig war — eine gescheiterte Abfrage von uns ist kein fehlender Record. Die Wertzeile lautet „mit AAAA / gemessen“: Der Nenner ist die Menge der Nameserver, deren AAAA-Antwort eindeutig war, nicht die Zahl der Nameserver. 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 und ADDRESS02, Stand 2026-08 — ausdrücklich nicht ADDRESS03, das den PTR-Hostnamen mit dem Namen des Nameservers selbst vergleicht; das verlangt diese Prüfung nicht). 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. Die Forward-Bestätigung wird vierwertig geführt: bestätigt, gemessen-und-nicht-vorhanden, nicht ermittelt und gar nicht abgefragt — eine Reverse-Abfrage von uns ohne eindeutige Antwort (auch REFUSED, bei Reverse-Delegationen häufig) zählt als Drittes und nie als fehlender PTR; das Vierte ist eine Grenze des Scans, nicht des Resolvers: Die Reverse-Abfragen sind optionale Arbeit, nach Aufbrauchen des Zeitbudgets dieses Abschnitts werden sie nicht mehr gesendet, und der Bericht sagt das, statt ein Ergebnis zu nennen. Beide können die Note nicht senken, und der grüne Haken verlangt, dass jede Adresse gemessen wurde. Der Drill-down listet die geprüften Nameserver-IPs — die ersten acht Nameserver nach Namen, je höchstens vier Adressen pro Familie und insgesamt 32 — mit Routbarkeit, PTR und dem Ergebnis der Forward-Bestätigung. Die Zahlen im Urteil beziehen sich auf diese Stichprobe.
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. RFC 5936 §5 überlässt die Zugriffsentscheidung dem Zonenbetreiber — der Abschnitt beginnt mit „A zone administrator has the option to restrict AXFR access to a zone“ und verlangt von einer Allzweck-Implementierung, AXFR an jeden ausliefern zu können —, sagt aber zugleich, eine solche Implementierung „SHOULD NOT have a default policy for AXFR requests to be ‘open to all’“; das ist eine Empfehlung an die Implementierung und ihre Voreinstellung, nicht eine Pflicht des Betreibers. Die Empfehlung, Transfers auf die vorgesehenen Secondaries zu beschränken, stammt aus NIST SP 800-81r3. Ein offener AXFR ist also kein Protokollverstoß, sondern eine Abweichung von der empfohlenen Voreinstellung mit realen Kosten. 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 über beide Adressfamilien. Der Mechanismus, den §5 zum Gewähren von Zugriff nennt, ist die Quelladresse des Clients („An implementation SHOULD allow access to be granted to Internet Protocol addresses and ranges“, daneben schlüsselbasiert TSIG und SIG(0)), und eine Verweigerung über IPv4 belegt keine Verweigerung über IPv6 — deshalb werden beide geprobt und nicht nur eine. Die Probe ist eine stabile Stichprobe, keine vollständige Abdeckung: die ersten acht Nameserver nach Namen, je eine Adresse pro Familie, höchstens sechzehn Proben. Klassifiziert wird 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 Adresse, die geantwortet hat, die Herausgabe von Zonendaten abgelehnt hat. Das ist die Messung — „Transfers sind auf autorisierte Secondaries beschränkt“ ist die daraus gezogene Folgerung, und der Drill-down nennt den RCODE, damit sich beides auseinanderhalten lässt: REFUSED(5) ist das, wonach Zugriffskontrolle in der Praxis aussieht, und NOTAUTH(9) einer der beiden Codes, die RFC 5936 §2.2.1 Note e) für eine AXFR-Antwort definiert, während FORMERR, SERVFAIL oder NOTIMP ebenfalls nichts offenlegen, aber etwas über die Anfrage oder den Server sagen und nicht über eine Zugriffsregel (Note e) nennt sie generische Fehler, „not set as part of the AXFR-specific response processing“). Übersprungen (skip) in drei Situationen, die alle Grenzen der Messung sind und nie ein Urteil: Keine Nameserver-Adresse hat auf TCP/53 überhaupt geantwortet (z. B. gefilterter Egress); jede Nameserver-Adresse ist eine, zu der dieser Scanner keine Verbindung aufbaut; oder jede Adresse hat die Verbindung angenommen und dann ohne Antwort beendet — was ausdrücklich NICHT „keine Route“ heißt, denn die Verbindungen standen. Die drei werden im Text auseinandergehalten. Eine Adresse, die die Verbindung angenommen und dann ohne Antwort geschwiegen hat, zählt weder als verweigernd noch als offen: Unser eigenes Schweigen ist nicht die Verweigerung des Servers. Die gemeldete Record-Zahl ist der Answer-Count der ERSTEN Antwortnachricht und damit eine Untergrenze – der Drill-down sagt „mindestens“. Der Drill-down listet das Ergebnis pro Nameserver-Adresse (IPv4 und IPv6), auch für Adressen, die bewusst nicht kontaktiert wurden.
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 von außen beobachtbare, nützlichste Signal ist das Origin-AS, aus dem jede Adresse announced wird — genau das prüft Zonemaster CONNECTIVITY03 („all IP addresses … are announced from different ASNs“). Es ist ein Näherungswert und kein Beweis: Zwei AS können demselben Betreiber gehören oder am selben Upstream bzw. Internet-Exchange hängen, und RFC 2182 §3.1 verlangt topologische und geografische Streuung, „to minimise the likelihood of a single failure disabling all of them“ — keine Anzahl von AS.
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 dieses eine AS weltweit von vielen Standorten aus announced; in dem Routing-Sinn, den diese Prüfung misst, ist es damit kein Single Point of Failure, und es wird info statt warn gemeldet. Der Anbieter selbst bleibt eine gemeinsame Abhängigkeit — ein Fehler in seiner Steuerungsebene oder Konfiguration kann alle Standorte zugleich erreichen, und keine externe Prüfung sieht das. Diese Ausnahme stützt sich auf eine kuratierte Liste von Nameserver-Hostnamen; ein Betreiber, der nicht auf der Liste steht, wird als gebündelt bewertet, auch wenn er von vielen Standorten weltweit announct. Das Finding benennt diese Grenze dort, wo es das warn vergibt, denn ein Vorbehalt ist nur so vollständig wie die Liste, aus der er entsteht. Die AS-Abfrage deckt beide Adressfamilien ab und zählt die Vereinigung der Origin-AS über beide hinweg. Das weicht bewusst von Zonemaster CONNECTIVITY03 (Stand 2026-08) ab, das IPv4 und IPv6 getrennt bewertet und verlangt, dass beide bestehen — und es ist die schwächere Regel: Ein zweites AS, das es nur unter IPv6 gibt, nützt einem Resolver nichts, der nur IPv4 spricht. Gibt es das zweite AS nur über die Familien hinweg — trägt also weder IPv4 noch IPv6 für sich mehr als eines —, sagt das Finding das und nennt die AS je Familie. Es bleibt bestanden, weil ein Dual-Stack-Resolver einen Routing-Ausfall in einem der beiden AS wirklich übersteht und das wirklich gemessen ist; zurückgezogen wird dort die Behauptung, kein einzelner Routing-Ausfall könne die Zone offline nehmen, denn ein Resolver mit nur einer Familie sieht ein AS. Der Netz-Näherungswert weiter unten wird bewusst nicht über die Familien vereinigt, und das ist kein Widerspruch: Ein v4 /24 und ein v6 /48 derselben Maschine zählen denselben Standort doppelt, während zwei Origin-AS zwei Routing-Domänen sind, gleich welche Familie sie announct. Auf AS-Ebene wird bewertet, sobald mindestens zwei Nameserver auf ein autonomes System aufgelöst haben — das müssen nicht alle sein: Eine Abfrage kann scheitern, und ein Nameserver ohne eigene Adresse wird gar nicht erst gefragt. Fehlen welche, zählt der Wert die gemessenen Nameserver statt aller, das Finding benennt die ausgelassenen, und die Note bleibt stehen: Die gemessenen Server liegen wirklich dort, wo es sagt, und einer Teilmessung Gewicht zu entziehen ist der Weg, auf dem ein Bericht mit weniger Messung besser abschneidet. 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 sich die Verteilung überhaupt nicht bewerten lässt — also wenn für weniger als zwei Nameserver ein autonomes System ermittelt werden konnte (die Abfrage kann auch schlicht scheitern) und keine Adressfamilie zwei oder mehr Adressen über mindestens zwei Nameserver hinweg hat; übersprungen statt informativ, wenn die NS-Abfrage selbst keine eindeutige Antwort lieferte, denn dann gab es keine Nameserver-Liste, deren Verteilung sich bewerten ließe, und eine Zählung von null wäre eine Messung, die niemand vorgenommen hat. Ein einzelner Nameserver mit zwei Adressen bleibt deshalb informativ: Eine zweite Adresse ist kein zweiter Server, und RFC 1034 §4.1 verlangt eine Zone auf mindestens zweien. 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-Unterstützung wird zunehmend erwartet – ohne AAAA erreicht ein IPv6-only-Client die Seite nur über eine Übersetzung (NAT64/DNS64, RFC 6146/6147, im Mobilfunk der Normalfall), und wo es keine gibt, bleibt er ausgeschlossen; internet.nl bewertet IPv6 in einer eigenen Testkategorie. Der Drill-down zeigt bis zu acht Adressen (die ersten vier je Familie, der Rest aufgefüllt aus der Familie mit den meisten) mit ihrem Reverse DNS (PTR). Die PTR-Spalte ist dreiwertig: ein Name, „kein PTR-Record“ nur bei eindeutiger Reverse-Antwort, sonst „nicht ermittelbar“ — eine REFUSED-Antwort, bei Reverse-Delegationen häufig, zählt als Drittes und nie als fehlender PTR. Hat eine Adresse mehrere PTR-Namen, werden die weiteren als „+N weitere“ zusammengefasst.
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. Das Wissen über die beiden Familien wird getrennt geführt: Records, die zurückkamen, belegen sich selbst — jede ABWESENHEITS-Aussage („kein AAAA“, „gar keine Adress-Records“) braucht dagegen eine eindeutige Antwort für genau diese Familie, und ohne sie wird die Prüfung übersprungen statt benotet. Das gilt auch für die Empfehlung: „IPv6 bereitstellen“, gesagt zu einer Domain, deren AAAA-Abfrage nur fehlschlug, ist ein Rat, der befolgt wird.
BehebungEinen A-Record (oder ALIAS/ANAME) und einen AAAA-Record auf die Adressen des Servers setzen.
CNAME am Zonen-Apex #
Nach RFC 2181 §10.1 trägt ein Name entweder einen CNAME oder andere Records, nie beides — die einzige dort genannte Ausnahme sind DNSSEC-Records an einem Alias, und RFC 4035 §2.5 verengt sie auf RRSIG und NSEC; deshalb kollidiert ein Apex-CNAME auch mit DNSKEY. Der Apex muss SOA und NS führen, ein CNAME am Apex erzeugt also eine widersprüchliche Zone: Er kollidiert mit diesen beiden und mit jedem weiteren Record-Typ an diesem Namen — MX, TXT und den DNSSEC-Records. Die Adressauflösung selbst folgt dem CNAME anstandslos; deshalb zeigt sich das Problem meist als gebrochene Mailzustellung oder gebrochenes DNSSEC und nicht als Seite, die nicht lädt. Der übliche Ausweg ist ein Provider-Feature (ALIAS/ANAME/CNAME-Flattening) — ein Anbieter-Mechanismus, kein Standard. Ein HTTPS 0 target.-Record nach RFC 9460 ist kein Ersatz: Anhang C.3 hält fest, dass es nötig bleibt, Adress-Records am Apex zu führen — für Clients, die den Typ 65 nicht abfragen, und §2.4.2 erwartet, dass Betreiber sie neben dem SVCB-Record behalten. Beides ist Betriebsempfehlung und keine RFC-2119-Pflicht, und C.3 erlaubt ausdrücklich, sie fallen zu lassen, sobald dieser Verkehr vernachlässigbar wird.
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. Ob ein Name ein Apex ist, wird gegen die Public Suffix List entschieden — ein Name direkt unter einem mehrteiligen Suffix (user.github.io, example.pages.dev) zählt deshalb als Apex, denn er ist einer. Gibt die Liste keine Antwort — sie ist nicht mitgeliefert, oder der geprüfte Name ist selbst ein Public Suffix und hat damit keine registrierbare Domain —, entscheidet die Zonenerkennung dieses Scans. Ist auch die gescheitert, wird das Finding nicht erzeugt: Ein Gewicht-2-Fehler wird nicht auf einer Vermutung behauptet, und sein Fehlen heißt dann „nicht festgestellt“, nicht „in Ordnung“.
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.
DNAME am Zonen-Apex #
Ein DNAME-Record (RFC 6672) leitet einen ganzen Teilbaum um: Jeder Name unterhalb seines Owners wird aus dem entsprechenden Namen unterhalb des Ziels beantwortet, der Owner selbst behält seine eigenen Records (§2.3: „the owner name of a DNAME is not redirected itself“). Am Zonen-Apex ist das – anders als ein CNAME – erlaubt und typisch für eine Domain, die ihre Hostnamen unter einen anderen Namen umgezogen hat. Es heißt zugleich, dass direkt unterhalb des Apex nichts mehr veröffentlicht werden kann: Solche Records sind verdeckt (§2.4), und ein CNAME am selben Namen ist verboten.
Bewertunginfo (Gewicht 0) – wird nur angezeigt, wenn der gescannte Name die registrierbare Domain (Zonen-Apex) ist und einen DNAME veröffentlicht. Nicht bewertet: Ob die Umleitung beabsichtigt ist, kann ein Scan nicht wissen. Eine fehlgeschlagene Abfrage behauptet nichts.
BehebungNichts zu tun, wenn die Umleitung beabsichtigt ist. Prüfen, dass die Zielzone die erwarteten Hostnamen (www, mail, autodiscover, …) führt, denn die Namen unterhalb des Apex werden nicht mehr aus der eigenen Zone beantwortet.
HTTPS-Record (SVCB, RFC 9460) #
Ein DNS-HTTPS-Record kündigt die Protokoll-Unterstützung (alpn=h3,h2) bereits bei der Namensauflösung an: Chrome und Firefox verbinden sich schon beim ALLERERSTEN Request per HTTP/3 (QUIC), statt es erst über Alt-Svc zu entdecken – sofern der Resolver des Browsers den Record geliefert hat –, und beide werten seine Existenz als HTTPS-Upgrade-Signal, das den ersten Klartext-Request spart. Authentifiziert ist es nicht: RFC 9460 §9.2.2 sagt, HTTPS-Records „do not require or provide any assurance of authenticity“, und §9.5, dass Clients dem Signal nicht mehr vertrauen dürfen als einer 307-Weiterleitung über Klartext-HTTP. DNSSEC authentifiziert den Record gegenüber einem validierenden Resolver — die Zusicherung, auf die ein Browser sich stützt, kommt aber aus der TLS-Verbindung. Ein Ersatz für HSTS ist der Record damit nicht. Er kann außerdem einen port tragen, der das Verbindungsziel von 443 wegschiebt (§7.2), und einen ech-Parameter — eine Encrypted-ClientHello-Konfiguration (RFC 9848). Browser mit ECH-Unterstützung verschlüsseln den Servernamen im TLS-Handshake; ein Beobachter im Netz sieht dann nicht mehr, welcher der Namen hinter einem gemeinsamen Front-End aufgerufen wird. §8 dieses RFC sagt ausdrücklich, dass der Schutz nur so weit reicht wie diese Anonymitätsmenge und den Servernamen „does not conceal … from the DNS resolver“.
Bewertunghellgrüner Haken (good, Gewicht 0), wenn vorhanden; info, wenn nicht vorhanden – der Record ist eine optionale Optimierung, keine Sicherheitsanforderung. Eine veröffentlichte Form ist info statt Gewinn: Ein AliasMode-Record mit der Wurzel als TargetName (HTTPS 0 .) kündigt die Abwesenheit eines Dienstes an und nicht die Abkürzung zu einem, denn RFC 9460 §2.5.1 gibt ihm genau diese Bedeutung — der Dienst „is not available or does not exist“ — und der nächste Satz macht die Ankündigung beratend, Clients dürfen sie also ignorieren und trotzdem verbinden. Liefert die Typ-65-Abfrage keine eindeutige Antwort, wird die Prüfung übersprungen, statt „nicht gesetzt“ zu melden, und es wird auch nicht geraten, einen zu veröffentlichen. Ein AliasMode-Record (Priorität 0) hat Vorrang vor jedem ServiceMode-Record derselben RRset (§2.4.1). Verpflichtende Schlüssel werden benannt: port und no-default-alpn sind automatisch verpflichtend (§9), und ein Client, der nicht jeden verpflichtenden Schlüssel umsetzt, ignoriert den Record vollständig — für ihn findet auch das https-Upgrade nicht statt (§8, §9.5). Ein Record, der gegen §2.2 verstößt (innerhalb eines SvcParam abgeschnitten, Schlüssel nicht streng aufsteigend, ein Schlüssel doppelt), wird als veröffentlicht-aber-nicht-lesbar gemeldet und nicht als fehlend — denn §2.2 verlangt von Clients, die gesamte RRset zu verwerfen und normal zu verbinden. Teilen sich mehrere ServiceMode-Records die niedrigste Priorität, sagt der Bericht das und wählt deterministisch: Eine RRset ist eine ungeordnete Menge (§2.4.1), und die Antwortreihenfolge schwankt zwischen Abfragen.
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 in BGP originieren darf (ROA = Route Origin Authorization). Netze, die Route Origin Validation durchsetzen, verwerfen dann Announcements, die der ROA widersprechen. Eine Garantie gegen Hijacking ist das nicht: RFC 7115 (BCP 185) §7 hält fest, dass „RPKI-based origin validation is expected to deal only with inadvertent mis-advertisement“ — das Origin-AS eines Updates ist selbst nicht signiert —, und dass Origin Validation „does not address the problem of AS_PATH validation“. 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. RPKI wird an den Adressen des geprüften Namens gemessen; lieferte die Adress-Abfrage keine eindeutige Antwort, gibt es keine Route zu prüfen: Die Prüfung wird dann als nicht messbar ausgewiesen, statt aus dem Bericht zu verschwinden — eine kürzere Liste liest sich wie „hier gibt es nichts zu melden“. Dasselbe gilt, wenn die Datenquelle selbst nicht antwortet: Liefert RIPEstat für keine der geprüften Adressfamilien eine brauchbare Antwort, steht dort „nicht testbar“. Beides ist ein skip, und ein skip verlässt die Bewertung vollständig — Punkte wie Nenner —, das Gewicht spielt in beiden Fällen also keine Rolle. Ließ sich nur EINE Adressfamilie ermitteln, behält das Urteil Note und Gewicht — die gemessene Hälfte trifft wirklich zu, und das Gewicht herauszunehmen ließe eine Note aus weniger Messung besser aussehen —, aber der Satz nennt die ungemessene Familie und sagt, dass er nur für die andere gilt. Jede unschlüssige Antwort von RIPEstat ist eine gescheiterte Anfrage, nie „keine ROA“: ein HTTP-Fehler, eine Antwort ohne Präfix oder AS und ein Validierungsstatus, den wir nicht lesen können, stehen alle als „nicht testbar“, und keine davon wird zwischengespeichert. Bei einem Namen, der eindeutig keine Adressen hat, bleibt der Eintrag aus; dort ist tatsächlich nichts zu prüfen.
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 — und eine leere MX-RRset heißt nicht, dass die Domain keine annimmt. RFC 5321 §5.1: „If an empty list of MXs is returned, the address is treated as if it was associated with an implicit MX RR, with a preference of 0, pointing to that host.“ Eine Domain mit Adress-Records und ohne MX empfängt also sehr wohl Mail, und zwar auf genau diesen Adressen. Die Absicht, keine zu empfangen, erklärt allein ein Null-MX-Record (0 ., RFC 7505).
Bewertungpass, wenn MX-Records vorhanden sind — ein Null MX eingeschlossen, denn ihn zu veröffentlichen ist eine gültige, vollständige Aussage; warn, wenn ein Null MX (Priorität 0 auf die Wurzel) neben echten MX-Records steht, was RFC 7505 §3 verbietet — und ebenso, wenn ein Record auf die Wurzel zeigt und dabei eine andere Priorität als 0 trägt, die derselbe Abschnitt wegdefiniert: Der Null MX ist Priorität 0 mit einem Label der Länge null, ein solcher Record erklärt also nichts und benennt keinen erreichbaren Host (der Abschnitt Mailserver-TLS & DANE sagt dasselbe über ihn); übersprungen, wenn die MX-Abfrage keine eindeutige Antwort lieferte, denn „keine Mailserver“ wäre dann eine Behauptung ohne Messung, und ebenso, wenn die RRset veröffentlicht war, sich aber kein Record darin lesen ließ — eine nicht lesbare Menge ist keine leere; sonst info. Gewicht 1. Der info-Fall deckt zwei Situationen ab, und der Bericht hält sie auseinander: Mit vorhandenen Adress-Records ist die Domain ihr eigener Mailexchanger (impliziter MX), und der Abschnitt Mailserver-TLS & DANE prüft diesen Host — es sei denn, seine Adressen gehören ausschließlich zu einem CDN-Edge-Netz; dorthin baut dieser Scanner auf Port 25 keine Verbindung auf, weil eine Adresse, die als eigener A-/AAAA-Record der Domain in einem CDN-Edge-Bereich steht, für die Website veröffentlicht wurde und nicht für Mail; ohne MX und ohne Adress-Records kann überhaupt nichts zugestellt werden. Zu beachten, wie die Adress-Records gelesen werden — das ist der eigene Schutz dieses Scanners und steht so nicht in RFC 5321 §5.1: Der Abschnitt regelt, wann der implizite MX überhaupt gilt, nicht was zu tun ist, wenn nur eine der beiden Adress-Abfragen antwortet: Antwortet eine Adressfamilie mit Adressen, genügt das für den impliziten MX, während „auch keine Adress-Records“ erst gesagt wird, wenn BEIDE Adress-Abfragen eindeutig zurückkamen. Vorhandensein braucht keine Vollständigkeit, Abwesenheit schon.
BehebungWenn die Domain Mail empfangen soll, MX-Records setzen — sie wegzulassen schaltet Mail nicht ab, sondern lenkt die Zustellung auf die eigenen A-/AAAA-Records der Domain (RFC 5321 §5.1). Soll sie keine empfangen, einen Null MX veröffentlichen (0 ., RFC 7505): Das ist die einzige Möglichkeit, das zu sagen, und eine andere Aussage als gar keinen MX-Record zu haben.
MX-Ziele gültig #
Ein MX-Record muss auf einen Hostnamen mit eigenen Adress-Records zeigen. RFC 5321 §5.1 formuliert es positiv: Das Datenfeld „MUST contain a domain name“, und „that domain name, when queried, MUST return at least one address record“. Eine in dieses Feld geschriebene IP-Adresse ist kein solcher Name — ein sendender MTA hat dort nichts nachzuschlagen. RFC 2181 §10.3 ergänzt, dass das Ziel kein Alias sein darf: „The domain name used as the value of a NS resource record, or part of the value of a MX resource record must not be an alias.“ Die dort genannten Kosten: Ein Alias wird in der Additional Section nicht aufgelöst, was „can cause extra queries, and extra network burden, on every query“ — wie ein einzelner Sender damit umgeht, legt der Standard nicht fest — RFC 5321 §5.1 sagt über einen Wert, der abgefragt ein CNAME liefert, er „lies outside the scope of this Standard“; deshalb ist dies eine Warnung und kein Fehler. Ein Ziel ganz ohne A/AAAA-Record macht die Mailzustellung unmöglich.
Bewertungfail, wenn ein MX-Ziel ein IP-Literal ist — oder wenn seine A- UND AAAA-Abfrage eindeutig und leer zurückkamen; warn, wenn das Ziel ein CNAME-Alias ist; pass, wenn jedes nachschlagbare Ziel ein Hostname mit Adress-Records ist; übersprungen, wenn sich keines der Ziele nachschlagen ließ. Ein Ziel, dessen Abfragen keine eindeutige Antwort ergaben, ist weder in Ordnung noch defekt: Es steht als „nicht geprüft“ in der Tabelle und geht nicht ins Urteil ein. Gewicht 1. Geprüft werden bis zu vier MX-Hosts, niedrigste Priorität zuerst; lautet das Urteil pass, nennt der Text die nicht erfassten Hosts. Bei Null MX nicht anwendbar, und ein Wurzelziel mit einer anderen Priorität als 0 wird hier gemeldet statt als Host behandelt.
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 Adresse, an die eine CA Meldungen über abgelehnte oder unautorisierte Anfragen senden soll — die Baseline Requirements des CA/Browser-Forums (§4.2.2.1) verpflichten CAs ausdrücklich nicht, auf den Inhalt zu reagieren; es ist also ein zusätzliches Signal, keine Überwachung. Einschränkend wirken nur issue und issuewild: Ohne issue-Property schränkt CAA die Ausstellung überhaupt nicht ein (RFC 8659 §3).
Bewertungpass nur, wenn das wirksame CAA-Set eine issue- oder issuewild-Property enthält — nur diese Tags schränken die TLS-Ausstellung ein (RFC 8659 §3), und geprüft wird das Tag, nicht der Wert: Ein bewusstes Totalverbot (0 issue ";") gilt damit als gesetzte Regel und besteht. Ein Set, das nur aus iodef, contactemail/contactphone oder issuemail besteht, startet bei info wie ein fehlendes Set, kann aber — anders als ein fehlendes — noch auf warn eskalieren, siehe unten; info, wenn nicht vorhanden – CAA ist ein Härtungs-Bonus, keine Pflicht, ein fehlender Record senkt die Note daher nicht; übersprungen, wenn die Abfrage keine eindeutige Antwort lieferte, denn „keine CAA-Records“ wäre dann eine Behauptung über eine Sicherheitsmaßnahme, die wir nicht gemessen haben. Gewicht 1. Bei Hostnamen wird der gesamte Namensbaum aufwärts durchsucht und das erste nicht-leere CAA-RRset gewertet, so wie CAs es tun (RFC 8659 §3). Dieser Aufstieg kostet eine Abfrage je Ebene und ist an das Zeitbudget dieses Scans für den Abschnitt gebunden: Muss er abgebrochen werden, wurden die Ebenen über dem Namen nicht abgefragt, und die Prüfung wird mit genau dieser Begründung übersprungen — nie als „keine CAA-Records gesetzt“ gemeldet. Ein vorhandenes, aber fehlkonfiguriertes Set warnt bei drei Stolperfallen. Erstens einem Critical-Flag (128) auf einem Property Tag, auf das eine TLS-CA nicht reagiert — §4.1 verlangt, bei einem kritischen Tag, das eine CA nicht kennt oder nicht unterstützt, JEDE Ausstellung zu verweigern; das umfasst nicht registrierte Tags, die drei von der IANA als Reserved geführten Namen (auth, path, policy) und registrierte Tags außerhalb des TLS-Namensraums wie issuemail oder issuevmc — Zweitens einem issue- oder issuewild-Wert, der nicht der Grammatik aus RFC 8659 §4.2 entspricht und wie ein leerer issuer-domain-name zu behandeln ist: auf einer issue-Property verbietet er jede Ausstellung, Erneuerungen eingeschlossen; auf einer issuewild-Property blockiert er nur die Wildcard-Ausstellung, denn §4.3 lässt issuewild bei Namen, die keine Wildcards sind, unbeachtet. Drittens mehr als einem accounturi-Parameter an einer Property, was RFC 8657 §3 unerfüllbar macht, sodass diese Property niemanden autorisiert — bei einer CA, die RFC 8657 umsetzt, was §5.2 zufolge vorher geklärt sein muss —, während eine zweite, erfüllbare issue-Property die Ausstellung weiterhin erlaubt, denn CAA-Autorisierungen sind additiv (RFC 8659 §4.2). Davon getrennt: issuewild ohne issue lässt die Nicht-Wildcard-Ausstellung unbeschränkt (§4.3) und wird ohne Notenabzug gemeldet, denn ein Satz ganz ohne CAA wird ebenfalls nicht benotet, und mehr zu tun darf nie schlechter abschneiden als nichts zu tun. Eine issue-Property mit leerem Wert ist ebenfalls keine Einschränkung, sondern ein bewusstes Totalverbot (§4.2) — und sie besteht, denn sie ist eine Regel, und zwar die strengste. Records, die sich nicht parsen lassen, werden gezählt und aufgeführt statt verworfen, und über ihren Inhalt wird nichts behauptet; die Empfehlung nennt den schwerwiegendsten gefundenen Zustand, nicht den zuerst geprüften.
BehebungCAA-Records setzen, z. B. 0 issue "letsencrypt.org", dazu ein 0 iodef "mailto:…" (oder eine https:-URL) als Adresse für Meldungen über unautorisierte Ausstellungsversuche — CAs sollen sie senden, müssen aber nicht darauf reagieren. Wer die Ausstellung zusätzlich mit RFC-8657-Parametern bindet (accounturi, validationmethods), sollte sich die Unterstützung von der CA bestätigen lassen: §5.2 sagt, eine Domain dürfe die Wirksamkeit ohne ausdrückliche Zusage der CA nicht annehmen; die Baseline Requirements des CA/Browser-Forums (§4.2.2.1.2) verlangen die Verarbeitung heute als SHOULD und ab dem 15.03.2027 als Pflicht (MUST) für öffentlich vertrauenswürdige CAs.
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, solange keine andere issuemail-Property eine CA benennt: CAA-Autorisierungen sind additiv, ein 0 issuemail ";" neben 0 issuemail "certum.pl" erlaubt Certum weiterhin die Ausstellung (RFC 9495 §5.4) – eine zweite, fehlerhafte Property ändert nichts, weil §4 auch einen fehlerhaften Wert als leeren issuer-domain-name liest. Ist gar keine issuemail-Property vorhanden, ist die S/MIME-Ausstellung per CAA nicht beschränkt (RFC 9495 §4). Die Wert-Syntax ist identisch zu issue (eine Aussteller-Domain, optional gefolgt von ;-Parametern).
BewertungKeine eigene Prüfung: issuemail wird als Teil des CAA-Findings ausgewertet, und dieser Eintrag erklärt diesen Teil. Das Einschränken von S/MIME-Ausstellern ist optional und spezifisch und wird deshalb nicht separat bewertet. Ein kritischer (Flag 128) issuemail-Record wird nicht als unbekanntes Tag bezeichnet — er ist bei der IANA registriert —, aber er wird sehr wohl gemeldet, und zwar aus dem Grund, aus dem es die Warnung gibt: RFC 8659 §4.1 verlangt von einer CA, bei einem kritischen Property Tag, das sie nicht kennt oder nicht unterstützt, jede Ausstellung zu verweigern — und registriert zu sein macht ein Tag nicht unterstützt. RFC 9495 §6 nennt die Folge für dieses Tag: „If a Certification Authority does not understand the Property, then it MUST NOT issue the certificate in question.“ Der Rat lautet deshalb, das Flag auf 0 zu setzen statt den Record zu löschen — belassen Sie es 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. Die Negative-Cache-TTL (RFC 2308) ist die Zeit, die ein Resolver sich „dieser Record existiert nicht“ merken darf; ein großer Wert verzögert also tatsächlich neu angelegte Records. Sie ist nicht einfach das letzte SOA-Feld: RFC 2308 §3 setzt sie auf den kleineren Wert aus dem MINIMUM-Feld und der TTL des SOA-Records selbst, und dieser kleinere Wert wird hier benotet — der Bericht nennt beide, wenn sie auseinanderliegen, und fällt auf MINIMUM allein zurück, wenn die Antwort keine brauchbare SOA-TTL trägt. §3 sagt, ein Resolver darf die negative Antwort so lange vorhalten; §5 empfiehlt Resolvern, ihren eigenen Negative-Cache zu deckeln — als sinnvolle Voreinstellung nennt er ein bis drei Stunden, Werte über einem Tag hält er für problematisch —, wie lange ein einzelner Resolver sie tatsächlich hält, ist damit seine Entscheidung. Ein Vorbehalt zu unseren Gunsten: Ein rekursiver Resolver liefert eine bereits heruntergezählte TTL, der von uns berechnete Wert ist also eine Untergrenze des veröffentlichten. Die refresh-/retry-/expire-Timer steuern dagegen nur die Replikation an Secondaries, die den Primary abfragen (AXFR oder IXFR); wo das niemand tut – der Normalfall bei API-getriebenem Managed DNS –, wirken sie gar nicht, und die Zahlen, die diese Anbieter veröffentlichen, folgen den Konventionen unten nicht – gemessen 2026-08: Google veröffentlicht für die eigenen Zonen refresh 900 / retry 900 / expire 1800 und als Cloud-DNS-Default 21600 / 3600 / 259200, Apple 300 / 300 / 3628800, was die Konventionen unten allesamt beanstanden würden, während Cloudflare (10000 / 2400 / 604800) und Route 53 (7200 / 900 / 1209600) zufällig innerhalb liegen. Wirkungslos sind sie aber nicht immer: Auch eine Managed-Zone kann echte Secondaries per Transfer versorgen (Cloudflare etwa bietet ausgehendes AXFR/IXFR an), und von außen ist nicht feststellbar, ob sie es tut. Die Zone funktioniert so oder so – 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 — aber nur, wenn die Abfrage eindeutig war, sonst wird die Prüfung übersprungen. Übersprungen wird auch, wenn ein SOA veröffentlicht ist, dessen Felder sich nicht als Zonenkonfiguration lesen lassen: Ein unlesbarer Record ist eine Grenze dieser Auswertung, keine gesunde Zone. Die Verhältnisse von refresh/retry/expire, ein negativer Timer-Wert und eine Serial von null werden nur als informative Hinweise angezeigt (sie sind ausschließlich für zonentransfer-basierte Secondaries relevant) und nennen jeweils ihre Quelle — RFC 1912 §2.2 („must be greater than the minimum and retry intervals“, „2-4 weeks are suggested values“), Zonemaster ZONE05 für den Vergleich mit refresh und mit einer Woche sowie Zonemaster ZONE03 für retry gegen refresh; die beiden Zonemaster-Prüfungen sind Konventionen dieses Werkzeugs, keine Normen, und seine Spezifikation ist ein bewegliches Ziel (Testfälle mit Stand 2026-08). Für die ganze Liste gilt eine historische Einordnung: RFC 1912 ist älter als RFC 2308 und liest das letzte SOA-Feld noch als Default-TTL für Records — eine Bedeutung, die RFC 2308 §4 durch die TTL für negative Antworten ersetzt hat. Der Vergleich von expire und Minimum ist damit eine überlieferte Konvention über dasselbe Wire-Feld und keine Regel aus seiner heutigen Bedeutung. Eine Untergrenze für refresh oder retry gibt es bewusst nicht: Die üblichen Mindestwerte würden gesunde Managed-DNS-Zonen wie google.com oder apple.com beanstanden. Gewicht 1.
BehebungPrüfen, ob die Zonen-Delegation korrekt ist. Die Negative-Cache-TTL deutlich unter einem Tag halten. Dabei ist zu sehen, was RFC 2308 §5 überhaupt ist: ein Absatz, der sich an Resolver-Implementierer richtet und die Obergrenze für deren EIGENEN Negative-Cache behandelt („Values of one to three hours have been found to work well and would make sensible a default. Values exceeding one day have been found to be problematic.“). Für das Feld der Zone nennt er keine Zielgröße — das Protokoll erlaubt aber Caching „for up to 68 years“ (RFC 2308 §5; die Zahl ist die Obergrenze von 2^31−1 Sekunden aus RFC 2181 §8). Kein großer Resolver hält sich auch nur annähernd daran: BIND deckelt negative Antworten per Default bei drei Stunden und kürzt jeden konfigurierten Wert über sieben Tage stillschweigend, Unbound bei einer Stunde, Knot Resolver bei einem Tag. Ein sehr großer Wert wird hier als Konfigurationshygiene gemeldet, nicht weil ein Resolver danach handeln würde. Der Hebel ist derjenige der beiden Eingangswerte, der gerade kleiner ist: MINIMUM oder die TTL des SOA-Records selbst. Den größeren zu senken ändert nichts. Die übrigen Timer sind nur relevant, wenn traditionelle AXFR-basierte Secondaries betrieben werden.
DNS-Abfragen (nichts messbar) #
Dieser Eintrag steht anstelle des gesamten DNS-Abschnitts, wenn keine einzige DNS-Abfrage zu dieser Domain eine eindeutige Antwort geliefert hat. Es gibt ihn, damit der Bericht nicht die Alternative tut: Befunde über eine Domain erfinden, die er nie erreicht hat. Vor seiner Einführung gemessen: Bei totem Egress entstand eine vollständige Befundliste und Note F für eine tadellose Domain — die benotete Substanz war identisch mit der Antwort auf eine gar nicht existierende Domain.
Bewertungskip, Gewicht 0 — das Modul wird als „konnte nicht benotet werden“ ausgewiesen, statt schlecht benotet zu werden. Im Text werden drei Fälle unterschieden. Gar keine Antwort (beide Resolver von diesem Scanner aus nicht erreichbar) verkürzt zusätzlich die Zwischenspeicherung dieser Antwort. Kamen zwar Antworten, war aber keine davon eindeutig (SERVFAIL und Ähnliches), wird die SOA-Abfrage einmal mit abgeschalteter DNSSEC-Validierung (CD=1) wiederholt: Antwortet die Zone darauf, existieren ihre Records und ihre Nameserver antworten — was scheitert, ist die DNSSEC-Kette, und genau deshalb antwortet ein validierender Resolver für die Zone mit SERVFAIL, statt ihre Records herauszugeben (RFC 4035 §5.5 — nur eine Abfrage mit gesetztem CD-Bit bekommt die vollständige Antwort noch, und CD ist das Werkzeug des validierenden Clients selbst); der Bericht sagt das dann auch. Bleibt die Wiederholung ebenfalls stumm, ist eine defekte Kette ausgeschlossen und es bleiben ausfallende Nameserver oder ein Problem auf unserer Seite — die beiden sind von hier aus nicht unterscheidbar, deshalb wird kein Schuldiger benannt. Das Urteil verschiebt sich nie: Eine mit abgeschalteter Validierung erhaltene Antwort wird nicht benotet, denn bei echten Besuchern kommt die Zurückweisung an.
BehebungNichts zu tun, wenn der Scan schlicht Pech hatte — einfach wiederholen. Benennt der Bericht die DNSSEC-Kette, gehört die Reparatur dorthin (der DNSSEC-Abschnitt dieses Berichts zeigt, welches Glied gebrochen ist); bis dahin löst die Zone für validierende Resolver nicht auf.
Direktabfragen an die Nameserver der Zone #
Drei Prüfungen dieses Abschnitts fragen nicht einen öffentlichen Resolver, sondern die Nameserver der Zone selbst — direkt auf Port 53: ob jeder von ihnen autoritativ für die Zone antwortet, ob sie untereinander übereinstimmen und ob die Delegation der Elternzone zu den NS-Records passt, die für die Zone veröffentlicht sind. Auch die dritte liest beide Seiten direkt auf Port 53 und fällt für die Zonenseite nur dann auf die NS-Antwort des Resolvers zurück, wenn die Nameserver der Zone keinen einheitlichen Satz geliefert haben. Dieser Eintrag steht in drei Situationen an ihrer Stelle, und er sagt, welche vorliegt: Die Abfragen wurden innerhalb des Zeitbudgets dieses Scanners von neun Sekunden nicht fertig und mussten abgebrochen werden; keiner der Nameserver der Zone hat überhaupt geantwortet; oder kein einziger von ihnen löst auf eine Adresse auf, es gab also nichts zu fragen. Ein Nameserver, der die Abfrage verweigert — oder einer, der sie verwirft, während andere noch antworten —, ist ein anderer Fall: Der wird innerhalb der drei Prüfungen selbst gemeldet.
Bewertungskip, Gewicht 0. Es gibt ihn, damit drei Findings nicht einfach aus dem Bericht verschwinden: An einer gesunden Zone gemessen sind alle drei ein pass, ihr stiller Wegfall verschiebt den Score also von 15/15 auf 10/10 — die Note bleibt gleich und der Bericht sagt nur weniger. Ein schrumpfender Bericht, der seine Note behält, ist die am schwersten bemerkbare Lücke; deshalb wird sie benannt.
BehebungNichts zu tun, wenn der Scan Pech hatte — einfach wiederholen. Tritt es wiederholt auf, prüfen, ob die Nameserver der Zone Abfragen auf TCP/UDP-Port 53 aus dem öffentlichen Internet beantworten.
Nameserver antworten autoritativ #
In einer Delegation zu stehen und die Zone tatsächlich auszuliefern sind zwei verschiedene Dinge. Diese Prüfung fragt jeden Nameserver der Zone direkt auf Port 53 — nicht einen öffentlichen Resolver, dessen Cache den Unterschied verdecken würde — und sieht sich das AA-Bit (Authoritative Answer) der Antwort an, definiert in RFC 1035 §4.1.1: „this bit is valid in responses, and specifies that the responding name server is an authority for the domain name in question section“. Ein Server, der ohne dieses Bit antwortet, steht in der Delegation, ist für die Zone aber nicht eingerichtet; Resolver, die ihn erwischen, verlieren einen Umlauf, und manche werten die ganze Zone als defekt.
Bewertungfail, wenn mindestens ein erreichbarer Nameserver ohne AA-Bit antwortet — oder wenn ein Nameserver statt der Zonendaten einen Fehlercode liefert (REFUSED, SERVFAIL und Ähnliches): Eine solche Antwort sagt nichts über die Records aus, sondern nur, dass dieser Server die Zone nicht ausliefern will oder kann, für die die Delegation ihn nennt. pass, wenn jeder beurteilbare Nameserver autoritativ antwortet. Gewicht 2. Server, deren Antwort sich nicht abholen ließ, und Server, deren Antwort abgeschnitten zurückkam, werden in keine Richtung gezählt; die Wertzeile nennt, wie viele Nameserver beurteilt wurden bzw. wie viele mit einem Fehlercode geantwortet haben. Kommen die Direktabfragen insgesamt nicht durch, tritt der Eintrag „Direktabfragen“ an die Stelle dieser Prüfung, statt sie stillschweigend entfallen zu lassen.
BehebungDie betroffenen Server als autoritativ für diese Zone einrichten oder aus der Delegation entfernen. Ein Server, der mit einem Fehlercode antwortet, hat die Zone möglicherweise nicht geladen, wird von einer Zugriffsregel gesperrt oder hat gerade eine Störung (SERVFAIL).
Nameserver stimmen untereinander überein #
Jeder autoritative Server einer Zone sollte dieselbe Zone ausliefern. Diese Prüfung vergleicht, was die Nameserver der Zone dafür zurückgeben — die NS-Records, die sie veröffentlichen, und die SOA-Seriennummer, die den Zonenstand kennzeichnet. Weichen sie voneinander ab, hängt die Antwort eines Besuchers davon ab, welchen Server sein Resolver zufällig erreicht hat; das ist eine echte Inkonsistenz in der Zone und kein Cache-Effekt.
Bewertungfail, wenn die Nameserver unterschiedliche Records liefern. warn bei zwei verschiedenen Situationen, die der Text auseinanderhält: Die Server sind sich bei den Records einig, melden aber unterschiedliche SOA-Seriennummern — meist ein noch laufender Zonentransfer, der sich binnen Minuten erledigt, und ein Secondary ohne Aktualisierungen, wenn es anhält — oder es ließ sich überhaupt nichts vergleichen, weil jede Antwort ein Fehlercode oder nicht vollständig abholbar war. Das Zweite ist kein sauberes Ergebnis, sondern das Fehlen eines Ergebnisses, und es wurde früher grün gemeldet: „gleiche Daten, gleicher Zonenstand“ über null Vergleiche ist die stärkste mögliche Aussage auf der schwächsten möglichen Grundlage. pass, wenn die vergleichbaren Server dieselben Records und denselben Zonenstand liefern; die Wertzeile nennt, wie viele verglichen wurden. Gewicht 1.
BehebungWeichen die Records ab, herausfinden, welcher Server veraltet ist — meist ein Secondary, das keine Zonentransfers mehr bekommt, oder ein Rückstand, der längst hätte entfernt werden sollen. Unterschiedliche Serials allein sind es wert, ein paar Minuten später noch einmal hinzusehen, bevor man handelt.
Delegation stimmt mit der Zone überein #
Die Nameserver, die Ihr Registrar in der Elternzone veröffentlicht, und die NS-Records in Ihrer eigenen Zone sind zwei getrennte Listen, und sie können auseinanderlaufen. Resolver erreichen die Zone über die Delegation der Elternzone, bleiben aber nicht dabei: RFC 2181 §5.4.1 stuft den NS-Satz der Zone selbst höher ein als die Delegations-Records der Elternzone; sobald ein Resolver die autoritative Antwort hat, ersetzt er die Delegation in seinem Cache und benutzt die Liste der Zone. Ein Server, der nur bei der Registry steht, wird mindestens bis dahin gefragt, auch wenn Sie ihn längst nicht mehr betreiben; ein Server, der nur in der Zone steht, wird gefragt, sobald der NS-Satz der Zone im Cache liegt. Beide Seiten können echten Verkehr bekommen, und genau deshalb müssen die beiden Listen übereinstimmen. Nach einem Providerwechsel ist das der klassische Rückstand. RFC 1034 §4.2.2 empfiehlt, dass beide Seiten des Schnitts übereinstimmen — der Text ist von 1987 und formuliert das als „should insure“, nicht als Pflicht: „The administrators of both zones should insure that the NS and glue RRs which mark both sides of the cut are consistent and remain so.“
Bewertungfail, wenn die Delegation der Elternzone andere Nameserver nennt als die Zone selbst veröffentlicht; pass, wenn beide dieselben nennen. Gewicht 2. Der Drill-down zeigt, welche Seite was führt. Der Vergleich braucht eine Antwort von beiden Seiten, und beide werden direkt auf Port 53 gefragt: die Elternseite bei einem Nameserver der Elternzone, die Zonenseite bei den Nameservern der Zone selbst — dieselben Direktantworten, auf denen die beiden Prüfungen darüber beruhen. Die Zonenseite wird nur dann von ihnen gelesen, wenn sie sich auf einen NS-Satz geeinigt und autoritativ geantwortet haben; andernfalls tritt die NS-Antwort des Resolvers dieses Scans an ihre Stelle, und die Prüfung sagt das in ihrem Text und in der Drill-down-Zeile „Zonenseite gelesen von“. Fehlt die Antwort der Elternzone, wird nie auf halber Grundlage entschieden, und der Bericht unterscheidet zwei Wege dorthin: Hat keiner der Nameserver der Zone überhaupt geantwortet, deckt der Eintrag „Direktabfragen“ diese Prüfung zusammen mit den beiden anderen ab, die von ihnen abhängen; ist allein die Abfrage der Elternzone gescheitert, hinterlässt diese Prüfung einen eigenen skip-Eintrag, der benennt, was nicht gelesen werden konnte.
BehebungDie Nameserver beim Registrar mit den NS-Records der Zone abgleichen oder umgekehrt. Erst eine Seite ändern, prüfen, dann die andere — nie beide gleichzeitig.