Beliebte Tools

Design

DNS-Health-Check

Domain-Validierung für das DNS: die Delegation der Registry, jeder Nameserver direkt gefragt, SOA, DNSSEC und Mail-Einträge. 40 Prüfungen, jede mit Lösung.

Stufen von Zonemaster und aus den RFCs · jeder Nameserver über TCP gefragt · Google Public DNS · RDAP

Geht von einem Root-Server zur Registry von .nl und fragt dann jeden Nameserver von sidn.nl direkt · 40 Prüfungen · etwa 3 sRegistry .nl → jeder Nameserver · 40 Prüfungen

Beispiel
BeispielAufgezeichnet am 23. Okt. 2026 · von unserem Server.nl3 NSDNSSEC-signiert

sidn.nl besteht jede Prüfung, die gelaufen ist, DNSSEC eingeschlossen

registriert bei SIDN·2,9 s

40 bestanden

A+: nichts über Info. Jeder Nameserver hat autoritativ geantwortet und mit den anderen übereingestimmt, die Timer liegen im Bereich von Zonemaster, und Google Public DNS validiert die DNSSEC-Kette ab der Root.

Probleme zuerst

Über TCP von unserem Server am Edge von Cloudflare gefragt: die Root, die Registry von .nl und jeder Nameserver direkt; Google Public DNS und Cloudflare für Mail-Einträge und Validierung. Wir protokollieren nicht, was Sie prüfen.

Was prüft ein DNS-Check?

Ein DNS-Check folgt einer Domain so, wie ein Resolver sie findet, und prüft jeden Schritt: die Delegation der Registry, jeden direkt gefragten Nameserver, ob diese Server übereinstimmen, den SOA-Eintrag, DNSSEC und die Mail-Einträge. Dieser führt 40 Prüfungen in sieben Gruppen aus und bewertet jede auf der Stufe, die ihre Autorität festlegt.

Die meisten Checker fragen einen Resolver und bewerten, was zurückkommt. Das verdeckt die Server dahinter: Ein Resolver antwortet von dem Nameserver, der gerade funktioniert, daher bleibt ein defekter unsichtbar, bis auch die anderen ausfallen. Hier wird jeder Nameserver über TCP ohne Rekursion gefragt, die Kopie der NS-Einträge bei der Registry wird mit der eigenen der Zone verglichen, und die DNSSEC-Kette wird vom DS bei der Registry bis zu den Signaturen in der Zone verifiziert.

Nutzen Sie ihn nach jeder Änderung als DNS-Audit: Er prüft die DNS-Einträge, von denen eine Domain abhängt, nicht nur, ob ihre Website lädt (dafür schaut sich der Website-Down-Checker die Seite selbst an). Bericht kopieren macht aus dem Ergebnis einen DNS-Bericht als reinen Text, den Sie in ein Ticket einfügen können.

Rooth.root-servers.net
.comRegistry .comh.gtld-servers.net
8 NameserverRoute 53 + NS1
Die Zonegithub.com
  • DNSSEC7 Prüfungendie Vertrauenskette ab der Root: github.com: endet bei .com (kein DS)
  • Parent-Zone & Delegation6 Prüfungender Verweis der Registry: 8 Namen · 295 Byte · kein Glue nötig
  • Nameserver14 Prüfungenjeder Server direkt gefragt: 8 von 8 autoritativ · über TCP · EDNS · keine Rekursion
  • Konsistenz3 Prüfungenstimmen die Server überein: 2 SOA-Seriennummern, eine pro DNS-Hoster · dieselben MX- und SPF-Einträge
  • SOA4 PrüfungenTimer unter den Untergrenzen von Zonemaster: Hinweise
  • CAA1 Prüfung7 Einträge · 4 CAs erlaubt
  • Mail-DNS5 PrüfungenMX bei Microsoft 365 · SPF 10 von 10 Abfragen · DMARC quarantine
Wo jede Gruppe von Prüfungen hinschaut, auf dem echten Weg von github.com (23. Oktober 2026): von der Root über die .com-Registry zu den Nameservern der Zone bei Route 53 und NS1.
DNS-Check von github.com: Note A, 40 Prüfungen in sieben Gruppen und der Weg von der Root zu 8 NameservernDNS-Check von github.com: Note A, 40 Prüfungen in sieben Gruppen und der Weg von der Root zu 8 NameservernDie NoteNur aus den Stufen: kein kritischer Befund, kein Fehler, zwei Warnungen ergeben ein A. Der Ring zeigt die Punktzahl, 90 von 100.40 Prüfungen, je eine ZelleGruppiert wie in der Liste auf der Seite. Gelbe und blaue Zellen sind die Warnungen und Hinweise; schraffierte Zellen konnten nicht laufen.Probleme zuerstGruppen mit etwas zu beheben stehen geöffnet oben, jede Zeile mit ihrer Autorität und der Lösung.Der WegEin Root-Server, die .com-Registry von Verisign, dann jeder Nameserver direkt gefragt: seine Antwort, Seriennummer und EDNS.VertrauensketteDie DNSSEC-Schiene neben dem Weg: grün, wo sie hält, gestrichelt, wo sie endet, rot, wo sie bricht.
Ein DNS-Health-Check von github.com. Wählen Sie eine Nummer, um zu sehen, was der jeweilige Teil zeigt.

Wie wird die Note berechnet?

Der Buchstabe ergibt sich nur aus den Stufen dessen, was fehlschlug, nie aus einer Punktetabelle: Jedes kritische Problem ergibt ein F, zwei oder mehr Fehler ein D, ein Fehler oder fünf und mehr Warnungen ein C, drei oder vier Warnungen ein B, eine oder zwei Warnungen (oder nur Hinweise) ein A und nichts über Info ein A+.

Die Stufen sind die der zitierten Autorität: das Standardprofil von Zonemaster, wo es den Test definiert, das MUST oder SHOULD des RFC, wo nicht. Die Zahl von 100 ordnet Domains nur innerhalb eines Buchstabens (100 − 30 pro kritischem Befund, 12 pro Fehler, 4 pro Warnung, 1 pro Hinweis). Prüfungen, die unser Server nicht ausführen kann, werden einer Domain nie angelastet; kann ein Viertel oder mehr nicht laufen, lautet die Note teilweise.

  1. A+100nichts über InfoINFO „weist definitiv nicht auf ein Problem hin“sidn.nl100
  2. A90–991–2 Warnungen oder nur HinweiseNOTICE „sollte dem Administrator der Zone bekannt sein, muss aber überhaupt kein Problem sein“github.com90example.com95bücher.de90
  3. B75–893–4 WarnungenWARNING „wird unter bestimmten Umständen ein Problem sein, das einem gelegentlichen Nutzer aber kaum auffallen dürfte“cloudflare.com87google.com83
  4. C60–741 Fehler oder 5 und mehr WarnungenERROR „beeinträchtigt sehr wahrscheinlich (oder womöglich sicher) die Funktion der Zone“keine in der Stichprobe
  5. D45–592 und mehr Fehlerdnssec-failed.org55
  6. F0–44jedes kritische ProblemCRITICAL „kann man mit gutem Grund als nicht existent bezeichnen“eine Domain unter .com44

Punktzahl = 100 − 30 × kritisch − 12 × Fehler − 4 × Warnung − 1 × Hinweis, innerhalb der Spanne des Buchstabens gehalten

teilweiseein Viertel oder mehr der Prüfungen konnte von unserem Server aus nicht laufen, und die Note sagt das

Die Leiter, mit den Domains, die wir am 23. Oktober 2026 geprüft haben, nach ihrer aufgezeichneten Note eingeordnet. Stufen zitiert nach den Schweregrad-Definitionen von Zonemaster.

Nameserver prüfen: Stimmen die NS-Einträge von Parent und Child überein?

Das sollten sie: Die Registry (die Parent-Zone) und die Zone (das Child) veröffentlichen jeweils einen NS-Satz, und laut RFC 1912 §2.8 sollen beide gleich bleiben. Zeigt die Registry auf einen Server, der nicht für die Zone antwortet, ist das eine Lame Delegation: Der Server antwortet REFUSED oder ohne das Flag für autoritative Antworten (AA).

Resolver gehen zum nächsten Server weiter, daher kostet ein einzelner Server, der lame ist, Zeit; ist jeder gelistete Server lame, löst sich die Domain nicht mehr auf. Zonemaster bewertet Namen, die nur die Registry listet, als Fehler (EXTRA_NAME_PARENT), Namen, die nur die Zone listet, als Hinweis und das Fehlen jedes funktionierenden Servers als kritisch.

github.comstimmt überein

Registry von .com
  • ns-520.awsdns-01.net
  • ns-421.awsdns-52.com
  • ns-1707.awsdns-21.co.uk
  • ns-1283.awsdns-32.org
  • dns1–4.p08.nsone.net
Die Zone
  • dieselben 8

8 von 8 antworten mit AA

eine Domain unter .netweicht ab

Registry von .net
  • ns1.domaindirect.com
  • ns2.domaindirect.comREFUSED
  • ns3.domaindirect.com
Die Zone
  • ns1.hover.com
  • ns2.hover.com

kein gemeinsamer Name · ns2.domaindirect.com: REFUSED · 2 Fehler

eine Domain unter .comLame Delegation

Registry von .com
  • ns63.domaincontrol.comREFUSED
  • ns64.domaincontrol.comREFUSED
Die Zone
  • niemand antwortetSERVFAIL

jeder Server: REFUSED · Resolver antworten SERVFAIL · CRITICAL

Drei Delegationen, aufgezeichnet am 23. Oktober 2026. Die Namen der beiden fehlerhaften werden zurückgehalten; ihre Nameserver und Antworten sind echt.

Wie viele Nameserver braucht eine Domain?

Mindestens zwei, und drei sind die Empfehlung. RFC 1034 §4.1 verlangt, dass jede Zone auf mindestens zwei Servern verfügbar ist, und RFC 2182 §5 empfiehlt drei für die meisten Zonen auf Organisationsebene. Ein einziger Nameserver ist bei Zonemaster ein Fehler; zwei bestehen mit einer Info-Meldung.

Wo sie stehen, zählt mehr als wie viele es sind, daher schaut die Nameserver-Prüfung auch auf ihre Netze. Server in einem Netz fallen gemeinsam aus: Zonemaster warnt, wenn jede Adresse in einem autonomen System liegt (IPV4_ONE_ASN), auch bei Anycast-Hosts wie Google, Cloudflare oder Akamai, deren Adressen jeweils von vielen Standorten antworten. Anycast verteilt die Last; es bleibt trotzdem ein Betreiber.

  • google.com4 NS · 1 Netzein Netz
  • github.com8 NS · 2 Netzeverteilt
  • sidn.nl3 NS · 2 Netzeverteilt
  • cloudflare.com5 NS · 1 Netzein Netz
  • nasa.gov6 NS · 1 Netzein Netz
  • example.com2 NS · 1 Netzein Netz

AS1921 ipcomAS13335 CloudflareAS15169 GoogleAS16509 AmazonAS21342 AkamaiAS48283 SIDNAS62597 NS1

„Es wird empfohlen, für die meisten Zonen auf Organisationsebene drei Server bereitzustellen, von denen mindestens einer weit von den anderen entfernt sein muss.“ RFC 2182 §5
Ein Punkt pro Nameserver, gefärbt nach dem Netz (AS), aus dem seine Adresse angekündigt wird, aus den am 23. Oktober 2026 aufgezeichneten Läufen. Ein einziges Netz ist die Warnung IPV4_ONE_ASN von Zonemaster, ob Anycast oder nicht.

Sind die Werte Ihres SOA-Eintrags richtig?

Hat ein großer DNS-Hoster sie gesetzt, sind sie mit ziemlicher Sicherheit in Ordnung, auch wenn ein Checker sie anmerkt. Refresh, Retry und Expire steuern nur Secondary-Server, die die Zone per Zonentransfer kopieren. Minimum ist die TTL für negatives Caching (RFC 2308): wie lange Resolver sich merken, dass ein Name nicht existiert.

RIPE-203 (1999) empfiehlt Refresh 86400, Retry 7200, Expire 3600000 und Minimum 172800, Letzteres aus der Zeit vor RFC 2308. Zonemaster setzt niedrigere Untergrenzen: Refresh 14400 und Retry 3600 (Hinweise), Expire 604800 (die einzige Warnung), Minimum zwischen 300 und 86400 (ein Hinweis). Die Standardwerte von Cloudflare, Route 53 und Azure liegen unter den Untergrenzen für Refresh und Retry; das Expire von 3 Tagen bei Google Cloud DNS ist die eine Warnung unter den großen Hostern.

RefreshZonemaster ≥ 4 Std. · ◆ 1 Tg.RetryZonemaster ≥ 1 Std. · ◆ 2 Std.ExpireZonemaster ≥ 7 Tg. · ◆ 41,7 Tg.MinimumZonemaster 5 Min. – 1 Tg. · ◆ 2 Tg.
Cloudflare2,8 Std.40 Min.7 Tg.30 Min.2 Hinweise
Amazon Route 532 Std.15 Min.14 Tg.1 Tg.2 Hinweise
Google Cloud DNS6 Std.1 Std.3 Tg.5 Min.1 Warnung
Azure DNS1 Std.5 Min.28 Tg.5 Min.2 Hinweise
GoDaddy8 Std.2 Std.7 Tg.1 Std.bestanden
Namecheap BasicDNS12 Std.1 Std.7 Tg.1 Std.bestanden
google.com (selbst betrieben)15 Min.15 Min.30 Min.1 Min.1 Warnung · 3 Hinweise

unter der Untergrenze von ZonemasterbestandenHinweisWarnungRIPE-203 (1999)

Die Werte jedes Hosters, wie seine Zonen sie am 23. Oktober 2026 über dig ausgeliefert haben: Cloudflare, Route 53 und Google Cloud DNS entsprechen ihrer Dokumentation; die Hilfeseite von GoDaddy nennt Minimum 600, seine Beispielzonen liefern 3600; für Azure DNS und Namecheap BasicDNS haben wir keine veröffentlichten Standardwerte gefunden, daher sind ihre Werte die ihrer Zonen. Logarithmische Skala von 1 Minute bis 6 Wochen.

DNSSEC prüfen: DS, DNSKEY und Signaturen

Ein DNSSEC-Check geht die Vertrauenskette ab: Der DS-Eintrag bei der Registry muss der Digest eines Schlüssels (DNSKEY) in der Zone sein, dieser Schlüssel muss den Schlüsselsatz der Zone signieren, und jede Signatur (RRSIG) muss sich verifizieren lassen und in ihrem Gültigkeitszeitraum liegen. Diese Prüfung berechnet den Digest, verifiziert jede Signatur selbst und fragt dann Google Public DNS, ob die Validierung gelingt.

Bricht ein Glied, antworten validierende Resolver mit SERVFAIL: Die Domain verschwindet für alle, die diese Resolver nutzen. dnssec-failed.org, eine absichtlich defekt gehaltene Testzone, zeigt zwei Brüche auf einmal. Algorithmen werden nach der IANA-Registry beurteilt (RFC 9904): 8, 13 und 15 sind empfohlen, während 5 und 7, die mit SHA-1 signieren, nicht mehr verwendet werden dürfen (RFC 9905) und von Zonemaster als Fehler gewertet werden.

cloudflare.comsicher

  1. DS 2371 bei .comAlgorithmus 13 · SHA-256 · 329968…26F2B9
  2. der Digest passt zu Schlüssel 2371
  3. DNSKEY 2371 · KSKFlags 257 · ECDSA P-256 (13)
  4. signiert den Schlüsselsatz · noch 50,8 Tage, Laufzeit 61 Tage
  5. DNSKEY 34505 · ZSKFlags 256 · ECDSA P-256 (13)
  6. signiert die Einträge · SOA: noch 1 Tag, Laufzeit 2 Tage
  7. Google Public DNSAD-Flag gesetzt: sicher

dnssec-failed.orgungültig

  1. DS 42069 bei .orgAlgorithmus 13 · SHA-256
  2. kein Schlüssel 42069 in der Zone
  3. DNSKEY 50719 · KSKder echte Key-Signing-Key der Zone
  4. seine Signatur über den Schlüsselsatz ist bereits 112 Tage abgelaufen
  5. DNSKEY 32784 · ZSKsigniert das SOA: gültig, noch 5,7 Tage, Laufzeit 7 Tage
  6. nichts Vertrauenswürdiges führt dorthin
  7. Google Public DNSSERVFAIL; mit gesetztem CD kommt eine Antwort: ungültig (bogus)

Signaturalgorithmen (IANA-Registry, RFC 9904)

  • RECOMMENDED8 RSASHA256 · 13 ECDSAP256SHA256 · 15 ED25519diese verwenden
  • MAY14 ECDSAP384SHA384 · 16 ED448erlaubt
  • NOT RECOMMENDED10 RSASHA512Zonemaster WARNING
  • MUST NOT5 RSASHA1 · 7 RSASHA1-NSEC3-SHA1 · 1 · 3 · 6 · 12RFC 9905 · Zonemaster ERROR

beide Ketten oben signieren mit 13

Zwei Ketten, aufgezeichnet am 23. Oktober 2026: Die von cloudflare.com hält; die von dnssec-failed.org bricht am DS und noch einmal an einer abgelaufenen Signatur.

Mail-DNS: MX, SPF und DMARC

Die Mail-Prüfungen lesen, was empfangende Server lesen: die MX-Einträge (oder einen Null-MX, der sagt, dass die Domain keine Mail annimmt, RFC 7505), einen SPF-Eintrag innerhalb des Limits von RFC 7208 von 10 DNS-Abfragen und eine DMARC-Richtlinie (RFC 9989, das RFC 7489 im Mai 2026 abgelöst hat).

SPF wird ausgewertet, nicht nur gefunden: Jedes include wird verfolgt und gezählt. Der Eintrag von github.com braucht genau 10 Abfragen plus eine leere Abfrage (Void Lookup): gültig, ohne Spielraum. Eine Domain, die nie Mail sendet, sollte das sagen: example.com veröffentlicht den Satz für geparkte Domains, einen Null-MX, v=spf1 -all und p=reject. Für Details gehen der SPF-Checker und der DMARC-Checker weiter.

github.comsendet und empfängt

MX
0 github-com.mail.protection.outlook.comMicrosoft 365 · 1 Host · kein Alias
SPF
v=spf1 ip4:192.30.252.0/22 include:spf.protection.outlook.com include:_netblocks.google.com include:_netblocks2.google.com include:mail.zendesk.com include:_spf.salesforce.com include:servers.mcsv.net include:mktomail.com include:sendgrid.net ip4:62.253.227.114 ip4:166.78.69.169 ip4:166.78.69.170 ip4:166.78.71.131 ~all10 von 10 DNS-Abfragen1 von 2 leeren Abfragen · gültig, kein Spielraum mehr
DMARC
p=quarantine; sp=rejectBerichte an 1 Adresse · Subdomains: reject

example.comgeparkt

MX
0 .Null-MX: nimmt keine Mail an (RFC 7505)
SPF
v=spf1 -allsendet keine Mail · 0 Abfragen
DMARC
p=reject; sp=rejectalles, was sich als example.com ausgibt, wird abgewiesen
github.com und example.com, wie am 23. Oktober 2026 veröffentlicht.

DNS über die Kommandozeile prüfen (dig)

Vier Schritte mit dig und delv wiederholen den Kern dieser Prüfung: der Delegation ab der Root folgen, einen Nameserver direkt ohne Rekursion fragen, den DS bei der Registry mit den Schlüsseln der Zone vergleichen und einen validierenden Resolver die Kette beurteilen lassen.

Fügen Sie +tcp hinzu, um zu sehen, was unser Server sieht; lassen Sie es weg, um UDP zu testen, was ein Web-Tool im Netz von Cloudflare nicht kann. Im Header der Antwort markiert aa eine autoritative Antwort; REFUSED oder kein aa-Flag von einem Server, den die Registry listet, ist eine Lame Delegation.

Terminal · dig 9.20

$ dig +trace +tcp github.com NS
;; (gekürzt)
com.          172800 IN NS a.gtld-servers.net.   ;; von h.root-servers.net 1
github.com.   172800 IN NS ns-520.awsdns-01.net. ;; von h.gtld-servers.net: 8 NS 2

$ dig @ns-421.awsdns-52.com github.com SOA +norec +tcp
;; flags: qr aa; QUERY: 1, ANSWER: 1 3
github.com.   900 IN SOA ns-1707.awsdns-21.co.uk. awsdns-hostmaster.amazon.com.
              1 7200 900 1209600 86400 4

$ dig @a.gtld-servers.net github.com DS +norec
;; status: NOERROR, ANSWER: 0 ;; kein DS: nicht signiert 5

$ delv @8.8.8.8 cloudflare.com SOA
; fully validated 6
cloudflare.com. 300 IN SOA ns3.cloudflare.com. dns.cloudflare.com.
                2417999975 10000 2400 604800 300
  1. Die Root verweist für .com auf ihre 13 Server
  2. Der NS-Satz der Registry für github.com, 2 Tage gültig
  3. aa: eine autoritative Antwort, kein Cache
  4. SOA: Seriennummer 1, dann Refresh, Retry, Expire, Minimum
  5. Kein DS bei .com: nichts, was DNSSEC prüfen könnte
  6. delv hat die Kette ab der Root validiert
Echte Antworten für github.com und cloudflare.com (23. Oktober 2026), gekürzt. Die nummerierten Markierungen gehören zu den Notizen.

Warum kommen DNS-Checker zu unterschiedlichen Ergebnissen?

Weil sie an unterschiedlichen Zahlen messen. Klassische Checker bemängeln die Standardwerte der Anbieter: intoDNS nennt das Expire von 1800 Sekunden bei google.com „NOT OK“ und meldet einen Fehler bei den zwei Seriennummern von github.com, die bei zwei DNS-Hostern normal sind. Zonemaster stuft die Seriennummern als Warnung ein und erkennt einen Null-MX; unsere eigene erste Version lag in beiden Fällen falsch.

Und sie sehen das Netz von verschiedenen Orten aus. Zonemaster (AFNIC und die schwedische Internetstiftung) fragt über UDP und TCP, über IPv4 und IPv6. Diese Prüfung läuft am Edge von Cloudflare: Sie fragt nur über TCP, baut keine IPv6-Verbindungen auf und kann sich nicht mit Cloudflares eigenen Adressen verbinden, daher werden diese Server über 1.1.1.1 gelesen und ihre Prüfungen als nicht getestet markiert, nie als fehlgeschlagen. Als intoDNS-Alternative zeigt sie hinter jeder Stufe die Autorität statt eines bloßen OK oder NOT OK.

FallintoDNSZonemasterDNS Robot v1Diese Prüfung
github.comzwei SOA-Seriennummern (zwei DNS-Hoster)Fehler„Looks like your nameservers do not agree on the SOA serial.“WarnungMULTIPLE_SOA_SERIALSdurchgefallen„Serial mismatch detected: 1656468023 vs 1.“Warnungerklärt: eine Seriennummer pro DNS-Hoster
google.comSOA-Expire 1.800 snicht ok„Your SOA EXPIRE number is: 1800. That is NOT OK“WarnungEXPIRE_MINIMUM_VALUE_LOWERdurchgefallen„too low (min recommended: 14 days)“Warnungmit dem, worauf Expire wirkt
example.comNull-MX (0 .)Fehler„0 No A Record (no glue either)“InfoZ09_VALID_NULL_MXbestanden„Found 1 MX record(s)“bestandenNull-MX erkannt
cloudflare.comSOA-Retry 2.400 s—nicht zitiertHinweisRETRY_MINIMUM_VALUE_LOWERdurchgefallen„too high (max recommended: 15min)“HinweisStandardwert von Cloudflare
cloudflare.commit DNSSEC signiertnicht geprüftkein DNSSEC-TestbestandenDNSSEC02 · 05 · 08: Kette verifiziertwarnt„DNSSEC does not appear to be enabled for this domain.“bestandenDS → KSK → RRSIG verifiziert, Google validiert
Dieselben Domains in vier Checkern. Ergebnisse von intoDNS und v1 zitiert nach ihren Seiten und Antworten vom 22.–23. Oktober 2026; die Stufen von Zonemaster aus seinen Testspezifikationen. Die letzte Spalte ist diese Prüfung: eine intoDNS-Alternative, die jeden Befund auf der Stufe bewertet, die seine Autorität festlegt.

DNS-Check: häufige Fragen

Was ist ein DNS-Check?

Ein DNS-Check oder DNS-Health-Check, auch DNS-Validierung genannt, testet, ob das DNS einer Domain so eingerichtet ist, dass das ganze Internet sie erreichen kann: die Delegation der Registry, jeden Nameserver, den SOA-Eintrag, DNSSEC und die Mail-Einträge. Jeder Befund wird danach bewertet, wie sehr er schaden kann, von Info bis kritisch, und dieser DNS-Validator zeigt die angewandte Regel (einen Zonemaster-Test oder einen RFC-Abschnitt) und die Lösung.

Ist Domain-Validierung dasselbe wie ein DNS-Check?

Nicht immer. „Domain-Validierung“ bezeichnet auch die Prüfung, die eine Zertifizierungsstelle vor der Ausstellung eines DV-Zertifikats vornimmt, und den TXT-Eintrag, mit dem Sie gegenüber Google Workspace oder Microsoft 365 nachweisen, dass Ihnen eine Domain gehört. Dieser Domain-Validator prüft das DNS der Domain: Delegation, Nameserver, SOA, DNSSEC und Mail-Einträge. Für ein Zertifikat nutzen Sie den SSL-Zertifikat-Check.

Was ist eine Lame Delegation, und wie behebe ich sie?

Eine Lame Delegation ist ein Nameserver, den die Registry listet, der aber nicht für Ihre Domain antwortet: Er sagt REFUSED oder antwortet ohne Autorität. Beheben Sie sie dort, wo die Abweichung liegt: Legen Sie die Zone bei diesem DNS-Hoster an, oder ändern Sie die Nameserver bei Ihrem Registrar auf die, die die Zone haben. Ist jeder gelistete Server lame, löst sich die Domain gar nicht auf.

Mein DNS-Hoster nutzt Anycast. Warum die Warnung wegen eines einzigen Netzes?

Weil ein Betreiber eine einzige Fehlerdomäne ist. Mit Anycast antwortet jede Adresse von vielen Standorten, was gegen den Ausfall eines Standorts schützt, nicht aber gegen einen Ausfall des Anbieters selbst oder einen Fehler in seiner Konfiguration. Zonemaster belässt IPV4_ONE_ASN deshalb bei Warnung, und RFC 2182 verlangt Server in unterschiedlichen Netzen. Ein zweiter DNS-Hoster in einem anderen Netz beseitigt die Warnung.

Meine SOA-Timer werden angemerkt. Muss ich sie ändern?

Meist nicht. Refresh, Retry und Expire zählen nur für Secondary-Server, die Ihre Zone per Zonentransfer kopieren; große Hoster wie Cloudflare und Route 53 nutzen sie für Ihre Zone nicht, und ihre Standardwerte sind in Ordnung. Ein Expire unter einer Woche ist das Einzige, was Zonemaster als Warnung einstuft. Ändern Sie Werte nur, wenn Sie Ihren eigenen Primary und eigene Secondaries betreiben.

Warum sind manche Prüfungen als „nicht getestet“ markiert?

Weil unser Server sie nicht ausführen konnte, nicht weil etwas falsch ist. Er läuft im Netz von Cloudflare, das keine Verbindungen zu Cloudflares eigenen Adressen öffnen kann, und er fragt nur über TCP und baut keine IPv6-Verbindungen auf. Diese Server werden stattdessen über den Resolver 1.1.1.1 von Cloudflare gelesen. Nicht getestete Prüfungen senken die Note nie; ab einem Viertel lautet sie teilweise.

Warum melden meine Nameserver unterschiedliche SOA-Seriennummern?

Entweder hat ein Secondary eine Änderung noch nicht übernommen, oder Ihre Domain nutzt zwei DNS-Hoster, die die Zone nicht untereinander übertragen, sodass jeder seine eigene Seriennummer führt. Das Zweite ist normal: Die Route-53-Server von github.com sagen 1, seine NS1-Server 1656468023. Zonemaster führt jeden Unterschied als Warnung; wir erklären, welcher der beiden Fälle vorliegt.

Kann ich hier DNSSEC prüfen, und senkt fehlendes DNSSEC die Note?

Ja: Die Prüfung vergleicht den DS bei der Registry mit den Schlüsseln der Zone, verifiziert jede Signatur und fragt dann Google Public DNS. Eine nicht signierte Zone ist eine Zonemaster-Warnung (DS07_NOT_SIGNED), die Note bleibt also höchstens bei A. Eine defekte Kette ist weit schlimmer als keine: Validierende Resolver weisen die Domain zurück, ein Fehler, der die Note auf C oder darunter senkt.

Wie oft sollte ich mein DNS prüfen?

Nach jeder Änderung an Nameservern, DNSSEC oder Mail-Einträgen und vor und nach einem Umzug zu einem neuen DNS-Hoster oder Registrar. Ansonsten genügt einmal im Monat, um eine ablaufende Signatur zu bemerken, einen Nameserver, der nicht mehr antwortet, oder eine Änderung bei der Registry, die Sie nicht selbst vorgenommen haben. Jedes Ergebnis hat seinen eigenen Link, sodass Sie Läufe vergleichen können.

Speichern Sie die Domains, die ich prüfe?

Nein. Die Prüfung läuft auf unserem Server am Edge von Cloudflare und fragt die Root, die Registry, Ihre Nameserver, Google Public DNS und den Resolver von Cloudflare; nichts wird mit Ihrer Adresse protokolliert. Ein abgeschlossener Lauf wird 10 Minuten aufbewahrt, damit eine Wiederholung oder ein geteilter Link sofort antwortet, und dann verworfen. Ihre Nameserver sehen pro Lauf etwa 20 Fragen von unserem Server.

Fehlt Ihnen etwas?Funktion oder neues Tool vorschlagen

Weitere DNS-Tools