DNS-Checker

Führen Sie vor jeder NS-Änderung, Registrar-Übertragung oder Mail-Provider-Umstellung einen Baseline-Lookup aus. Erfassen Sie A, AAAA, MX, TXT (SPF, DKIM, DMARC), NS und SOA in einem Change-Ticket mit TTL und Zeitstempel. Nach dem Cutover denselben Lookup ausführen und Antworten Zeile für Zeile vergleichen. SOA-Serial steigt bei vielen Providern bei Zonenänderungen — notieren Sie ihn, wenn Support behauptet, die «Propagation sei abgeschlossen», während Ihr Laptop noch alte Mail-Routen zeigt.

Nutzen Sie den DNS Checker beim Onboarding eines SaaS mit Verification-TXT, beim Debuggen der Zustellbarkeit nach SPF- oder DKIM-Rotation, zur CAA-Bestätigung vor Zertifikatsausstellung oder wenn ein CDN orange-cloud AnyCast-A-Antworten ändert. DNS records online prüfen ist schneller als bind-utils auf gesperrten Firmen-Laptops und vollständiger als ping oder nslookup — die zeigen nie MX, TXT und CAA in einer strukturierten Ansicht. Für Teams ohne Root-Zugang ist das oft der schnellste Weg zu einem vollständigen Zonenbild.

Kombinieren Sie den vollständigen Lookup mit WHOIS, wenn die Delegation selbst fraglich ist: Wenn NS beim Registrar nicht zu den öffentlich zurückgegebenen NS passen, bearbeiten Sie möglicherweise ein inaktives DNS-Panel, während die Welt noch den alten Host abfragt. Für Einzeltyp-Spuren (nur MX, nur TXT, nur NS) liefert DIG auf derselben Seite resolver-artige Answer-Abschnitte zum Einfügen in Support-Threads ohne Umformatierung.

Zeigt der DNS Checker Werte, die von Ihrem Control Panel abweichen, vergleichen Sie zuerst NS. Sie könnten in einem Child-Zone-Editor sein, während der Apex noch woanders delegiert ist. Fragen Sie autoritative NS mit DIG @ns1.example.com ab, wenn rekursive Caches «lügen» — unser Checker nutzt einen konfigurierten Resolver-Pfad und spiegelt wider, was die meisten Besucher sehen, nicht unbedingt die authoritative Datei Sekunden nach Save.

TTL bestimmt, wie lange alte Antworten bestehen. Ein Eintrag mit TTL 86400 kann bis zu vierundzwanzig Stunden in jedem Resolver weltweit verbleiben, auch nachdem Sie einen Fix veröffentlicht haben. Senken Sie TTL auf stabilen Einträgen vierundzwanzig bis achtundvierzig Stunden vor einer geplanten Änderung, bestätigen Sie die niedrigere TTL mit dem DNS Checker, wenden Sie neue Daten an und erhöhen Sie TTL wieder nach Stabilisierung. «Gespeichert im Panel» ist nicht dasselbe wie «überall live sichtbar».

Doppelte SPF-TXT-Einträge am selben Owner-Namen invalidieren SPF vollständig — Includes in eine Zeichenkette zusammenführen. CNAME an einem Label mit MX oder TXT ist per DNS-Regeln ungültig und erzeugt unvorhersehbares Resolver-Verhalten. DMARC ohne ausgerichtetes SPF oder DKIM meldet Fehler, behebt sie aber nicht; behandeln Sie DMARC als Richtlinienebene über funktionierenden Auth-Einträgen, nicht als Ersatz.

Geografisches AnyCast und CDN-proxied Names können je nach Resolver-Standort unterschiedliche A- oder AAAA-Antworten liefern. Das ist erwartet, kein Propagations-Bug. Beim Debuggen des Origin-Routings vergleichen Sie grey-cloud vs. orange-cloud in Ihrem DNS-Panel und führen Sie den DNS Checker nach jedem Toggle erneut über denselben Resolver-Pfad aus.

Eingehende Mail hängt von MX-Prioritäten und erreichbaren Mail-Exchanger-Hostnamen ab. Ausgehende Reputation hängt von SPF-, DKIM- und DMARC-TXT an vorhersagbaren Namen ab. Der DNS Checker gruppiert MX und TXT in einer Antwort, damit Sie bestätigen können, dass mail.example.com auflöst, nur ein SPF am Apex existiert, Ihr selector._domainkey-Label einen aktuellen Public Key veröffentlicht und _dmarc.example.com die gewünschte Richtlinie (none, quarantine oder reject) angibt.

Nach Google Workspace, Microsoft 365 oder jedem SMTP-Relay-Onboarding alle vier Familien prüfen, bevor Sie Bulk-Mail senden. Ein funktionierender MX-Eintrag bedeutet nicht korrektes SPF — vergleichen Sie ausgehende SMTP-IPs mit der SPF-Include-Kette und Provider-Dokumentation. Kopieren Sie die exakt verkettete TXT aus dem Checker statt aus PDFs abzutippen; im Panel geteilte DKIM-Strings werden in DNS-Antworten zusammengefügt.

Wenn Authentication-Results spf=fail oder dkim=fail zeigen, TXT live mit dem DNS Checker erneut abfragen, Zone korrigieren, TTL notieren und auf Cache-Ablauf warten vor Retest. Nutzen Sie den Blacklist Checker für Sending-IPs, wenn Deferrals nach sauberer DNS-Auth bestehen — DNS-Fixes sind Voraussetzungen für Zustellbarkeit, ersetzen aber keine IP-Reputationsarbeit.

Dieses Tool zeigt die DNS-Einträge, die unser Resolver gerade zurückgibt — ein vollständiger All-Records-Lookup inklusive DKIM- und DMARC-freundlicher TXT-Antworten, gruppiert nach Typ mit Kopieraktionen. Es dient der Konfigurationsprüfung, Migrationsdokumentation und der Frage «was zeigt der öffentliche DNS-Baum heute für diesen Namen?» Es zeichnet keine Weltkarte resolver-spezifischer Unterschiede und behauptet nicht, fünfzig globale Standorte gleichzeitig zu testen.

Dedizierte DNS-Propagation-Checker fragen viele regionale rekursive Resolver über Zeit ab und visualisieren, welche Regionen noch alte A-, MX- oder NS-Werte cachen. Diese Weltansicht hilft nach großen TTL-lastigen Änderungen oder NS-Wechseln, wenn Support fragt «ist es schon propagiert?» DN01 repliziert diese Karte nicht — wir fokussieren einen hochwertigen Snapshot plus Historie, API-Zugang und Begleit-Tools (DIG, WHOIS, SSL) auf derselben Seite.

Propagation ist keine sofortige Teleportation. Alte Caches laufen per TTL ab plus Registrar-Glue-Updates bei NS-Wechsel. Niedrige TTL in der autoritativen Zone hilft künftigen Änderungen schneller zu konvergieren, kann aber nicht retroaktiv Antworten flushen, die bereits bei 86400 Sekunden gecacht sind. Nutzen Sie den DNS Checker, um Ihr autoritatives Publish zu bestätigen, dann Propagation-Maps, wenn Sie geografische Sicherheit brauchen, dass Resolver in mehreren Regionen alte Daten abgelaufen haben.

Wenn Antworten zwischen DNS Checker und Propagation-Map abweichen, können beide für ihren Standpunkt «korrekt» sein. Rekursive Resolver cachen unabhängig; Büro-DNS, Mobilfunk und 8.8.8.8 können bis TTL-Ablauf divergieren. Fragen Sie autoritative NS direkt mit DIG ab, wenn Sie Cache vollständig umgehen müssen — zeigt authoritative NS schon den neuen MX, der Checker aber noch den alten, beobachten Sie Cache-Lag, kein fehlgeschlagenes Publish.

Wählen Sie DN01, wenn Sie jeden wichtigen Eintragstyp in einer Ansicht, lokalisierte UI in acht Sprachen, lokale Recent History und dokumentierte API für Automatisierung wollen. Wählen Sie Propagation-Maps, wenn Ihre Frage speziell lautet «welche Regionen sehen noch die alte IP?» — nicht «sind meine MX- und SPF-Strings korrekt?» Wir sind ehrlich über diese Grenze: keine fake Propagation-Percentage-Bar, kein simuliertes globales Grid — nur genaue, kopierfreundliche DNS-Daten für Betreiber, die zuverlässige Mail-, Web- und Zertifikatsänderungen ausliefern müssen. Diese klare Abgrenzung spart Zeit gegenüber irreführenden «99 % propagiert»-Anzeigen, während MX oder SPF noch falsch sind.