IPv6 und Dualstack einer Website getrennt prüfen

Das Prüfergebnis in mehrere Aussagen zerlegen

Dualstack bedeutet im Websitebetrieb, dass IPv4 und IPv6 nutzbare Wege zur vorgesehenen Website bilden. Dafür müssen mehrere Bestandteile zusammenpassen. Der Hostingbestand benötigt die richtigen Adressen und die Domainzuordnung. DNS muss die passenden Namen veröffentlichen. Ein Client benötigt einen tatsächlich verfügbaren Netzweg. Der Server muss die Verbindung annehmen und die richtige Website mit einem passenden Zertifikat ausliefern. Diese Aussagen werden getrennt geprüft. Ein grüner Browseraufruf kann den gesamten Zusammenhang nicht belegen, weil der Browser einen verfügbaren Weg auswählen kann.

Die IPv6-Grundspezifikation RFC 8200 beschreibt das Protokoll, während RFC 8305 zu Happy Eyeballs die Auswahl konkurrierender Verbindungswege behandelt. Für Betreiber folgt daraus eine praktische Grenze: Gewöhnliche Nutzeraufrufe können einen Defekt einer Adressfamilie verdecken. Prüfen Sie deshalb IPv4 und IPv6 gezielt. Ein positiver Befund für eine Familie wird nicht als positiver Befund für die andere übernommen. Diese Trennung ist besonders bei neuen Domains, Umzügen und Änderungen an Proxy- oder Firewallregeln hilfreich.

Die Zielidentität aus dem Hostingbestand bestimmen

Beginnen Sie mit der tatsächlichen Domain und dem zugehörigen Abonnement. Lesen Sie die vorgesehenen IPv4- und IPv6-Adressen aus dem Hostinginventar. Ein altes Übergabedokument oder die Adresse eines anderen Kunden ist keine ausreichende Quelle. Prüfen Sie, ob die Domain auf beiden Adressen zugeordnet ist und welche Hostnamen das Zertifikat abdecken soll. Der Hauptname und eine www-Variante sind getrennte Identitäten. Eine gemeinsame IP-Adresse sagt nicht, ob beide Namen korrekt verarbeitet werden. Virtuelle Hosts und Namenszuordnung müssen zum konkreten Aufruf passen.

Notieren Sie diese Angaben als erwarteten Zustand. Dazu gehören Hauptadresse, zusätzliche Namen und die beabsichtigten Weiterleitungen. Die Liste enthält keine geheimen Zugangsdaten. Vor Änderungen wird sie mit dem aktuellen Bestand abgeglichen. In einer Verwaltungsoberfläche mit mehreren Abonnements ist diese Identitätsprüfung wichtig. Eine richtige IPv6-Adresse am falschen Abonnement schafft keinen nutzbaren Domainweg. Wenn der konkrete Host keine geeignete Adresse bereitstellt, bleibt das als tatsächliche Voraussetzung offen. Allgemeine IPv6-Unterstützung einer Plattform ist keine Zusage für dieses Hostingangebot.

DNS autoritativ prüfen

Fragen Sie die autoritativen Nameserver der Domain nach A- und AAAA-Einträgen für die relevanten Namen. Die autoritative Antwort zeigt den veröffentlichten Zonenstand. Ein beliebiger rekursiver Resolver kann noch einen gecachten älteren Zustand liefern. Prüfen Sie bei mehreren autoritativen Servern, ob die Antworten übereinstimmen. Der DNS-Ratgeber behandelt diese Unterscheidung vertieft. Eine Antwort ohne AAAA ist zunächst ein Befund über die Veröffentlichung. Sie widerlegt nicht, dass der Server unter einer intern bekannten IPv6-Adresse erreichbar sein könnte.

Ein möglicher Prüfauftrag lautet sinngemäß: A und AAAA für Hauptname sowie www direkt bei den zuständigen Servern abfragen und den Antwortzeitpunkt dokumentieren. Nutzen Sie dabei die tatsächlich ermittelten Nameserver. Eine verkürzte Ausgabe mit nur den Adressen ist praktisch für den Vergleich; für einen Bericht kann der vollständige Antwortkontext mit TTL und Status hilfreicher sein. Bei CNAME-Ketten wird der Zielname ebenfalls betrachtet. Der ursprüngliche Websitehostname bleibt für TLS und Weiterleitungen relevant, auch wenn DNS auf einen anderen Namen verweist.

Gewöhnliche Namensauflösung ergänzen

Prüfen Sie nach dem autoritativen Stand die Auflösung über einen gewöhnlichen Resolver des vorgesehenen Messpunkts. Damit untersuchen Sie den Weg, den ein normaler Client verwendet. Unterschiede können durch Caches oder durch verschiedene Antworten in einer DNS-Kette entstehen. Halten Sie TTL und Beobachtungszeit fest, statt ein unbestimmtes „DNS dauert noch“ zu schreiben. Ein fehlender Eintrag an einem Messpunkt und ein vorhandener Eintrag bei der Autorität sind unterschiedliche Befunde. Die nächste Aufgabe ist dann die Erklärung dieser Differenz, nicht ein ungeprüfter Umbau der ganzen Zone.

Achten Sie auf Hauptname und Weiterleitungsnamen. Eine funktionierende Apexadresse kann neben einem falsch aufgelösten www-Namen stehen. Wenn Nutzer über beide Namen eintreffen, müssen beide Wege bewusst behandelt werden. Auch ein reiner Weiterleitungsname benötigt eine funktionierende HTTPS-Verbindung, bevor der Browser seine verschlüsselte Weiterleitung verarbeiten kann. Der Zielname allein genügt dafür nicht. DNS, Zertifikat und Redirect werden deshalb als zusammenhängende Strecke geprüft. Dabei bleiben externe Mail- und andere Zoneneinträge außerhalb des Websiteänderungsumfangs, sofern sie nicht ausdrücklich Gegenstand der Aufgabe sind.

Den Messpunkt auf echtes IPv6 prüfen

Ein IPv6-Test benötigt einen Client mit geeigneter IPv6-Konnektivität. Wenn das lokale Netz keinen solchen Weg besitzt, lässt sich damit die Zielerreichbarkeit nicht zuverlässig bewerten. Notieren Sie den Messpunkt und seine Voraussetzung. Ein zweiter geeigneter Messpunkt kann die Prüfung ergänzen. Verwenden Sie keine Darstellung einer IPv4-Adresse in einer IPv6-ähnlichen Schreibweise als Beleg für eine native IPv6-Verbindung. Die tatsächlich verwendete entfernte Adresse und der Netzweg verdienen Aufmerksamkeit. Ein Bericht soll klar zeigen, welche Adressfamilie der Aufruf wirklich verwendete.

Proxys können die Aussage verändern. Wenn Ihr Werkzeug über einen Proxy arbeitet, stammt die Verbindung zum Ziel möglicherweise vom Proxy und nicht vom lokalen System. Das kann für einen bestimmten Prüfzweck nützlich sein, muss aber benannt werden. Für einen direkten Hosttest wird ein geeigneter direkter Weg benötigt. Wenn ein Werkzeug keine Angaben zum verwendeten Netzweg liefert, bleibt die Aussage begrenzt. Eine fehlgeschlagene Prüfung wird mit Originalfehler dokumentiert. „Kein verfügbarer IPv6-Weg am Messpunkt“ ist ein anderer Zustand als „Zielhost über IPv6 nicht erreichbar“.

IPv4 und IPv6 gezielt anfordern

Die offizielle curl-Manpage beschreibt die Optionen -4 und -6. Ein lesender Test kann damit bewusst eine Familie wählen. Verwenden Sie eine bekannte öffentliche URL mit einer begrenzten Gesamtdauer und erfassen Sie Status sowie verwendete Zieladresse. Der Test soll keine verändernden Aktionen auslösen. Ein Abruf der Startseite ist ein erster Nachweis; weitere wichtige Pfade werden danach geprüft. Vergleichen Sie die Ergebnisse beider Familien getrennt, einschließlich Fehlercode des Werkzeugs und HTTP-Antwort.

Für den Test einer bereits bekannten Serveradresse bietet curl auch --resolve. Dabei bleiben Websitehostname und TLS-Name erhalten, während die Adresswahl für den angegebenen Namen und Port festgelegt wird. Ein illustrativer Eintrag lautet www.example.org:443:[2001:db8::10]; beide Werte sind Beispiele und müssen durch den echten geprüften Bestand ersetzt werden. Ein erfolgreicher solcher Aufruf belegt die direkte Verbindung zur festgelegten Adresse. Er belegt keine öffentliche AAAA-Veröffentlichung. Diese Differenz ist bei einer vorbereiteten Installation vor einer DNS-Änderung besonders wichtig.

TLS mit dem echten Namen überprüfen

Die Zertifikatsprüfung muss den verwendeten Websitehostname berücksichtigen. Ein Server kann eine verschlüsselte Verbindung annehmen und trotzdem ein unpassendes Zertifikat liefern. Lassen Sie die normale Namens- und Kettenprüfung aktiv. Ein Aufruf mit deaktivierter Prüfung kann eine Transportspur liefern, ist aber kein positiver Nachweis für korrektes HTTPS. Halten Sie die beiden Situationen getrennt. Für die Abnahme zählt der Aufruf mit regulärer Prüfung. Der TLS-Ratgeber erläutert die Verbindung von Namen, Erneuerung und tatsächlichem Auslieferungszustand.

Prüfen Sie das Zertifikat über beide Adressfamilien. Unterschiedliche Listener oder vorgeschaltete Systeme können verschiedene Zertifikate ausliefern. Eine gültige IPv4-Verbindung lässt daher die IPv6-Strecke offen. Notieren Sie die relevanten Namen und das beobachtete Ende der Gültigkeit, sofern es Teil Ihrer Abnahme ist. Verwenden Sie die Serverzeit und aktuelle Beobachtung für die Interpretation. Ein einmal installierter Zertifikatsname im Panel beweist nicht, dass alle öffentlichen Wege bereits denselben Zustand ausliefern. Die Verbindung liefert den entscheidenden Nachweis.

Redirects mit Pfad und Query prüfen

Ein Redirect soll Nutzer zur beabsichtigten Hauptadresse führen. Prüfen Sie HTTP zu HTTPS sowie zusätzliche Namen zur Hauptdomain. Verwenden Sie eine bekannte Unterseite und einen harmlosen Beispielparameter. Der endgültige Pfad und die Query müssen dem vorgesehenen Verhalten entsprechen. Ein Test ausschließlich der Startseite kann einen Redirectfehler an Unterseiten übersehen. Untersuchen Sie die einzelnen Antworten und den letzten Zielnamen. Wenn eine Weiterleitung die Adressfamilie nicht ausdrücklich festlegt, prüfen Sie den vollständigen Weg trotzdem aus beiden gezielt gewählten Ausgangssituationen.

Ein Redirect kann erfolgreich antworten, während sein HTTPS-Ziel falsch aufgelöst wird. Oder der erste Name liefert über IPv6 ein unpassendes Zertifikat, sodass der Browser die Weiterleitung gar nicht verarbeitet. Deshalb wird der Redirect nicht isoliert als Konfigurationszeile abgenommen. Die tatsächliche Verbindungskette ist der Prüfgegenstand. Auch Schleifen gehören dazu. Wenn mehrere Ebenen gleichzeitig Hauptnamen und HTTPS erzwingen, können Regeln einander widersprechen. Prüfen Sie den Webserver-Requestweg und ändern Sie nur die konkret zuständige Domainregel.

Teilweise Fehler gezielt eingrenzen

Wenn IPv4 funktioniert und IPv6 scheitert, betrachten Sie die IPv6-Zieladresse, Domainzuordnung, Listener und die zuständige Filterung. Prüfen Sie diese Punkte mit der Administration, soweit sie außerhalb Ihres Zugriffs liegen. Ein kompletter Neustart aller Dienste ist keine automatische erste Maßnahme. Wenn beide Familien denselben Anwendungsfehler liefern, liegt eine gemeinsame dynamische Verarbeitung als Spur näher. Das bleibt eine Hypothese, bis Logs oder weitere Tests sie bestätigen. Die 502/503-Analyse hilft beim Übergang vom Netzbefund zur Anwendung.

Bei sporadischen Problemen lohnt ein Vergleich mehrerer geeigneter Messpunkte. Unterschiedliche Netze können unterschiedliche Pfade und Resolver nutzen. Dokumentieren Sie die Beobachtungen mit Zeitpunkt, statt sie zu einem einzigen pauschalen Ergebnis zu mitteln. Ein guter Bericht kann beispielsweise sagen: Beide Familien waren am benannten Messpunkt mit gültiger Namensprüfung erfolgreich; ein zweiter IPv6-Messpunkt bleibt ungeprüft. Das ist eine präzise positive Aussage mit Grenze. Sie behauptet keine weltweite Erreichbarkeit, die aus einer kleinen Stichprobe nicht abgeleitet werden kann.

Eine Prüfkette in den Betrieb aufnehmen

• Adressen und Domainzuordnung aus dem tatsächlichen Hostinginventar erfassen.
• A und AAAA für alle relevanten Namen autoritativ und rekursiv prüfen.
• Einen Messpunkt mit nachgewiesener geeigneter IPv6-Konnektivität verwenden.
• Direkte Adresstests und veröffentlichte DNS-Wege getrennt dokumentieren.
• HTTPS-Namensprüfung über IPv4 und IPv6 aktiv bestehen lassen.
• Redirects einschließlich Unterpfad und harmloser Query tatsächlich aufrufen.

Nehmen Sie die getrennten Familienprüfungen in die Überwachung auf, wenn die Website Dualstack anbieten soll. Wiederholen Sie die Abnahme nach DNS-, Zertifikats- und Hostingänderungen. Bewahren Sie dabei auch nicht erfolgreiche Originalbefunde auf. Eine spätere Korrektur liefert einen neuen Nachweis. So bleibt erkennbar, welche Strecke inzwischen funktioniert und welche Voraussetzung noch fehlt. Die Klarheit dieser einzelnen Aussagen macht den Betriebsbericht belastbarer als ein allgemeines Label „IPv6 fertig“.

Die Auswahl mehrerer Zieladressen dokumentieren

Eine Domain kann mehr als eine Adresse derselben Familie veröffentlichen. Ein einzelner erfolgreicher Aufruf erreicht dann nur den vom Client ausgewählten Weg. Für eine Abnahme des veröffentlichten Bestands prüfen Sie die vorgesehenen Ziele einzeln, soweit der Betriebsaufbau dies erfordert. Halten Sie fest, welche Adresse tatsächlich verbunden wurde. Wenn ein vorgeschalteter Dienst die Ziele dynamisch auswählt, benennen Sie diese Architektur und die Aussagegrenze des Tests. Ein kleines statisches Hostingprojekt und ein verteiltes Auslieferungssystem benötigen dabei unterschiedliche Prüfverfahren.

Verwenden Sie für Vergleiche möglichst dieselbe URL, denselben Methodenumfang und dieselben Namensprüfungen. Eine reine Headerabfrage kann anders verarbeitet werden als ein regulärer Seitenabruf. Bei einem Unterschied werden daher zunächst die Verfahren angeglichen, bevor daraus ein Netzproblem abgeleitet wird. Notieren Sie außerdem, ob der Test Weiterleitungen verfolgt oder lediglich den ersten Antwortschritt untersucht. Der Bericht soll nachvollziehbar machen, ob die erfolgreiche Verbindung den Ausgangshost oder das endgültige Websiteziel belegt. Diese Angaben sind besonders hilfreich, wenn ein zusätzlicher Name nur als Weiterleitungsweg dient und der Fehler bereits vor dessen Zielwechsel auftritt.