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

Ein DNS-Eintrag ist eine Auskunft mit Haltbarkeitsdatum, kein Schalter. Wer etwas ändert und danach sofort eine andere Antwort erwartet, misst meistens nicht die Zone, sondern den Zwischenspeicher irgendeines Resolvers — und hält dessen Trägheit für einen Fehler.

Die Satzarten, die im Alltag zählen#

A und AAAA. 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.

CNAME. Ein Aliasname, der nicht auf eine Adresse zeigt, sondern auf einen anderen Namen, der dann selbst aufgelöst wird. Neben einem CNAME darf unter derselben Bezeichnung nichts anderes stehen, und am Zonenursprung — also auf der Domain ohne Unterdomain — ist er 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 am Ende 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. 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 der Zone, also die Server mit der verbindlichen Antwort. Alles andere im Netz sind Kopien mit Ablaufdatum.

Abfragen mit dig und nslookup#

dig liegt auf macOS und Linux bei, nslookup gibt es auf jedem System einschließlich 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 eigentlich interessante Zahl: die verbleibende TTL in Sekunden.

Dasselbe mit dem Bordmittel:

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.beispiel.de beispiel.de A

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

Warum zwei Resolver verschieden antworten#

Weil sie verschieden alte Kopien halten. Der autoritative Server liefert die eingestellte TTL mit, etwa 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 Browser mit einem eigenen Speicher und der Resolver des Zugangsanbieters, der kurze TTLs mitunter künstlich verlängert.

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. Deshalb wirkt ein frisch angelegter Eintrag manchmal träger als die Änderung eines bestehenden.

Was „propagieren“ wirklich 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 nur, weil alte Kopien ablaufen und bei Bedarf neu geholt werden.

Daraus folgt das gesamte praktische Vorgehen. Die Wartezeit ist nach oben durch die alte TTL begrenzt — durch den Wert also, der vor der Änderung galt, nicht durch den neuen. 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.

Eine Ausnahme betrifft den Wechsel der Namensserver: Dort wirkt zusätzlich die TTL, die die übergeordnete Zone für die Delegierung vorgibt. Darauf hat der Domaininhaber keinen Einfluss.

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

Weiterlesen#

Was hinter der Adresse aus dem A-Eintrag steckt und warum der angezeigte Standort selten stimmt, steht unter IP-Adresse einer Website herausfinden. Wer die TXT-Einträge ohnehin gerade offen hat, liest sie am besten gleich richtig: SPF-Eintrag prüfen. Und wer wissen will, wer die Zone überhaupt verwaltet: Wem gehört eine Website.