A Record Suche (IPv4)

Host

Typ

Resolver

Iterativer Trace

Im iterativen Tracemodus wird der Resolver ignoriert.

Propagationstest

Fragt mehrere öffentliche Resolver ab, um die Antworten zu vergleichen.

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 des TLD (.com, .fr, .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 und Regionen vergleichen
Einen warmen Cache, einen zu langen 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 eines 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, OpenDNS, ISPs …) und gruppiert die Antworten nach Inhalt und RCODE. Sie sehen sofort, wer die Aktualisierung bereits übernommen hat.

1. Multipoint-Resolver
Aktiviert die Propagations-Presets, um mehrere Akteure weltweit abzufragen.
2. Automatischer Vergleich
Gruppiert identische Antworten und hebt Abweichungen oder resolver-spezifische Fehler hervor.
3. Verwertbare Zusammenfassung
Liefert eine klare Übersicht, die Resolverliste, deren Latenzen und den Status jeder Gruppe.

Wann einsetzen?

Verfolgen, wie sich eine DNS-Änderung weltweit verbreitet
Veraltete Caches erkennen und über einen gezielten Flush entscheiden
Einen Propagationsstatus in einem Ticket oder Post-Mortem teilen

Tipp: Während des Propagationstests ist die Resolverauswahl gesperrt. Deaktivieren Sie den Modus, um zur Einzelanalyse zurückzukehren.

Zusätzliche Informationen zu DNS-Einträgen vom Typ A

Ein A Record verbindet einen Domainnamen mit einer IPv4 Adresse. Zum Beispiel ist es die Antwort dieses Eintrags, die dem Browser den richtigen Server für den Besuch einer Website liefert. Für IPv6 verwendet man einen DNS Eintrag vom Typ AAAA. Außerdem macht ein DNS-Eintrag vom Typ PTR das Gegenteil und ordnet eine IPv4 Adresse einem Namen zu.
Ein A Record enthält einen Namen, einen Typ, einen Wert und einen TTL Wert. Der TTL-Wert gibt an, wie lange die Antwort im Cache des lokalen Resolvers bleibt.

Beispiel DNS Eintrag vom Typ A

Name	Typ	IPv4 Adresse	TTL in Sekunden
www	A	203.0.113.10	3600

In diesem Beispiel bezeichnet der Name www eine Subdomain. Um die Wurzel der Domain anzusprechen verwendet man das At Zeichen. Der Wert muss eine gültige über das Internet erreichbare IPv4 Adresse sein. Ein TTL von 3600 entspricht einer Stunde.

Beispiel mit mehreren Adressen

Mehrere A Einträge für denselben Namen zu veröffentlichen ist möglich. Der lokale Resolver erhält eine Liste und wählt eine aus. Das verteilt die Last auf einfache Weise.

Name	Typ	IPv4 Adresse	TTL in Sekunden
www	A	203.0.113.10	3600
www	A	203.0.113.11	3600

Diese Rotation ersetzt kein echtes automatisches Failover. Bei einer Störung können manche Besucher für kurze Zeit dennoch die nicht erreichbare Adresse erhalten.

TTL einfach erklärt

Ein kurzer TTL-Wert macht eine Änderung schneller sichtbar. Während einer Migration kann ein TTL von 60 Sekunden hilfreich sein.
Ein mittlerer oder langer TTL-Wert verringert Anfragen an die autoritativen Server und ist für einen stabilen Dienst sinnvoll.
Es wird empfohlen den TTL einige Stunden vor dem Wechsel zu senken und ihn nach Abschluss der Migration wieder zu erhöhen.

Gut zu wissen
TTL ist kein Versprechen sofortiger Propagation. Caches respektieren die angegebene Dauer. Die Aktualisierung erscheint, wenn der Zähler beim Resolver auf null fällt.

Wo ein A Record eingesetzt wird

An der Wurzel eines Domainnamens dem sogenannten Apex veröffentlicht man A Einträge. Ein CNAME dort ist nicht konform.
Für www kann man einen A Eintrag verwenden, wenn man die IP Adresse selbst kontrolliert. Andernfalls wählt man einen CNAME, wenn auf einen anderen vom Anbieter verwalteten Namen gezeigt wird.
Für andere Subdomains wie api cdn blog kann man ebenfalls DNS Einträge vom Typ CNAME A oder AAAA nutzen. Jeder Dienst kann eine eigene Adresse haben. Änderungen bleiben dadurch einfacher.

Zu vermeiden
A und CNAME auf demselben Namen mischen ist nicht RFC konform.
Eine private Adresse in einer öffentlichen Zone veröffentlichen.
Einen alten A Record nach einer Migration stehen lassen..

Online prüfen

Eine Online-DNS-Abfrage erlaubt es, einen Domainnamen einzugeben. So erhält man die Liste der IPv4 Adressen des A Eintrags sowie den im Internet sichtbaren TTL. Das ist eine erste hilfreiche Kontrolle. Danach lokal am eigenen Rechner testen.

Unter Windows prüfen

Windows stellt nslookup bereit. Es lässt sich im interaktiven Modus nutzen.

Lokaler Resolver

nslookup
set q=a
www.beispiel.com

Spezifischer Resolver

nslookup
set q=a
server 1.1.1.1
www.beispiel.com

Der erste Teil fragt einen A Eintrag über die Netzwerkkonfiguration des Rechners ab. Der zweite Teil erzwingt die Nutzung eines Drittanbieter Resolvers hier Cloudflare.

Unter Linux und unter Mac prüfen

Auf diesen Systemen ist der Befehl dig praktisch und einfach zu verwenden.

Lokaler Resolver

dig a www.beispiel.com

Spezifischer Resolver

dig a www.beispiel.com @1.1.1.1

Antworten schnell lesen

Mehrere IPv4 Adressen bedeuten eine einfache Lastverteilung.
Ein noch hoher TTL-Wert kann eine Verzögerung nach einer Änderung erklären.
Eine leere Antwort oder ein Auflösungsfehler deutet oft auf einen Eingabefehler oder eine zu früh entfernte Adresse hin.

Einfache Migrationsabfolge

Den neuen Server mit seiner neuen Adresse vorbereiten.
Den TTL auf 300 oder sogar 60 Sekunden am betroffenen Namen einige Stunden vor dem Wechsel senken.
Die alte Adresse zum geplanten Zeitpunkt durch die neue ersetzen.
Mit nslookup oder dem Befehl dig aus mehreren Netzen prüfen.
Den TTL wieder auf einen komfortablen Wert erhöhen wenn alles stabil ist.

Praktischer Tipp
Für jeden Namen ein Begleitblatt führen. Verantwortliche Person Datum gewählter TTL und Grund der Änderung notiert. Diese Spur verhindert Auslassungen und beschleunigt eine Rückkehr zum vorherigen Zustand, falls nötig.

Häufige Fälle

Website hinter einem Content Delivery Network CDN

Für www einen CNAME verwenden, um Anbieteränderungen zu folgen, und auf der Root Domain einen DNS Eintrag vom Typ A beibehalten.

Mehrregionen Umgebung

Mehrere Adressen in der Nähe der Besucher veröffentlichen. Der lokale Resolver wählt eine IPv4 Adresse aus der Liste. Für präzises standortbasiertes Routing sind erweiterte DNS Funktionen oder ein Anwendungsnetz erforderlich.

Mailserver

Der A Eintrag veröffentlicht die IPv4 Adresse des Mailservers. Der Reverse PTR verbessert die Zustellbarkeit. Beide sollten zueinander passen. Die Aktualisierung synchronisiert sich nicht automatisch in beide Richtungen.

Schnelle Fehlerbehebung

Wenn die Website nicht antwortet zuerst die lokale Auflösung prüfen.
Wenn die Antwort eine private Adresse zeigt die öffentliche Zone korrigieren.
Wenn die Antworten zwischen zwei Adressen wechseln und eine davon offline ist die fehlerhafte Adresse entfernen.
Wenn die Antwort trotz Aktualisierung alt bleibt auf das Ablaufen des TTL warten und nach Möglichkeit den Cache des lokalen Resolvers leeren.

Zusammengefasst ein A Eintrag ordnet einen Namen einer IPv4 Adresse zu. Der TTL-Wert steuert die Cachedauer im lokalen Resolver. Mehrere Adressen können den Traffic verteilen, schaffen aber kein Failover. Ein CNAME lebt nicht zusammen mit einem A Eintrag auf demselben Namen. Am Apex veröffentlicht man A Einträge. Die Prüfung beginnt mit einem Online Werkzeug dann mit nslookup unter Windows und mit dig unter Linux und unter Mac.
Mit diesen Anhaltspunkten bleibt die Verwaltung einfach. Änderungen laufen ohne Stress. Besucher erreichen die Website ohne Zwischenfälle.