Propagation & Diagnose

Vergleichen Sie öffentliche Resolver und analysieren Sie die gelieferten Antworten.

HTTPS-Eintrag Suche

Im iterativen Tracemodus wird der Resolver ignoriert.
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. 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.

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

Ein HTTPS-Record beschreibt, wie eine Website erreicht werden kann. Es ist die spezialisierte Variante des SVCB für das Web. Er kann ein Ziel angeben und Parameter wie Protokolle, Port und ECH-Daten ankündigen. Browser verwenden ihn zur Auswahl der besten Verbindung.
Ein HTTPS-Record enthält einen Namen, einen Typ, eine Priorität, ein Ziel, Parameter und eine TTL. Die TTL gibt an, wie lange die Antwort im lokalen Resolver zwischengespeichert bleibt.

Beispiel für DNS-Eintrag vom Typ HTTPS

NameTypPrioritätZielParameterTTL in Sekunden
test.captaindns.comHTTPS1cdn.beispiel.net.alpn=h3,h2 port=443 ipv4hint=203.0.113.103600

In diesem Beispiel zielt der Name auf die Website ab. Das Ziel ist ein anderer Hostname. Die Parameter geben die Protokolle, den Port und eine Fallback-Adresse an. Eine TTL von 3600 entspricht einer Stunde.

Beispiel im Alias-Modus

Die Priorität null aktiviert den Alias-Modus. Der Name verhält sich dann wie ein Alias zum Ziel.

NameTypPrioritätZielParameterTTL in Sekunden
captaindns.comHTTPS0cdn.beispiel.net.(keine Parameter)3600

Dieser Modus dient dazu, auf eine andere Zone zu zielen, während man am Apex konform bleibt, wo ein CNAME nicht erwünscht ist.

Häufige Parameter

ParameternameRolle
alpnKündigt Protokolle wie h2 oder h3 an
portGibt den Port des Dienstes an
ipv4hintLiefert indikative v4-Adressen
ipv6hintLiefert indikative v6-Adressen
echVeröffentlicht ECH-Daten zur Verschlüsselung des ClientHello

Diese Parameter leiten den Client. Sie ersetzen nicht die A- und AAAA-Einträge, die weiterhin die Adressquelle bleiben.

TTL einfach erklärt

Eine kurze TTL macht eine Änderung sichtbarer. Praktisch während eines Übergangs.
Eine mittlere oder lange TTL reduziert die Anfragen an die autoritativen Server. Geeignet für einen stabilen Dienst.
TTL einige Stunden vor einer Umstellung reduzieren, dann nach Validierung wieder erhöhen.

Gut zu wissen
Clients, die HTTPS-Records nicht verstehen, verwenden A und AAAA. Das Veröffentlichen von HTTPS beseitigt nicht die Notwendigkeit, diese Adressen beizubehalten.

Wo ein HTTPS-Record verwendet wird

Auf www zur Ankündigung von h3 oder einem Verbreitungsziel. Am Apex im Alias-Modus, um auf einen Namen zu zielen und dabei konform zu bleiben. Auf einer Anwendungs-Subdomain, wenn der Webdienst dort residiert.
HTTPS kann mit A und AAAA koexistieren. Browser wählen IPv6, wenn möglich, und fallen auf IPv4 zurück, wenn nötig.

Zu vermeiden
HTTPS ohne A oder AAAA am Ziel zu veröffentlichen.
Mehrere Ziele ohne Grund zu verketten.
Parameter zu deklarieren, die nicht dem tatsächlichen Dienst entsprechen.

Online überprüfen

Ein Online-DNS-Lookup ermöglicht die Eingabe eines Namens. Man sieht die Priorität, das Ziel, die Parameter und die TTL, wie sie vom Internet aus wahrgenommen werden. Das ist eine nützliche erste Kontrolle. Anschließend einen lokalen Test von der eigenen Maschine durchführen.

Unter Windows überprüfen

Windows stellt nslookup zur Verfügung. Man kann es im interaktiven Modus verwenden.

Lokaler Resolver
nslookup set q=https beispiel.com
Spezifischer Resolver
nslookup
set q=https
server 1.1.1.1
beispiel.com

Der erste Teil fragt entsprechend der Netzwerkkonfiguration der Maschine ab. Der zweite erzwingt die Verwendung eines Drittanbieters-Resolvers, hier den von Cloudflare.

Unter Linux und Mac überprüfen

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

Lokaler Resolver
dig HTTPS beispiel.com
Spezifischer Resolver
dig HTTPS beispiel.com @1.1.1.1

Schnelles Lesen der Antworten

Eine Priorität von null zeigt einen Alias an. Ein Wert größer als null beschreibt einen Dienst mit Parametern.
Das Vorhandensein von alpn leitet die Wahl zwischen h3 oder h2. Die Felder ipv4hint und ipv6hint sind nur Hinweise.
Eine hohe verbleibende TTL kann eine Verzögerung nach einer Änderung erklären.

Einfache Einrichtung

  1. Das Ziel wählen. Alias am Apex oder Veröffentlichung von Parametern auf www.
  2. Die TTL vor der Einrichtung auf 300 oder sogar 60 Sekunden reduzieren.
  3. Den HTTPS-Eintrag mit der gewählten Priorität, dem Ziel und den Parametern veröffentlichen.
  4. Mit nslookup oder dem dig-Befehl von mehreren Netzwerken aus überprüfen.
  5. Die TTL erhöhen, wenn alles stabil ist.

Praktischer Tipp
Die Priorität, das Ziel und jeden Parameter dokumentieren. Datum und Grund der Änderung festhalten. Diese Spur erleichtert die Kontrollen.

Häufige Fälle

Adoption von HTTP Version drei beschleunigen

alpn h3 auf www veröffentlichen. h2 für Kompatibilität behalten.

Website hinter einem Anbieter

Alias-Modus verwenden, um auf den vom Dienst bereitgestellten Namen zu zielen. A und AAAA am Ziel behalten.

ECH aktivieren

ech veröffentlichen, wenn die Plattform es anbietet. Unterstützung browser-seitig überprüfen.

Schnelle Fehlerbehebung

  1. Wenn die Website nicht von h3 profitiert, das Vorhandensein von alpn und die server-seitige Unterstützung überprüfen.
  2. Wenn Clients HTTPS ignorieren, A und AAAA am Ziel überprüfen.
  3. Wenn eine Schleife auftritt, überprüfen, dass das Ziel nicht auf den ursprünglichen Namen zurückverweist.
  4. Wenn die Antwort trotz Aktualisierung veraltet bleibt, das Ablaufen der TTL abwarten und wenn möglich den Cache des lokalen Resolvers leeren.

Zusammengefasst kündigt ein HTTPS-Eintrag die optimale Weise an, eine Website zu erreichen. Er kann als kontrollierter Alias dienen und nützliche Parameter wie alpn, port und ech veröffentlichen. Eine gut eingestellte TTL erleichtert Übergänge. Die Überprüfung erfolgt über ein Online-Tool, dann über nslookup und dig.
Mit diesen Anhaltspunkten bleibt die Verwaltung klar. Änderungen laufen stressfrei ab. Benutzer greifen ohne Zwischenfälle auf die Website zu.