Einfach = eine Abfrage an den Resolver · Trace = Abstieg von der Root
OptionenErweiterte Optionen
Wichtige Funktionen
CAA-Antwort des abgefragten Namens
Sehen Sie die für den eingegebenen Namen zurückgegebenen CAA-Records mit ihren Werten (Let's Encrypt, DigiCert usw.) und ihrer TTL.
Multi-Resolver
Vergleichen Sie Antworten von Google, Cloudflare und Quad9, um Propagationsprobleme zu erkennen.
Issue- und Issuewild-Tags
Die Abschnitte unten erklären die Rolle jedes Tags. Das Tool zeigt die Werte so an, wie sie zurückgegeben werden, ohne sie auszulegen.
Iodef-Tag
Lesen Sie die iodef-Benachrichtigungsadresse, falls die Domain eine veröffentlicht. Das Tool prüft ihre Erreichbarkeit nicht und garantiert keine Benachrichtigung.
Kostenlos und unbegrenzt
Testen Sie so viele Domains wie nötig. Keine Anmeldung erforderlich.
Wie Sie die Optionen der DNS-Suchmaschine effektiv nutzen
Was ist der iterative Trace?
Der Trace führt die Auflösung Schritt für Schritt aus. Der Resolver fragt zuerst die Root-Server ab, dann die der TLD (.com, .de, .eu) und anschließend die autoritativen Server der Zielzone. In jedem Schritt zeigt die Seite den abgefragten Server, die Antwort, den RCODE und die Latenz an.
1. Root
Ermittlung der TLD-Server für den angefragten Namen.
2. TLD
Verweis auf die NS der Zone (Delegation).
3. Autoritative Server
Endgültige Antwort (oder Fehler) mit TTL und Latenz.
Wozu dient das?
Antworten nach Resolvern vergleichen
Einen warmen Cache, eine zu lange TTL oder eine unvollständige Delegation erkennen
Einen Latenzunterschied oder einen unerwarteten RCODE erklären
Tipp: Lassen Sie den Trace für schnelle Checks deaktiviert; aktivieren Sie ihn, wenn Sie untersuchen oder ein Ticket/Post-Mortem vorbereiten.
Was ist der klassische Trace?
Der klassische Trace befragt nur den ausgewählten Resolver (UDP oder DoH) und zeigt die Antwort so, wie sie von diesem Netzpunkt wahrgenommen wird. Sie erhalten den RCODE, die Antwortsektionen sowie die Latenz auf dem Abschnitt Client → Resolver.
1. Gewählter Resolver
Verwendet das Preset oder die individuelle Konfiguration, um die Anfrage genau wie Ihr Dienst auszuführen.
2. Protokoll beibehalten
Respektiert das ausgewählte Transportprotokoll (UDP, TCP oder DoH), um das reale Verhalten nachzustellen.
3. Detaillierte Antwort
Zeigt die Bereiche Question, Answer und Authority/Additional, sofern vorhanden, mitsamt TTL und hilfreichen Metadaten.
Warum nutzen?
Die Sicht eines bestimmten Resolvers prüfen, bevor Sie die Delegation verdächtigen
Zwischengespeicherte Werte und die Wirkung einer TTL oder Flushs bestätigen
Eine Auflösung dokumentieren, wie sie ein Client oder Microservice erlebt
Tipp: Lassen Sie die Option für den iterativen Trace deaktiviert, wenn Sie einen bestimmten Resolver auditieren; aktivieren Sie sie anschließend, um den Pfad Root → TLD → Autoritativ zu vergleichen.
Wie funktioniert der Propagationstest?
Der Test befragt parallel eine Reihe öffentlicher Resolver (Google, Cloudflare, Quad9, AdGuard, CleanBrowsing, DNS4EU, NextDNS, Surfshark) und gruppiert die Antworten nach Inhalt und RCODE. Sie sehen sofort, wer die Aktualisierung bereits übernommen hat.
1. Mehrere Resolver
Fragt die öffentlichen Resolver des Katalogs gleichzeitig ab, von unseren Servern in Europa aus.
2. Automatischer Vergleich
Gruppiert identische Antworten und hebt Abweichungen oder resolver-spezifische Fehler hervor.
3. Verwertbare Zusammenfassung
Liefert eine klare Übersicht mit der Resolverliste, deren Latenzen und dem Status jeder Gruppe.
Wann einsetzen?
Verfolgen, wie eine DNS-Änderung bei den wichtigsten öffentlichen Resolvern ankommt
Veraltete Caches erkennen und über einen gezielten Flush entscheiden
Einen Propagationsstatus in einem Ticket oder Post-Mortem teilen
Tipp: Der Propagationstest ist ein eigenständiges Tool. Nutzen Sie den DNS-Lookup für eine gezielte Einzelabfrage und den Propagationstest, um mehrere öffentliche Resolver zu vergleichen.
Ein CAA-Record (Certificate Authority Authorization) definiert, welche Zertifizierungsstellen (CAs) berechtigt sind, SSL/TLS-Zertifikate für eine Domain auszustellen. Es ist eine Sicherheitsmaßnahme, die nicht autorisierte Zertifikatsausstellung verhindert.
Die Richtlinie eines Namens kommt nicht unbedingt vom Apex. Die Suche folgt Aliasen. Endet die Auflösung erfolgreich ohne CAA, setzt sie beim Elternnamen des angefragten Namens fort, dann beim ersten Vorfahren, der einen CAA-Satz zurückgibt, bis einschließlich zur TLD. Sie steigt nicht über die Eltern des Alias-Ziels auf und fragt die Root nicht ab. Ein Abfragefehler lässt das Ergebnis unbekannt.
Die CA verweigert die Ausstellung. Häufig enthält der geltende CAA-Satz issue-Tags oder, bei einer Wildcard, issuewild-Tags, die diese CA nicht autorisieren. Das ist nicht die einzige Ursache: Auch ein Parameter accounturi oder validationmethods kann blockieren, und eine CA kann ablehnen, solange die CAA-Abfrage fehlschlägt.
Ermitteln Sie den geltenden CAA-Satz: angefragter Name, Aliase, dann Eltern
Jeder Befehl fragt einen einzigen Namen ab und steigt nicht zu den Eltern auf. Prüfen Sie zuerst den Status: SERVFAIL, REFUSED oder eine Zeitüberschreitung erlauben keine Schlussfolgerung. Lautet der Status NOERROR ohne CAA-Zeile und zeigt die Antwort nur eine Alias-Kette, fragen Sie auch deren letzten Zielnamen ab, ohne über dessen übergeordnete Namen aufzusteigen. Ohne CAA-Satz fragen Sie dann den Elternnamen des angefragten Namens ab, danach die nächsten bis zur TLD. Der vollständige Leitfaden zu CAA-Records beschreibt dieses Verfahren samt Aliasen.