Was das Tool macht
Dein Browser fragt Cloudflare (1.1.1.1) oder Google Public DNS (8.8.8.8) nach den Einträgen, die unter einem Domainnamen veröffentlicht sind, und nutzt dafür die JSON-Schnittstelle des Resolvers für DNS-over-HTTPS; diese Seite stellt die Antwort übersichtlich dar.
Jeder Eintrag erscheint mit Name, Typ, TTL und Daten. Die TTL steht in Sekunden und zusätzlich als lesbare Dauer da, 300 also auch als 5 Minuten. Außerdem siehst du den Antwortcode (NOERROR, NXDOMAIN, SERVFAIL oder REFUSED), ob der Resolver das AD-Flag gesetzt hat (DNSSEC-validiert) und wie lange die Abfrage in deinem Browser gedauert hat. TXT-Strings werden vollständig ausgegeben, was bei SPF, DMARC und langen Verifizierungs-Tokens wichtig ist.
Auch internationalisierte Namen, etwa mit Umlauten, funktionieren: bücher.example wird vor dem Senden in xn--bcher-kva.example umgewandelt, denn diese ASCII-Form ist das, was tatsächlich im DNS steht.
So fragst du ab
- Gib einen Domainnamen wie
example.comodermail.example.comein, ohnehttps://und ohne Pfad. - Wähle einen Eintragstyp: A, AAAA, MX, TXT, NS, CNAME, CAA oder SOA. Mit „Alle“ werden diese acht Typen nacheinander abgefragt.
- Wähle Cloudflare oder Google Public DNS als Resolver.
- Starte die Abfrage und prüfe zuerst den Antwortcode, bevor du die Einträge liest.
- Um das Ergebnis aufzuheben oder weiterzugeben, kopiere die Adresse der Seite. Name, Eintragstyp und Resolver stehen hinter dem
#, etwa#example.com/MX/google; so kannst du dieselbe Abfrage als Lesezeichen speichern oder an Kollegen schicken.
Die Frage läuft nicht über die Server von iseeu.cc. Dein Browser spricht direkt mit dem gewählten Resolver; der sieht also deine IP-Adresse und den abgefragten Namen, und dafür gilt seine eigene Datenschutzerklärung. Googles Resolver kann einen Teil deiner IP-Adresse an manche autoritativen Server weitergeben (EDNS Client Subnet), damit diese eine Antwort aus deiner Nähe wählen können; Cloudflares Resolver gibt an, das nicht zu tun. Der Teil hinter # wird nie an einen Server gesendet, und iseeu.cc protokolliert weder IP-Adressen noch Abfragen, führt keine Besucherdatenbank, setzt keine Cookies und zeigt keine Werbung.
Anwendungsfälle
- Eine frische Änderung prüfen. Frag den neuen A-Eintrag bei beiden Resolvern ab. Zeigt einer noch die alte Adresse, verrät dir seine TTL ungefähr, wie lange diese zwischengespeicherte Kopie noch gilt.
- Probleme bei der E-Mail-Zustellung. Prüfe MX, den TXT-String
v=spf1auf der Domain und TXT auf_dmarc.example.com. Zwei getrennte SPF-Einträge sind ein häufiger Fehler, den empfangende Server als Fehler werten. - Vor dem Beantragen eines TLS-Zertifikats. Öffentliche Zertifizierungsstellen (CAs) müssen vor der Ausstellung CAA prüfen; ein CAA-Eintrag, der nur deine frühere CA nennt, blockiert den Antrag also.
- Domain-Verifizierung. Verlangt ein Online-Dienst ein TXT-Token, frag TXT ab und vergleiche den String Zeichen für Zeichen.
- DNS-Hosting umziehen. NS zeigt, wohin die Domain delegiert ist, und die SOA-Seriennummer, die sich meist bei jeder Bearbeitung ändert, hilft dir zu bestätigen, dass die ausgelieferte Zone die ist, die du bearbeitet hast.
- Filter oder veralteten Cache erkennen. Sind sich Cloudflare und Google einig, liefert
diggegen deinen üblichen Resolver aber NXDOMAIN oder eine andere Adresse, liegt der Unterschied bei deinem lokalen Resolver, nicht in der Zone.
Die Antwort lesen
NOERROR ohne Einträge, oft NODATA genannt, bedeutet: Der Name existiert, enthält aber nichts vom angefragten Typ, etwa AAAA bei einem Host, der nur IPv4 hat. Das gilt auch für Namen, die nur existieren, weil unter ihnen etwas liegt: b.example.com, wenn nur a.b.example.com definiert ist. NXDOMAIN ist stärker: Der Name existiert für keinen Typ. Auch negative Antworten werden zwischengespeichert, und zwar so lange, wie es der SOA-Eintrag der Zone festlegt – ein Name, den du schon vor dem Anlegen abgefragt hast, kann deshalb noch eine Weile als fehlend erscheinen.
SERVFAIL bedeutet, dass der Resolver keine Antwort liefern konnte. Beide Resolver validieren DNSSEC, und eine häufige Ursache ist eine unterbrochene Vertrauenskette, etwa ein DS-Eintrag, der nach dem Umzug zu einem DNS-Anbieter mit anderen Schlüsseln beim Registrar stehen geblieben ist; auch nicht erreichbare autoritative Server führen dazu. REFUSED heißt, dass der Server die Antwort verweigert hat, was bei diesen beiden selten vorkommt. Das AD-Flag setzt eine signierte Domain voraus; die meisten sind nicht signiert, daher ist es normal, wenn es fehlt.
Ist der Name ein CNAME, listet die Antwort zuerst den Alias und dann die Einträge seines Ziels. Am Zonen-Apex, also auf der Domain selbst, ist kein CNAME erlaubt; DNS-Anbieter, die dort einen nachbilden, veröffentlichen einfache A- und AAAA-Einträge, und genau die siehst du hier. MX-Daten bestehen aus Präferenz und Host, etwa 10 mail.example.com., kleinere Zahlen zuerst; ein einzelnes 0 . ist ein Null-MX und bedeutet, dass die Domain keine E-Mails annimmt.
TTL, Caches und Propagation
DNS-Änderungen breiten sich nicht von deinem Anbieter aus nach außen aus. Jeder Resolver behält eine Kopie, solange die TTL es erlaubt, und fragt dann neu. Die TTL, die du siehst, zählt vom veröffentlichten Wert herunter: Ein Eintrag, der mit 3600 veröffentlicht und vor 20 Minuten zwischengespeichert wurde, zeigt etwa 2400. Bis zu einer vollen TTL nach einer Änderung haben manche Resolver den neuen Wert und manche den alten. Damit eine Änderung schnell ankommt, senke zuerst die TTL und warte mindestens die alte TTL ab, bevor du den Eintrag änderst. Nameserver-Wechsel dauern länger, weil NS-Einträge in der übergeordneten Zone oft TTLs von ein bis zwei Tagen haben. Unterschiedliche Antworten der beiden Resolver sind nicht immer ein Fehler: Geo-DNS und Lastverteilung passen Antworten daran an, woher die Frage zu kommen scheint.
Dieselben Abfragen im Terminal
dig +short example.com MX @1.1.1.1
dig _dmarc.example.com TXT @8.8.8.8
dig +dnssec example.com A @1.1.1.1
nslookup -type=SOA example.com 8.8.8.8
Resolve-DnsName example.com -Type MX -Server 1.1.1.1In der vollständigen Ausgabe von dig ist ad in der Zeile mit den Flags dasselbe DNSSEC-Signal wie hier. Ein Unterschied ist wichtig: dig nutzt einfaches DNS über Port 53, das manche Netze abfangen und selbst beantworten. Diese Seite nutzt HTTPS – widersprechen sich dig und diese Seite beim selben Resolver, antwortet also vermutlich etwas in deinem Netz an seiner Stelle.
Häufige Fragen
Warum zeigen Cloudflare und Google für denselben Namen unterschiedliche IP-Adressen?
Viele große Websites antworten je nachdem, woher die Frage zu kommen scheint, und nutzen dafür Geo-DNS oder Lastverteilung. Googles Resolver kann über EDNS Client Subnet einen Teil deiner IP-Adresse an den autoritativen Server weitergeben, sodass die Antwort auf dein Netz zugeschnitten ist; Cloudflares Antwort hängt dagegen vom Standort des eigenen Servers ab. Zwei verschiedene Adressen können also beide richtig sein. Ein Problem ist das nur, wenn eine davon zu einem Host gehört, den der Domaininhaber stillgelegt hat.
Ich habe einen Eintrag vor einer Stunde geändert – warum sehe ich immer noch den alten Wert?
Ein Resolver, der den alten Eintrag im Cache hat, liefert ihn weiter aus, bis dessen TTL abgelaufen ist; die TTL, die hier angezeigt wird, ist die Restlaufzeit dieser Kopie. Hatte der alte Eintrag eine TTL von 86.400 Sekunden, kann eine zwischengespeicherte Kopie bis zu einem Tag halten. Führe die Abfrage auch beim anderen Resolver aus. Zeigt der schon den neuen Wert, ist deine Zone in Ordnung, und du wartest nur darauf, dass ein Cache abläuft.
Was ist der Unterschied zwischen NXDOMAIN und einer leeren Antwort?
NXDOMAIN heißt, dass der Name überhaupt nicht existiert, für keinen Eintragstyp. NOERROR ohne Einträge heißt, dass der Name existiert, aber nichts vom angefragten Typ hat – etwa bei einer AAAA-Abfrage für einen Host, der nur eine IPv4-Adresse hat. Liefert ein Name, den du gerade erst angelegt hast, NXDOMAIN, hält ein Resolver womöglich noch eine negative Antwort im Cache, die er gespeichert hat, bevor es den Namen gab.
Sieht iseeu.cc, welche Domains ich abfrage?
Nein. Dein Browser schickt die Anfrage per HTTPS direkt an Cloudflare oder Google; sie läuft nicht über die Server von iseeu.cc. Der gewählte Resolver sieht allerdings deine IP-Adresse und den Namen, und dafür gilt seine eigene Datenschutzerklärung. Die Abfrage, die hinter dem # in der Seitenadresse steht, wird nie an einen Server gesendet. iseeu.cc protokolliert weder IP-Adressen noch Abfragen, führt keine Besucherdatenbank, setzt keine Cookies und zeigt keine Werbung.
Warum kann ich auf meiner Domain ohne www keinen CNAME setzen?
Der Zonen-Apex, also die Domain selbst, muss SOA- und NS-Einträge enthalten, und ein CNAME darf seinen Namen mit keinem anderen Eintrag teilen. Manche DNS-Anbieter bieten für den Apex einen Alias an – je nach Firma ALIAS, ANAME oder Flattening genannt –, der das Ziel für dich nachschlägt und ganz normale A- und AAAA-Einträge veröffentlicht. Eine Abfrage auf dieser Seite zeigt dann diese Adressen statt eines CNAME.
Die Antwort ist nicht als DNSSEC-validiert markiert. Stimmt da etwas nicht?
Meistens nicht. Der Resolver setzt das AD-Flag nur, wenn die Domain signiert ist und die Signaturen von der Root abwärts gültig sind. Die meisten Domains sind nicht signiert und kommen deshalb ohne das Flag zurück. Bedenklich ist nur eine signierte Domain, deren Validierung scheitert: Validierende Resolver liefern dann SERVFAIL statt einer Antwort, oft weil ein DS-Eintrag beim Registrar nicht mehr zu den Schlüsseln der Zone passt.
Wie prüfe ich mit dem Tool die E-Mail-Einstellungen einer Domain?
Frag MX für die Domain ab, um zu sehen, welche Hosts ihre E-Mails annehmen. Frag dann TXT für denselben Namen ab und achte darauf, dass es genau einen String gibt, der mit v=spf1 beginnt. Danach fragst du TXT für _dmarc vor der Domain ab, zum Beispiel _dmarc.example.com, um die DMARC-Richtlinie zu lesen. DKIM-Schlüssel liegen unter einem Selektor-Namen innerhalb von _domainkey; den Selektor bekommst du von dem Dienst, der die E-Mails verschickt.
Wie lange dauert es, bis eine DNS-Änderung überall angekommen ist?
Bis zu einer vollen TTL: Jeder Resolver behält seine Kopie, solange die TTL es erlaubt, und fragt erst dann neu. In dieser Zeit liefern manche Resolver schon den neuen Wert und andere noch den alten. Soll eine Änderung schnell ankommen, senke zuerst die TTL und warte mindestens die alte TTL ab, bevor du den Eintrag änderst. Ein Wechsel der Nameserver dauert länger, weil NS-Einträge in der übergeordneten Zone oft TTLs von ein bis zwei Tagen haben.
DNS-Antworten ändern sich, wenn Einträge bearbeitet werden und Caches ablaufen. Die Ergebnisse zeigen, was der gewählte Resolver im Moment deiner Abfrage geliefert hat, und sind keine Garantie dafür, was jeder andere Resolver gespeichert hat.