Live-Abfrage · Einträge einer Domain
Geben Sie eine Domain ein und fragen Sie sie direkt hier auf Deutsch ab: A-, AAAA-, MX-, TXT-, NS-, CNAME-, CAA- und SOA-Einträge, ihre Werte und die TTL, mit der sie ausgeliefert werden. Es ist die Sicht eines öffentlichen Resolvers in diesem Moment, nicht die vollständige Zone und nicht das interne DNS von irgendjemandem.
DNS-Abfrage
Geben Sie eine Domain ein und wählen Sie den Eintragstyp. „ALL“ liefert das vollständige Inventar – A, AAAA, CNAME, MX, TXT, NS, CAA, SOA, DS und DNSKEY –, jede andere Option beschränkt die Antwort auf einen einzigen Typ. Jede Zeile kommt mit ihrer TTL.
Wählen Sie „ALL“ für das vollständige Inventar oder einen bestimmten Typ, um die Antwort einzugrenzen.
Nutzt die Route /api/dns-lookup von MyIPScan, gestützt auf einen öffentlichen Resolver für DNS über HTTPS. Es ist die Sicht eines Resolvers: Das Ergebnis kann sich je nach Netz, Cache und Verbreitung ändern.
Das Formular oben liefert öffentliche DNS-Einträge: A (IPv4), AAAA (IPv6), MX (E-Mail), TXT (Verifizierung und SPF), NS (Nameserver), CNAME (Alias) und die übrigen verfügbaren Typen. Der Rest der Seite erklärt, was jeder einzelne bedeutet.
Sie greift nicht auf private oder interne DNS-Einträge zu. Die Ergebnisse hängen von der DNS-Verbreitung ab und können sich bei kürzlichen Änderungen zwischen Resolvern unterscheiden.
Eine DNS-Abfrage fragt einen Resolver, welche Einträge eine Domain veröffentlicht, und liefert deren Werte so, wie sie in diesem Moment vorliegen: den A-Eintrag mit der IPv4, den AAAA-Eintrag mit der IPv6, den MX-Eintrag mit den Mailservern, den TXT-Eintrag mit SPF, DKIM und Verifizierungs-Tokens und den NS-Eintrag mit den Nameservern. Jede Antwort kommt mit ihrer TTL. Es ist die Sicht eines Resolvers, nicht die vollständige Zone der Domain.
Ihr Gerät tut das hunderte Male am Tag, ohne es Ihnen zu zeigen. Sie geben eine Domain ein, und bevor irgendetwas geöffnet wird, fragt Ihr Browser einen DNS-Server – den Resolver –, mit welcher IP-Adresse er sich verbinden soll. Der Resolver antwortet, der Browser verbindet sich, die Seite lädt.
Eine manuelle DNS-Abfrage stellt dieselbe Frage, aber absichtlich und mit der vollständigen Antwort vor Augen. Der Unterschied liegt im Ausgangspunkt: Die Frage stellt der Server von MyIPScan an einen öffentlichen Resolver für DNS über HTTPS, nicht Ihr Computer. Deshalb enthält das Ergebnis nicht den Cache Ihres Routers und hängt nicht vom Server ab, den Ihr Internetanbieter festgelegt hat – und deshalb eignet es sich zum Vergleichen: Sieht Ihr Gerät etwas anderes als diese Abfrage, liegt der Fehler nicht bei der Domain, sondern beim Cache dazwischen.
Diese Seite prüft, was eine Domain veröffentlicht. Welcher Resolver beim Surfen für Sie antwortet, ist eine andere Frage, und die beantwortet der DNS-Leak-Test.
Das Formular hat zwei Felder, mehr nicht. Das erste ist die Domain, die Sie ohne Zusätze eingeben – beispiel.de –, ohne Protokoll und ohne abschließenden Schrägstrich. Das zweite ist ein Auswahlmenü mit dem Eintragstyp, wobei „ALL“ das gesamte Inventar anfordert und jede andere Option die Antwort auf einen einzigen Typ beschränkt. Eine Schaltfläche startet die Abfrage.
Die Antwort kommt als Tabelle mit den Spalten Typ, TTL in Sekunden und Rohantwort, also dem Wert; im Modus „ALL“ kommt die Spalte „Warum dieser Eintrag wichtig ist“ hinzu. Den abgefragten Namen sehen Sie in der Übersicht über der Tabelle. Liefert ein Typ mehrere Einträge – bei MX, NS und TXT der Normalfall –, erscheinen alle, einer pro Zeile, ohne Zusammenfassung und ohne Sortierung nach Wichtigkeit.
Was Sie dort nicht finden: einen Änderungsverlauf, eine Karte der Subdomains oder eine Sicherheitsbewertung. Die Abfrage stellt eine konkrete Frage und zeigt die Antwort unverändert; sie zu deuten ist genau das, was diese Seite erklärt.
Alles, was folgt – was jeder Typ bedeutet, wie man die TTL liest, was zu tun ist, wenn das Ergebnis nicht passt –, gilt genauso für diese Abfrage, für dig im Terminal oder für das Dashboard Ihres DNS-Anbieters. Das Vokabular ist überall dasselbe, und was Sie hier lernen, bleibt nicht an einem Tool hängen.
„ALL“ liefert das Inventar in einem Durchgang; wer nur einen Typ abfragt, erhält ein übersichtlicheres Ergebnis.
Eine DNS-Antwort ist kein Satz, sondern eine Liste von Einträgen, und jeder Eintrag wird immer in derselben Reihenfolge gelesen: Name, Typ, TTL und Wert. Mit diesen vier Spalten lässt sich fast alles klären.
Der Name ist der, nach dem Sie gefragt haben, unverändert zurückgegeben. Ein Blick darauf lohnt sich, denn er verrät Unachtsamkeiten: Haben Sie nach www.beispiel.de gefragt und die Antwort spricht von beispiel.de, steckt dazwischen ein Alias, der Sie unbemerkt umgeleitet hat.
Der Typ bestätigt, um welche Art von Eintrag es sich in jeder Zeile handelt, und stimmt nicht immer mit dem überein, was Sie angefragt haben. Eine A-Abfrage für einen Namen, der in Wirklichkeit ein Alias ist, liefert zuerst den CNAME und danach den A-Eintrag des Ziels: zwei Zeilen unterschiedlichen Typs für eine einzige Frage.
Die TTL ist die Anzahl der Sekunden, die ein Resolver diese Antwort weiter ausliefern darf, ohne erneut zu fragen. Fragen Sie denselben Resolver nach einer Weile erneut, ist sie gesunken: Was Sie lesen, ist der Countdown der zwischengespeicherten Kopie, kein fester Wert des Eintrags. Diese Seite hält jede Antwort bis zu fünf Minuten selbst im Cache; innerhalb dieser Zeit sehen Sie hier dieselbe TTL. Springt die TTL auf ihren ursprünglichen Wert zurück, ist diese Kopie abgelaufen und der Resolver hat neu gefragt.
Der Wert hängt vom Typ ab. Bei einem A-Eintrag ist es eine IPv4-Adresse; bei einem MX-Eintrag eine Prioritätszahl, gefolgt von einem Servernamen; bei einem NS-Eintrag der Name eines Nameservers; bei einem TXT-Eintrag eine Zeichenkette in Anführungszeichen, die manchmal in Stücke geteilt ist, weil das Protokoll jedes Fragment auf 255 Zeichen begrenzt. Diese Aufteilung ist normal und macht nichts kaputt: Wer den Eintrag liest, fügt die Teile vor der Auswertung wieder zusammen.
Ein Detail, das Verwirrung erspart: Die Reihenfolge, in der die Zeilen eintreffen, hat keine Bedeutung. Viele Resolver rotieren die Antworten absichtlich, um den Datenverkehr zu verteilen; zwei Abfragen hintereinander können also dieselben Adressen in anderer Reihenfolge liefern, ohne dass sich ein einziger Eintrag geändert hat.
beispiel.de, ohne https:// und ohne abschließenden Schrägstrich. DNS versteht keine URLs, sondern Namen._dmarc.beispiel.de für DMARC, selector._domainkey.beispiel.de für DKIM, www.beispiel.de, wenn Sie vermuten, dass www auf ein anderes Ziel zeigt als die Hauptdomain.Das Abfrageformular – Domain und Eintragstyp – finden Sie am Anfang dieser Seite.
Der MX-Eintrag gibt an, an welche Server Nachrichten an die Domain zugestellt werden. Meist gibt es mehrere mit unterschiedlichen Prioritäten: Der Absender versucht zuerst die niedrigste Zahl und nimmt die nächste, wenn er keine Antwort erhält. Eine Domain ohne MX hat keinen ausgewiesenen Mailserver: Absender versuchen dann höchstens noch die Adresse aus dem A-Eintrag, und dort nimmt meist niemand E-Mails an – so perfekt die Website auch lädt. Wenn Sie gerade den Anbieter gewechselt haben, ist der Vergleich der alten mit den neuen MX-Einträgen die erste Prüfung, die sich lohnt.
Der TXT-Eintrag ist die Schublade, in der fast alles andere liegt. Dort steht SPF, das mit v=spf1 beginnt und festlegt, welche Server im Namen der Domain senden dürfen; der öffentliche DKIM-Schlüssel, abgelegt unter einer Subdomain der Form selector._domainkey.beispiel.de; und die DMARC-Richtlinie, die nicht unter der Hauptdomain, sondern unter _dmarc.beispiel.de veröffentlicht wird. Dieses Detail erklärt, warum so viele annehmen, eine Domain „habe kein DMARC“, obwohl sie in Wahrheit an der falschen Stelle nachgesehen haben.
Gehen Nachrichten hinaus, kommen aber nicht an, ist DNS nur die halbe Wahrheit: Die andere Hälfte ist der Ruf der Adresse, von der Sie senden, und den prüft die IP-Blacklist-Prüfung.
In der Praxis entstehen fast alle DNS-Abfragen aus einer dieser drei Situationen. Die Reihenfolge, in der Sie fragen, ist wichtiger als das Tool, mit dem Sie fragen.
Beginnen Sie mit dem MX-Eintrag der Empfängerdomain und bestätigen Sie, dass er existiert und auf die Server ihres Anbieters zeigt. Machen Sie mit dem TXT-Eintrag der Domain weiter, von der Sie senden, um den gesamten SPF zu lesen und zu prüfen, ob er den Dienst enthält, den Sie tatsächlich verwenden. Schließen Sie mit _dmarc.beispiel.de ab, wo die DMARC-Richtlinie liegt, und mit selector._domainkey.beispiel.de, wo sich der öffentliche DKIM-Schlüssel befindet. Nach vier Abfragen wissen Sie, ob das Problem im DNS liegt oder anderswo gesucht werden muss.
Fragen Sie die aktuellen A- und AAAA-Einträge ab und notieren Sie deren TTL, bevor Sie etwas ändern. Sind sie lang, senken Sie sie auf 300 und warten Sie, bis der alte Wert abgelaufen ist; erst dann ändern Sie die Adresse. Fragen Sie nach der Änderung alle paar Minuten erneut ab: Die neue Antwort erscheint bei manchen Resolvern früher als bei anderen, und genau so soll es sein. Ist die alte TTL überall abgelaufen, erhöhen Sie den Wert wieder, damit Ihre Nameserver nicht mit Anfragen überhäuft werden.
Fragen Sie den CAA-Eintrag der Domain ab. Veröffentlicht sie eine Liste von Zertifizierungsstellen und Ihre ist nicht darunter, wird die Ausstellung absichtlich und ohne weitere Erklärung abgelehnt. Eine Domain ohne CAA schränkt nichts ein, das Fehlen dieses Eintrags ist also nie die Ursache. Prüfen Sie außerdem, ob der genaue Name des Zertifikats aufgelöst wird: Viele Validierungen scheitern, weil www als Eintrag nicht existiert, nicht weil das Zertifikat falsch beantragt wurde.
Die TTL, englisch time to live, ist eine Zahl in Sekunden, die jede Antwort begleitet und angibt, wie lange ein Resolver sie im Cache halten darf, bevor er erneut fragt. Eine TTL von 300 entspricht fünf Minuten, eine von 86400 einem ganzen Tag.
Daher kommt, was alle „Propagation“ nennen – obwohl sich dabei nichts ausbreitet: Es ist das Ablaufen von Caches. Wenn Sie einen Eintrag ändern, ist der neue Wert sofort in der Zone veröffentlicht, aber jeder Resolver liefert den alten weiter aus, bis die gespeicherte TTL abgelaufen ist. Deshalb können zwei Personen in zwei verschiedenen Netzen unterschiedliche Antworten sehen und beide recht haben.
Die praktische Folge betrifft die Reihenfolge: Senken Sie vor einer Migration die TTL auf 300, warten Sie, bis die vorherige TTL abgelaufen ist, und ändern Sie erst dann den Eintrag. Bei neu angelegten Einträgen planen Sie bis zu 48 Stunden Spielraum ein.
Drei Ergebnisse sorgen für Verwirrung und bedeuten fast nie das, wonach sie aussehen.
Es erscheint kein A-Eintrag. Der Name wird zu keiner IP aufgelöst, und der Browser weiß nicht, wohin. Vielleicht wurde der Eintrag gelöscht oder nie angelegt, oder die Domain funktioniert nur über IPv6. Bei einer neuen Domain richten Sie den A-Eintrag auf die IP des Servers und fragen nach fünfzehn bis dreißig Minuten erneut ab.
Statt eines A-Eintrags erscheint ein CNAME. Das ist bei Subdomains, die auf einen externen Dienst zeigen, normal: Maßgeblich ist der Alias, und die endgültige Adresse veröffentlicht der Name, auf den er zeigt. Folgen Sie der Kette, indem Sie dieses Ziel abfragen.
Die IP ist nicht die Ihres Servers. Läuft die Domain über ein CDN oder einen Reverse Proxy, veröffentlicht der A-Eintrag die Adresse des Proxys, nicht die des Ursprungsservers. Das ist erwartetes Verhalten – und der Grund, warum eine DNS-Abfrage den Ursprungsserver nicht ausfindig macht.
Um herauszufinden, wem diese Adresse gehört, übersetzt die ASN-Abfrage die Netznummer in eine Organisation, und die IP-Geolokalisierung liefert den ungefähren Standort, den die Datenbanken veröffentlichen. Die WHOIS-Abfrage ergänzt Registrar, Daten und Status der Domain: Angaben aus der Registrierung, nicht aus dem DNS.
Liefert eine Abfrage nicht das Erwartete, steckt die Erklärung meist im Antwortcode. Drei davon sollten Sie auseinanderhalten, denn auf dem Bildschirm ähneln sie sich und bedeuten doch sehr Unterschiedliches.
NXDOMAIN heißt, dass der Name in der Zone nicht existiert. Es fehlt nicht nur dieser Eintragstyp: Unter diesem Namen ist überhaupt nichts veröffentlicht. Bei einer frisch gekauften oder frisch delegierten Domain ist das eine Weile lang normal; bei einer Domain, die gestern noch funktionierte, deutet es auf einen gelöschten Eintrag oder eine abgelaufene Domain hin, und das klärt die WHOIS-Abfrage besser als jede DNS-Abfrage.
Korrekte, aber leere Antwort ist die verwirrendste. Der Name existiert, die Frage wurde fehlerfrei beantwortet, und trotzdem kommt die Liste ohne Einträge: Das bedeutet, dass dieser Name genau diesen Typ nicht veröffentlicht. Eine Domain mit Website, aber ohne E-Mail liefert genau das, wenn Sie nach MX fragen – und kaputt ist nichts.
SERVFAIL sagt nichts über die Domain, sondern über die Auflösung. Der Resolver hat versucht zu antworten und konnte es nicht: Nameserver, die nicht reagieren, eine fehlerhafte Delegation zwischen Registrierung und Zone oder eine DNSSEC-Signatur, die sich nicht validieren lässt. Liefert eine Domain bei einem Resolver SERVFAIL und antwortet bei einem anderen normal, sind Signatur oder Delegation die ersten Verdächtigen.
Bleibt ein vierter Fall ohne eigenen Code: Die Antwort kommt, ist korrekt, und der Wert ist veraltet. Hier ist nichts kaputt. Es ist der Cache, der seine Arbeit tut, und das Problem löst sich, sobald die TTL abläuft.
Nichts davon ist einer Website vorbehalten. Jedes Betriebssystem bringt ein Tool mit, das dieselbe Frage stellt, und es lohnt sich, es zu kennen, denn es antwortet aus Ihrem Netz und nicht von einem entfernten Server.
Unter macOS und Linux liefert dig beispiel.de MX die Mail-Einträge mit ihrer TTL. Mit +short bleiben nur die Werte übrig, ohne Kopfzeilen und Abschnitte. Und um einen bestimmten Resolver zu fragen, setzen Sie einfach dessen Adresse davor: dig @1.1.1.1 beispiel.de A fragt diesen Server und nicht den, der in Ihrem System eingestellt ist.
Unter Windows leistet nslookup -type=MX beispiel.de dasselbe, und nslookup -type=TXT _dmarc.beispiel.de zeigt die DMARC-Richtlinie. Am Ende der Zeile akzeptiert es auch einen Server, wenn Sie den Resolver Ihres Netzes umgehen möchten.
Der Unterschied zur Abfrage auf dieser Seite ist genau der Ausgangspunkt, und deshalb lohnt es sich, beide griffbereit zu haben. Ihr Terminal fragt über den Resolver Ihres Netzes, einschließlich dessen Cache; eine entfernte Abfrage fragt von woanders und mit einem anderen Cache. Stimmen beide überein, ist der Wert verbreitet; wenn nicht, wissen Sie, auf welcher Seite die veraltete Kopie liegt.
Die Abfrage fragt nach dem Namen und dem Typ, die Sie eingeben, und liefert das, was ein öffentlicher Resolver in diesem Moment antwortet. Das ist ihre Reichweite und ihre Grenze.
Sie listet keine Subdomains auf: Wonach Sie nicht fragen, das erscheint nicht. Sie sieht nicht das interne DNS eines Unternehmens, das innerhalb des Firmennetzes etwas anderes antworten kann. Sie beweist nicht, wem die Domain gehört, und bescheinigt nicht, dass ihre Konfiguration sicher ist – und dass ein Eintrag existiert, heißt nicht, dass der Dienst dahinter funktioniert.
Außerdem kann die Antwort aus einem Cache stammen, delegiert sein oder über einen Proxy laufen: Sie ist ein öffentliches, wiederholbares Signal, keine endgültige Wahrheit über die Infrastruktur. Die Methodik auf Deutsch erklärt, wie jedes Signal eingeordnet wird und wo es endet. Dieselbe Abfrage mit englischer Oberfläche finden Sie unter DNS Lookup.
Geben Sie die Domain ohne „https://“ und ohne abschließenden Schrägstrich ein, wählen Sie „ALL“ für das vollständige Inventar und starten Sie die Abfrage über das Formular auf dieser Seite. Die Anfrage geht vom Server von MyIPScan an einen öffentlichen Resolver für DNS über HTTPS, die Antwort hängt also nicht vom Cache Ihres Geräts oder Ihres Routers ab. Eine Subdomain geben Sie vollständig ein.
Der MX-Eintrag gibt an, an welche Server E-Mails für diese Domain zugestellt werden sollen. Meist gibt es mehrere mit einer Prioritätszahl: Der Absender versucht zuerst die niedrigste und arbeitet sich die Liste hinunter, wenn sie nicht antwortet. Eine Domain ohne MX-Einträge hat keinen ausgewiesenen Mailserver; Absender versuchen dann höchstens noch die Adresse aus dem A-Eintrag, und dort nimmt meist niemand E-Mails an, auch wenn die Website normal lädt.
Ein Eintrag mit freiem Text, auf dem fast die gesamte E-Mail-Authentifizierung aufbaut. Dort stehen SPF, das mit v=spf1 beginnt und festlegt, wer im Namen der Domain senden darf, der öffentliche DKIM-Schlüssel unter einer Subdomain der Form selector._domainkey.beispiel.de sowie Tokens zur Verifizierung der Inhaberschaft. Die DMARC-Richtlinie wird separat unter _dmarc.beispiel.de veröffentlicht.
Fast immer liegt es am Cache. Jede DNS-Antwort trägt eine TTL, und Resolver behalten den Wert, bis diese Zeit abläuft. Haben Ihr Computer, Ihr Router oder der Resolver Ihres Internetanbieters den alten Wert gespeichert, liefern sie ihn weiter aus, auch wenn die Domain bereits einen anderen veröffentlicht. Warten Sie, bis die TTL abgelaufen ist, bevor Sie von einem Fehler ausgehen.
So lange, wie die TTL des alten Eintrags vorgibt, nicht die des neuen. Wurde der alte Wert mit einer TTL von 86400 veröffentlicht, liefern manche Resolver ihn noch bis zu 24 Stunden nach der Änderung aus. Deshalb sollten Sie die TTL vor einer Migration auf 300 senken, abwarten, bis die lange TTL abgelaufen ist, und erst dann den Eintrag ändern.
Es bedeutet, dass dieser Name zu keiner IPv4-Adresse aufgelöst wird. Der Browser weiß also nicht, wohin er sich verbinden soll, und die Website lädt nicht. Vielleicht wurde der Eintrag gelöscht oder nie angelegt, oder die Domain veröffentlicht nur AAAA und funktioniert über IPv6. Bei einer neuen Domain legen Sie den A-Eintrag mit der IP des Servers an und fragen nach fünfzehn bis dreißig Minuten erneut ab.
Nein. Die Abfrage antwortet nur für den exakten Namen, den Sie eingeben; eine Subdomain, nach der Sie nicht fragen, taucht nirgends auf. Das Auflisten von Subdomains liegt außerhalb dessen, was diese Abfrage leistet – absichtlich, nicht aus einem Fehler heraus. Wenn Sie den Namen kennen, geben Sie ihn vollständig ein und fragen Sie ihn separat ab.
Dies sind die freigegebenen deutschen Seiten. Sie verlinken nicht auf künftige Ratgeber, Ranglisten, Affiliate-Angebote oder Entwürfe.