Netzwerk-Diagnose-Tools

DNS-Gesundheitscheck

Ein vollständiger Bericht zu Delegierung & DNS

esc
Ihre IP 8.8.8.8 oder google.com

DNS & Einträge

DNS-Abfrage Alle DNS-Einträge für jede Domain A-Eintrag-Abfrage IPv4-Adressen für eine Domain AAAA-Eintrag-Abfrage IPv6-Adressen für eine Domain MX-Abfrage Mailserver für eine Domain NS-Abfrage Autoritative Nameserver TXT-Abfrage TXT-Einträge, SPF, Verifizierung CNAME-Abfrage Kanonische Namen (Alias)-Einträge SOA-Abfrage Start-of-Authority-Eintrag SRV-Abfrage Dienst-Standort-Einträge CAA-Abfrage Welche CAs Zertifikate ausstellen dürfen Reverse DNS (PTR) IP-Adresse zu Hostname DNSSEC-Prüfung Ist die Domain signiert und validiert? DNS-Gesundheitscheck Ein vollständiger Bericht zu Delegierung & DNS

E-Mail-Zustellbarkeit

SPF-Prüfung Validieren Sie Ihren Sender-Policy-Framework-Eintrag DMARC-Prüfung Untersuchen und bewerten Sie Ihre DMARC-Richtlinie DKIM-Prüfung Finden und validieren Sie Ihren öffentlichen DKIM-Schlüssel Blacklist-Prüfung Prüfen Sie eine IP gegen E-Mail-Sperrlisten (DNSBLs) SMTP-Test Mit einem Mailserver verbinden und STARTTLS prüfen MTA-STS-Prüfung Erzwungene TLS-Richtlinie für eingehende Mails BIMI-Prüfung Markenlogo-Eintrag für E-Mail TLS-RPT-Prüfung SMTP-TLS-Berichtsrichtlinie

Netzwerk & Web

SSL-Zertifikat-Prüfung TLS-Zertifikat und Ablauf einer Website untersuchen HTTP-Header-Prüfung Antwort-Header, Weiterleitungen und Sicherheit untersuchen Ping (TCP) Erreichbarkeit und Latenz über TCP Port-Prüfung Welche gängigen Ports offen sind

Domain

WHOIS-Abfrage Registrierungsdaten für Domains, IPs und ASNs

Was ist ein DNS-Gesundheitscheck?

Ein DNS-Gesundheitscheck prüft, wie eine Domain von Anfang bis Ende delegiert und konfiguriert ist, und nicht nur einen einzelnen Eintragstyp. Er fragt die Elternserver (die TLD), was sie für Ihre Domain veröffentlichen, fragt dann Ihre eigenen Nameserver direkt und vergleicht beide. Abweichungen zwischen dem Elternserver und Ihren Servern — fehlendes Glue, sich widersprechende NS-Listen, nicht synchronisierte SOA-Seriennummern, lahme Nameserver oder solche mit offener Recursion — sind genau die Probleme, die ein langsames, sporadisches oder still defektes DNS verursachen. IPeek führt jede Prüfung durch und erklärt Ihnen in verständlicher Sprache, warum sie jeweils wichtig ist und wie Sie sie beheben.

Eltern-Delegierung, Glue und die Kette, die Ihre Domain findet

Jede Abfrage Ihrer Domain beginnt in der Elternzone — der TLD-Registry (zum Beispiel .de oder .com) —, die die NS-Einträge enthält, die Resolver zu Ihren Nameservern leiten. Wenn diese Nameserver innerhalb Ihrer eigenen Domain liegen, muss der Elternserver auch deren IP-Adressen als „Glue“ veröffentlichen, sonst geraten Resolver in eine Henne-und-Ei-Schleife. Eine gesunde Delegierung hat den Elternserver und Ihre eigenen Server, die sich auf dieselbe NS-Liste einigen, mit Glue dort, wo es nötig ist. Stimmen sie nicht überein, folgen manche Resolver veralteten Informationen und Ihre Änderungen scheinen für manche Nutzer zu funktionieren und für andere nicht.

Nameserver-Gesundheit: Redundanz, Autorität und Recursion

RFC 2182 empfiehlt mehrere Nameserver in unterschiedlichen Netzwerken, damit ein einzelner Ausfall Ihre Domain nie offline nimmt. Jeder muss autoritativ für Ihre Zone antworten — ein „lahmer“ Server, der das nicht tut, ist ein stilles Zuverlässigkeitsloch. Ihre autoritativen Server sollten zudem die Recursion für Fremde verweigern: Ein offen rekursiver Nameserver kann für Cache-Poisoning und DDoS-Amplification missbraucht werden. IPeek fragt jeden Ihrer Nameserver direkt ab, um zu bestätigen, dass sie antworten, autoritativ antworten, sich untereinander einig sind, TCP unterstützen und die Recursion geschlossen halten.

SOA-, MX- und Apex-Plausibilität

Der SOA-Eintrag trägt die Seriennummer und die Timing-Werte Ihrer Zone; jeder Nameserver muss dieselbe Seriennummer melden, sonst ist Ihre Zone nicht synchron und Änderungen propagieren ungleichmäßig. Die Seriennummer sollte der Konvention JJJJMMTTnn folgen, und die Timer für Refresh/Retry/Expire/Minimum sollten in den von den RFCs empfohlenen Bereichen liegen. Auf der Mailseite müssen MX-Einträge Hostnamen sein (niemals nackte IPs oder CNAMEs), die zu öffentlichen Adressen auflösen. Schließlich sollte der Apex (Ihre nackte Domain) eine Adresse veröffentlichen, aber keinen CNAME, den RFC 1912 neben anderen Einträgen verbietet.

Häufig gestellte Fragen

Worin unterscheidet sich das von einer normalen DNS-Abfrage?

Eine DNS-Abfrage zeigt Ihnen die Einträge so, wie sie ein rekursiver Resolver sieht. Ein Gesundheitscheck geht weiter: Er fragt die Eltern-TLD-Server und jeden Ihrer eigenen Nameserver direkt ab und vergleicht sie dann. So erkennt er Delegierungsprobleme, die eine einfache Abfrage verbirgt — fehlendes Glue, NS-Abweichungen zwischen Eltern- und Kindserver, lahme oder uneinige Nameserver und nicht synchronisierte SOA-Seriennummern.

Was ist Glue und warum ist ein fehlender Glue-Eintrag wichtig?

Glue ist die IP-Adresse eines Nameservers, die von der Elternzone neben dem NS-Eintrag veröffentlicht wird. Es ist erforderlich, wenn Ihre Nameserver innerhalb derselben Domain liegen, die sie bedienen (zum Beispiel ns1.example.com, das example.com bedient), weil Resolver sonst zuerst den Nameserver auflösen müssten, bevor sie überhaupt etwas auflösen können. Fehlt in diesem Fall das Glue, bricht die Auflösung; liegen Ihre Nameserver in einer anderen Domain, ist Glue optional und spart nur eine zusätzliche Abfrage.

Warum sollten meine Nameserver keine Recursion erlauben?

Autoritative Nameserver sollten nur für die Zonen antworten, die sie hosten. Ein Nameserver, der für jeden Recursion durchführt (ein „offener Resolver“), kann für DNS-Amplification-DDoS-Angriffe missbraucht werden und ist anfälliger für Cache-Poisoning. Wenn der Gesundheitscheck offene Recursion meldet, deaktivieren Sie die Recursion auf dem autoritativen Server oder trennen Sie autoritative und rekursive Rollen auf verschiedene Hosts.

Was bedeutet es, wenn meine Nameserver bei der SOA-Seriennummer nicht übereinstimmen?

Die SOA-Seriennummer ist eine Versionsnummer für Ihre Zone. Wenn Ihre Nameserver unterschiedliche Seriennummern melden, liefert mindestens einer veraltete Daten — meist ein Secondary, der die neueste Zone nicht vom Primary übertragen konnte. Das Ergebnis sind inkonsistente Antworten, je nachdem, welchen Server ein Resolver gerade trifft. Prüfen Sie die Zonentransfers (AXFR/IXFR), die NOTIFY-Einstellungen des Primary und den SOA-Refresh-Timer.

Ist ein einzelner MX-Eintrag oder zwei Nameserver ein Problem?

Keines davon ist ein Fehler, aber beide sind Single Points of Failure. Bei nur einem MX kann E-Mail verloren gehen, wenn dieser Server lange genug ausfällt; ein Backup-MX schafft Ausfallsicherheit. Zwei Nameserver sind laut RFC 2182 akzeptabel, aber drei oder mehr in unterschiedlichen Netzwerken sind sicherer. Der Gesundheitscheck kennzeichnet diese als Warnungen, nicht als Fehler — es lohnt sich, sie zu verbessern, aber sie sind kein Notfall.

Verwandte Tools

Deutsch | English | Español | Français | Italiano | Português | Русский | Українська | 日本語 | 简体中文 | 한국어