Zum Hauptinhalt springen

CNAME-Record-Abfrage

Entdecken Sie die Ziele Ihrer DNS-Aliase in Sekunden

Subdomain antwortet nicht? Überprüfen Sie, ob Ihr CNAME-Record auf das richtige Ziel zeigt und ob dieses korrekt zu einer IP-Adresse aufgelöst wird.

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

Sofortige Alias-Auflösung

Entdecken Sie ein CNAME-Ziel in Echtzeit. Folgen Sie der Auflösungskette bis zur finalen IP-Adresse.

Multi-Resolver

Vergleichen Sie Antworten von Google, Cloudflare und Quad9, um Propagierungsprobleme zu erkennen.

Kettenverfolgung

Visualisieren Sie jeden Sprung, wenn ein CNAME auf einen anderen CNAME zeigt. Identifizieren Sie Schleifen oder zu lange Ketten.

TTL und Caching

Überprüfen Sie die Cache-Dauer jedes Records, um Ihre Migrationen sicher zu planen.

Kostenlos und unbegrenzt

Testen Sie so viele Domains wie nötig. Keine Anmeldung erforderlich.

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 CNAME-Record?

Ein CNAME-Record (Canonical Name) erstellt einen Alias von einem Domainnamen zu einem anderen kanonischen Namen. Der Resolver folgt diesem Ziel, um die finale IP-Adresse über A- oder AAAA-Records zu erhalten.

CNAME-Record-Struktur:

FeldBeschreibungBeispiel
NameDie Alias-Subdomainwww oder cdn
TypImmer CNAMECNAME
ZielDer kanonische Namehosting.provider.com.
TTLCache-Dauer in Sekunden3600

Anwendungsbeispiele

www-Subdomain

www auf einen Host oder CDN zeigen:

www.captaindns.com.  3600  IN  CNAME  captaindns.netlify.app.

CDN und statische Assets

Assets an einen CDN-Anbieter delegieren:

cdn.captaindns.com.  3600  IN  CNAME  d123456.cloudfront.net.

SaaS-Dienste

Eine Domain für einen Drittanbieter-Dienst anpassen:

support.captaindns.com.  3600  IN  CNAME  captaindns.zendesk.com.

Wichtige Regeln

Ein CNAME muss allein stehen

RegelErklärung
Keine anderen RecordsEin CNAME kann nicht mit A, AAAA, MX oder TXT am gleichen Namen koexistieren
Verboten am ApexDer Domain-Root hat bereits SOA und NS, daher kein CNAME
MX zeigt nicht auf CNAMEMailserver müssen direkte A/AAAA-Records haben

Best Practices

PraxisWarum
Lange Ketten vermeidenJeder Sprung fügt Latenz hinzu
Kurzer TTL vor MigrationBeschleunigt die Änderungspropagierung
Aliase dokumentierenErleichtert die Fehlersuche

Häufige Probleme

Subdomain antwortet nicht

  1. Überprüfen Sie, ob der CNAME existiert und auf das richtige Ziel zeigt
  2. Prüfen Sie, ob das Ziel gültige A- oder AAAA-Records hat
  3. Testen Sie die Auflösung des Ziels selbst

Konflikt mit anderen Records

Ein CNAME am gleichen Namen wie ein A, MX oder TXT verursacht Probleme. Entfernen Sie die anderen Records oder verwenden Sie stattdessen A/AAAA.

CNAME-Kette zu lang

Wenn ein CNAME auf einen anderen CNAME zeigt, der auf einen anderen zeigt... steigt die Auflösungszeit. Begrenzen Sie auf 2-3 Ebenen.


Befehlszeilenüberprüfung

Linux/Mac

dig CNAME www.captaindns.com

Der gesamten Kette folgen:

dig +trace www.captaindns.com

Windows

nslookup -type=cname www.captaindns.com

CNAME am Apex: Alternativen

Am Domain-Root (Apex) können Sie keinen CNAME verwenden. Alternativen:

LösungBeschreibung
ALIAS/ANAMEProprietäre Funktion einiger DNS-Anbieter (Cloudflare, Route53)
Direkte A/AAAAAuf die IPs des Dienstes zeigen
HTTP-WeiterleitungZu www weiterleiten, das CNAME verwendet

Ergänzende Tools

ToolZweck
A-Record-AbfrageFinale IPv4-Adresse prüfen
AAAA-Record-AbfrageFinale IPv6-Adresse prüfen
DNS-PropagierungsprüfungWeltweite Propagierung prüfen

Nützliche Ressourcen