DNS-Eintrag prüfen: A, MX, TXT und TTL

$ dig cyberscale.io A +short
75.2.60.5

So sieht die Antwort aus, die jeder bekommt, der nach der Adresse dieser Domain fragt. Sie ist richtig, und sie ist trotzdem nicht verbindlich: Was dig ohne Zusatz liefert, stammt aus dem Zwischenspeicher irgendeines Resolvers und gilt nur noch so lange, wie die TTL daneben sagt. Verbindlich ist allein die Antwort des autoritativen Namensservers. Wer einen Eintrag ändert und danach sofort eine andere Antwort erwartet, misst meist den Zwischenspeicher und hält dessen Trägheit für einen Fehler.

Die Satzarten, die im Alltag zählen#

Ein A-Eintrag verweist auf eine IPv4-Adresse, ein AAAA-Eintrag auf eine IPv6-Adresse. Beide dürfen nebeneinander und mehrfach vorkommen; mehrere Adressen für denselben Namen sind Lastverteilung, kein Widerspruch.

Ein CNAME ist ein Aliasname. Er zeigt auf einen anderen Namen, der dann selbst aufgelöst wird. Neben einem CNAME darf unter derselben Bezeichnung nichts anderes stehen (RFC 1034, Abschnitt 3.6.2), und am Zonenursprung, also auf der Domain ohne Unterdomain, ist er deshalb nicht zulässig, weil dort SOA und NS liegen müssen. Anbieter, die dort trotzdem etwas Ähnliches erlauben, lösen das intern auf und liefern A-Einträge aus.

MX nennt die Server, die Mails für die Domain annehmen, jeweils mit einer Vorrangzahl; der niedrigere Wert hat den höheren Vorrang. TXT ist Freitext und damit der Sammelplatz der Zone: SPF, DMARC, DKIM-Schlüssel unter einer eigenen Unterdomain, Bestätigungscodes fremder Dienste. NS benennt die autoritativen Namensserver. CAA (RFC 8659) legt fest, welche Zertifizierungsstellen für die Domain Zertifikate ausstellen dürfen; fehlt er, darf jede.

Eine Zone, vollständig gelesen#

In eigener Sache die Zone dieses Magazins, abgefragt am 03.10.2026 um 04:48 UTC. Auf dem Rechner, an dem das entstand, war dig nicht installiert; die Abfrage lief deshalb per DNS-over-HTTPS (RFC 8484) gegen den Resolver von Cloudflare, der dieselbe Auskunft als JSON liefert:

curl -s -H 'accept: application/dns-json' \
  'https://cloudflare-dns.com/dns-query?name=cyberscale.io&type=A'

Die Antworten, auf das Wesentliche gekürzt:

Was man daran ablesen kann, ohne die Betreiberin zu fragen: Die Website liegt beim Hoster, dessen Name im CNAME steht, die Post bei einem anderen Anbieter (MX), und der Namensdienst bei einem dritten (NS). Es gibt kein IPv6. Es gibt keinen CAA-Eintrag, also darf jede Zertifizierungsstelle ausstellen. Die Zone selbst hält ihre Antworten eine Stunde für gültig, der Hoster seine Adressen nur zwei Minuten, damit er sie schnell wechseln kann. Und im TXT steht neben SPF der Bestätigungscode eines Google-Dienstes, also ein Hinweis darauf, welche Werkzeuge im Einsatz sind.

Genau diese Lesart gilt für jede fremde Zone auch.

Abfragen mit dig, nslookup und DoH#

dig liegt auf macOS und den meisten Linux-Systemen bei, nslookup gibt es überall, auch unter Windows.

dig beispiel.de A +short
dig beispiel.de MX +short
dig beispiel.de TXT +short
dig beispiel.de NS +short

Ohne +short erscheint der vollständige ANSWER-Abschnitt, und dort steht in der zweiten Spalte die Zahl, auf die es ankommt: die verbleibende TTL in Sekunden.

nslookup beispiel.de
nslookup -type=MX beispiel.de
nslookup -type=TXT beispiel.de

Ein bestimmter Resolver lässt sich gezielt befragen, bei dig mit @, bei nslookup als zweites Argument:

dig @9.9.9.9 beispiel.de A
nslookup beispiel.de 1.1.1.1

Die wichtigste Variante ist die Frage an den autoritativen Server selbst. Erst die NS-Einträge holen, dann einen davon direkt fragen:

dig @ns1.domainion.at cyberscale.io A

Diese Antwort ist die verbindliche. Jede andere zeigt, was ein Zwischenspeicher gerade noch vorrätig hält.

Warum zwei Resolver verschieden antworten#

Meistens, weil sie verschieden alte Kopien halten. Der autoritative Server liefert die eingestellte TTL mit, oben 3600 Sekunden. Ein Resolver, der die Antwort speichert, zählt diesen Wert herunter und gibt den Rest weiter. Fragt man denselben Namen im Abstand einer Minute zweimal, sinkt die angezeigte TTL um sechzig. Bei null wird beim autoritativen Server neu geholt.

Dazu kommen Ebenen, die man leicht übersieht: der Zwischenspeicher des Betriebssystems, der des Browsers und der Resolver des Zugangsanbieters. Den Zwischenspeicher des Betriebssystems leert unter Windows ipconfig /flushdns; weitere Handgriffe dieser Art sammelt Windows-FAQ.

Der zweite Grund ist Absicht. Manche Zonen antworten je nach Herkunft der Anfrage unterschiedlich, etwa bei Lastverteilung oder einem Content Delivery Network. Zwei abweichende Antworten sind dann beide korrekt.

Auch negative Antworten werden gespeichert: Existiert ein Name nicht, merkt sich der Resolver das für die im SOA hinterlegte Dauer (RFC 2308). Deshalb wirkt ein frisch angelegter Eintrag manchmal träger als die Änderung eines bestehenden.

Was „propagieren“ heißt#

Nichts wird verteilt. DNS schiebt keine Daten durch das Netz. Eine Änderung steht auf dem autoritativen Server unmittelbar nach dem Speichern und ist dort sofort messbar. Der Rest der Welt erfährt davon, weil alte Kopien ablaufen und bei Bedarf neu geholt werden.

Daraus folgt das ganze Vorgehen: Die Wartezeit ist nach oben durch die alte TTL begrenzt, durch den Wert also, der vor der Änderung galt. Wer einen Umzug plant, senkt die TTL rechtzeitig vorher, lässt die alte Frist verstreichen, ändert dann den Eintrag und setzt die TTL anschließend wieder herauf. Bei der Zone oben hieße das: 3600 Sekunden vor dem Umzug auf 300 gehen, eine Stunde warten, umziehen.

Eine Ausnahme ist der Wechsel der Namensserver. Dort wirkt zusätzlich die TTL, die die übergeordnete Zone für die Delegierung vorgibt, und darauf hat der Domaininhaber keinen Einfluss.

Karten mit grünen und roten Punkten aus sogenannten Propagation-Checkern zeigen den Speicherstand einiger öffentlicher Resolver. Das ist eine Stichprobe, kein Fortschrittsbalken.

Was die Adresse aus dem A-Eintrag nicht sagt#

Eine IP-Adresse ist einem Netzbetreiber zugeteilt, nicht einem Ort. Was Standortdienste anzeigen, ist der eingetragene Sitz dieses Betreibers oder eine Schätzung aus Laufzeitmessungen. Bei Servern in Rechenzentren liegt das oft um Länder daneben.

Läuft eine Seite über ein Content Delivery Network, gibt es den einen Standort gar nicht. Ein CDN beantwortet jede Anfrage vom nächstgelegenen Knoten; zwei Menschen in verschiedenen Ländern bekommen verschiedene Adressen für dieselbe Domain, und beide sind richtig. Die Zone oben zeigt das im Kleinen: Die beiden Adressen hinter dem CNAME gehören dem Hoster, nicht der Betreiberin, und sie können morgen andere sein.

Wofür die Adresse trotzdem taugt: für den Betreiber der Infrastruktur, dessen Missbrauchskontakt öffentlich abfragbar ist (dorthin gehört ein Hinweis auf eine Betrugsseite, nicht zum Registrar); für Zusammenhänge, wenn zwei Seiten auf derselben eigenen Adresse liegen; und für die eigene Erreichbarkeit nach einem Umzug, die eine einzelne Abfrage beantwortet.

Was sich regelmäßig zu prüfen lohnt#

Zeigt noch alles dorthin, wo es soll? Alte A- oder CNAME-Einträge für Subdomains, die es nicht mehr gibt, sind ein bekannter Angriffsweg: Wer das verwaiste Ziel übernimmt, bekommt eine Subdomain der fremden Domain.

Stimmt die Mail-Absicherung? MX, SPF, DKIM und DMARC stehen in derselben Zone. Wie oft davon etwas fehlt, steht mit Zahlen aus 149 Tiroler Domains in DMARC einrichten; wie man den SPF-Eintrag liest, in SPF-Eintrag erstellen und prüfen. Wer wissen will, wer die Zone überhaupt verwaltet: Wem gehört eine Website.

Stand 03.10.2026. Quellen abgerufen und Befehle nachgestellt am selben Tag.