DNS-Checker: DNS-Records richtig prüfen

Ein DNS-Checker ist eine bequeme Möglichkeit, die Records zu prüfen, die ein Resolver für eine Domain aktuell abrufen kann. Man nutzt ihn nach dem Wechsel des Website-Hosts, bei der Einrichtung von E-Mail, nach dem Umzug zu einem anderen DNS-Anbieter oder bei der Untersuchung eines Namens, der sich nicht auflösen lässt. Das Ergebnis ist eine Momentaufnahme, keine Garantie dafür, dass jeder rekursive Resolver aktualisiert wurde oder der zugrunde liegende Dienst verfügbar ist. Damit die Prüfung aussagekräftig wird, wählen Sie den exakten Hostnamen, wählen den zum Symptom passenden Record-Typ und werten eine leere Antwort anders als einen DNS-Fehler. Diese drei Schritte verhindern viele Fehlalarme und zeigen Ihnen, welche Konfigurationsebene Aufmerksamkeit verdient.

Den Record wählen, der Ihre Frage beantwortet

Für die IPv4-Adresse einer Website prüfen Sie A, für IPv6 AAAA. Eine Subdomain kann per CNAME auf den Hostnamen eines Hosting-Anbieters zeigen, statt direkt eine Adresse zu tragen. Die E-Mail-Zustellung hängt zuerst von MX-Records ab, während TXT-Records häufig SPF-, DKIM- und DMARC-Daten sowie Daten zur Inhaberverifizierung veröffentlichen. NS-Records zeigen, welche Nameserver für eine Zone eingetragen sind, und SOA liefert administrative Felder und Zeitangaben zu dieser Zone. Nur A-Records zu prüfen reicht daher nicht aus, wenn das Problem in der Mailzustellung, einer delegierten Subdomain oder einem Verifizierungsschritt liegt. Gehen Sie vom betroffenen Dienst aus und ordnen Sie das Symptom den passenden Record-Typen zu.

Prüfen Sie als Nächstes den abgefragten Namen genau. example.com, www.example.com und api.example.com sind getrennte DNS-Namen und können völlig unterschiedliche Antworten liefern. Ein abschließender Punkt in der vollqualifizierten DNS-Notation steht für die Root und ist in Benutzeroberflächen meist optional. Fügen Sie keine komplette URL mit Pfad ein und gehen Sie nicht davon aus, dass der Checker erkennt, welcher Hostname gemeint ist; extrahieren Sie den Hostnamen zuerst. Wenn Sie einen neuen Record validieren, vergleichen Sie den zurückgegebenen Wert Zeichen für Zeichen mit der Anleitung des Anbieters. TXT-Richtlinien enthalten oft Satzzeichen, Trennzeichen oder lange Zeichenketten, bei denen ein scheinbar kleiner Tippfehler den Record ungültig machen kann.

Verstehen, woher abweichende Antworten kommen

DNS ist verteilt und wird gecacht. Ein autoritativer Nameserver hält die veröffentlichten Daten der Zone, während rekursive Resolver Nutzern antworten und frühere Antworten cachen können, bis ihre TTL abläuft. Zwei Checker können daher vorübergehend unterschiedliche Werte anzeigen, wenn sie verschiedene Resolver, Standorte oder Record-Versionen abfragen. Ein Checker, der mehrere Standorte abfragt, kann Abweichungen veranschaulichen, beweist aber nicht, dass sich jedes Netzwerk angeglichen hat. Weicht ein Ergebnis von der beabsichtigten Konfiguration ab, ermitteln Sie, welcher Resolver geantwortet hat, und vergleichen Sie ihn mit den autoritativen Nameservern. Berücksichtigen Sie dann die TTL und den Zeitpunkt, zu dem der vorherige Wert gecacht wurde, bevor Sie eine weitere Änderung vornehmen.

• NOERROR ohne den angefragten Record kann bedeuten, dass der Name existiert, aber keine Daten dieses Typs hat.
• NXDOMAIN bedeutet, dass der abgefragte Name als nicht existent gemeldet wurde.
• SERVFAIL zeigt an, dass ein Resolver die Abfrage nicht erfolgreich abschließen konnte.
• Ein Timeout bedeutet, dass innerhalb der Wartezeit des Checkers keine Antwort eingetroffen ist.
• Mehrere A- oder AAAA-Antworten können gewollt sein, etwa für Redundanz oder Lastverteilung.

Eine DNS-Prüfung zum sicheren Troubleshooting-Schritt machen

Halten Sie bei DNS-Änderungen ein Vorher-Nachher-Protokoll fest. Erfassen Sie Name, Typ, Wert, TTL, Resolver und Zeitpunkt und wiederholen Sie dieselbe Abfrage nach der Aktualisierung. Liefert der autoritative Server den neuen Wert, ein rekursiver Resolver aber noch den alten, kann es sinnvoll sein, das Ablaufen der Caches abzuwarten; den Record wiederholt zu ändern, kann die Diagnose erschweren. Widersprechen sich die autoritativen Server, prüfen Sie die Zonenreplikation oder die Anbieterkonfiguration. Wirken alle DNS-Antworten korrekt und die Website schlägt dennoch fehl, gehen Sie zu Konnektivität, TLS, Routing oder Anwendungsgesundheit über, statt weiter blind am DNS zu ändern.

Ordnen Sie die Antwort schließlich nach ihrem Geltungsbereich ein. Öffentliche DNS-Prüfungen eignen sich für Domains und Records, die im öffentlichen Internet sichtbar sein sollen; sie sind kein Mittel, um den rein internen Namensraum einer Organisation zu untersuchen. Eine von DNS zurückgegebene IP kann ein CDN-Edge, ein Load Balancer oder ein Reverse Proxy sein statt der Maschine, auf der die Anwendung läuft. Wenn Sie nur öffentliche Adressantworten benötigen, ist die Domain-zu-IP-Abfrage ein gezielter nächster Schritt. Begriffe und Beispiele zu A, AAAA, MX, TXT und NS finden Sie unter DNS-Record-Typen erklärt.

Einen Checker-Bericht mit gesunder Skepsis lesen

Ein DNS-Checker zeigt womöglich einen grünen Indikator, sobald er irgendeine Antwort erhält, selbst wenn der zurückgegebene Wert nicht der ist, den Ihr Dienst benötigt. Lesen Sie den rohen Owner, den Typ und die Daten, statt sich nur auf ein Zusammenfassungs-Badge zu verlassen. Auch die Antwort eines einzelnen Standorts ist eine Stichprobe, keine Garantie für globale Übereinstimmung. Listet das Tool viele Standorte auf, bedenken Sie, dass jeder Standort für einen bestimmten Resolver und Cache-Zustand stehen kann, nicht für alle Nutzer in dieser Region. Nutzen Sie den Bericht, um den nächsten Diagnoseschritt zu wählen: mit der autoritativen Quelle vergleichen, die TTL prüfen oder den Dienst testen. Übernehmen Sie keine IP in die Produktionskonfiguration, ohne zu bestätigen, dass es der unterstützte Endpunkt des Anbieters ist. Gutes Troubleshooting beruht auf einem erwarteten Wert und einem Grund für diese Erwartung, nicht allein darauf, ob ein Checker das Ergebnis „gültig“ nennt.