Zum Hauptinhalt springen

A-Record-Abfrage (IPv4)

Überprüfen Sie die IPv4-Adresse Ihrer Domain in Sekunden

Website reagiert nicht? Überprüfen Sie, ob der A-Record auf die richtige IPv4-Adresse zeigt. Vergleichen Sie Antworten von mehreren DNS-Resolvern, um Propagierungsprobleme zu erkennen.

Im iterativen Tracemodus wird der Resolver ignoriert.
Fragt mehrere öffentliche Resolver ab, um die Antworten zu vergleichen.

Sofortige Auflösung

Erhalten Sie die IPv4-Adresse einer Domain in Echtzeit. Vergleichen Sie Antworten von Google, Cloudflare, Quad9 und dem autoritativen Server.

Diskrepanzerkennung

Identifizieren Sie Unterschiede zwischen Resolvern. Erkennen Sie veraltete Caches, die noch die alte Adresse zurückgeben.

Vollständige iterative Trace

Visualisieren Sie den DNS-Pfad: Root → TLD → autoritativ. Identifizieren Sie, welcher Schritt langsam ist oder fehlschlägt.

TTL und Latenz

Überprüfen Sie die verbleibende TTL, um zu wissen, wann der Cache abläuft. Messen Sie die Latenz jedes Resolvers.

Kostenlos und unbegrenzt

Keine Registrierung erforderlich. Testen Sie so viele Domains wie nötig, so oft Sie möchten.

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. 1. Root

    Ermittlung der TLD-Server für den angefragten Namen.

  2. 2. TLD

    Verweis auf die NS der Zone (Delegation).

  3. 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. 1. Gewählter Resolver

    Verwendet das Preset oder die individuelle Konfiguration, um die Anfrage genau wie Ihr Dienst auszuführen.

  2. 2. Protokoll beibehalten

    Respektiert das ausgewählte Transportprotokoll (UDP, TCP oder DoH), um das reale Verhalten nachzustellen.

  3. 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. 1. Multipoint-Resolver

    Aktiviert die Propagations-Presets, um mehrere Akteure weltweit abzufragen.

  2. 2. Automatischer Vergleich

    Gruppiert identische Antworten und hebt Abweichungen oder resolver-spezifische Fehler hervor.

  3. 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.

Was ist ein A-Record?

Ein A-Record (Address Record) ist der grundlegende DNS-Record, der einen Domainnamen einer IPv4-Adresse zuordnet. Wenn Sie eine URL in Ihren Browser eingeben, teilt die A-Record-Antwort mit, welchen Server Sie kontaktieren sollen.

A-Record-Struktur:

FeldBeschreibungBeispiel
NameDomain oder Subdomainwww
TypImmer AA
WertIPv4-Adresse203.0.113.10
TTLCache-Dauer in Sekunden3600

Konkretes Beispiel:

www.captaindns.com.  3600  IN  A  203.0.113.10

Dieser Record zeigt an, dass www.captaindns.com auf die IPv4-Adresse 203.0.113.10 mit einer TTL von einer Stunde zeigt.


Häufige Anwendungsfälle

1. Domain-Apex zeigen

Der Apex (oder Root) einer Domain (captaindns.com ohne www) muss A-Records verwenden, da CNAMEs an dieser Stelle laut RFC nicht erlaubt sind.

captaindns.com.  3600  IN  A  203.0.113.10

2. Lastverteilung (Round-Robin)

Veröffentlichen Sie mehrere A-Records, um Anfragen auf Server zu verteilen:

www.captaindns.com.  300  IN  A  203.0.113.10
www.captaindns.com.  300  IN  A  203.0.113.11
www.captaindns.com.  300  IN  A  203.0.113.12

Der Resolver gibt die vollständige Liste zurück. Der Client wählt typischerweise den ersten aus. Dieser Mechanismus verteilt die Last, erkennt aber keine Ausfälle.

3. Mail-Server

Der von einem MX-Record referenzierte Server muss einen A-Record haben:

mail.captaindns.com.  3600  IN  A  203.0.113.25

Das Reverse-DNS (PTR) dieser IP sollte übereinstimmen, um die E-Mail-Zustellbarkeit zu verbessern.


Best Practices

TTL: Die richtige Balance finden

SituationEmpfohlene TTLGrund
Stabile Konfiguration3600-86400 (1h-24h)Reduziert Last auf autoritativen Servern
Geplante Migration300-600 (5-10 min)Ermöglicht schnelles Rollback
Test oder Debugging60-300 (1-5 min)Änderungen schnell sichtbar

Migrationstipp: Reduzieren Sie die TTL 24-48h vor der Änderung, führen Sie die Änderung durch, erhöhen Sie dann die TTL, sobald alles stabil ist.

Vermeiden

  • CNAME am Apex: Nicht RFC-konform, kann E-Mail brechen
  • A + CNAME am gleichen Namen: Von RFCs verboten
  • Private IP-Adresse: Funktioniert nicht aus dem Internet
  • Alte Records vergessen: Nach Migration aufräumen

Fehlerbehebung häufiger Probleme

Website reagiert nicht

  1. Überprüfen Sie, ob der A-Record existiert
  2. Bestätigen Sie, dass die zurückgegebene IP korrekt ist
  3. Testen Sie die IP-Erreichbarkeit (ping, telnet Port 80/443)
  4. Vergleichen Sie mehrere Resolver, um Propagierungsprobleme zu erkennen

Langsame Propagierung nach Änderung

  1. Überprüfen Sie die TTL des alten Werts (das ist entscheidend)
  2. Der autoritative Server muss den neuen Wert zurückgeben
  3. Warten Sie, bis die TTL auf öffentlichen Resolvern abläuft
  4. Leeren Sie bei Bedarf den lokalen DNS-Cache

Inkonsistente Antworten zwischen Resolvern

  1. Das ist normal während der Propagierung
  2. Überprüfen Sie, ob der autoritative Server den korrekten Wert zurückgibt
  3. Verwenden Sie die iterative Trace, um Unterschiede zu identifizieren
  4. Warten Sie, bis die längste TTL abläuft

Überprüfung per Kommandozeile

Windows (nslookup)

nslookup
set q=a
captaindns.com

Mit einem bestimmten Resolver:

nslookup captaindns.com 1.1.1.1

Linux/Mac (dig)

dig A captaindns.com

Mit einem bestimmten Resolver:

dig A captaindns.com @1.1.1.1

Vollständige iterative Trace:

dig A captaindns.com +trace

Ergänzende Tools

ToolZweck
AAAA-AbfrageIPv6-Adresse der Domain überprüfen
CNAME-AbfrageDNS-Aliase überprüfen
PropagierungstestDutzende Resolver gleichzeitig vergleichen
Vollständiges DNS-AuditGesamte DNS-Konfiguration überprüfen

Nützliche Ressourcen