DNS und HTTPS: Domain, IPv4, IPv6 und Zertifikat richtig verbinden

Ihre Domain muss zur richtigen Website führen, und der Browser muss deren sichere Verbindung prüfen können. DNS und HTTPS lösen dabei verschiedene Aufgaben. Dieser Leitfaden erklärt den Zusammenhang, zeigt typische Fehler und gibt Ihnen einen nachvollziehbaren Prüfweg für Hauptdomain, www, IPv4 und IPv6.

Die Domainadresse und die Verbindung trennen

Eine Designerin zieht ihr Portfolio auf einen neuen Hostingplatz um. Die Domain scheint zu funktionieren, aber bei manchen Besuchern erscheint eine andere Seite. Auf einem weiteren Gerät meldet der Browser ein Zertifikatsproblem. Das kann mehrere Ursachen haben: unterschiedliche DNS-Antworten, ein alter IPv6-Eintrag oder eine unpassende TLS-Konfiguration. „Die Domain geht“ ist deshalb keine präzise Beschreibung des Zustands.

DNS liefert Informationen darüber, welche Adresse oder welcher Dienst zu einem Namen gehört. HTTPS verwendet TLS, um die Verbindung zum erreichten Server abzusichern und unter anderem den Hostnamen anhand des Zertifikats zu prüfen. Eine richtige IP-Adresse allein liefert noch kein passendes Zertifikat. Ein gültiges Zertifikat allein zeigt umgekehrt nicht, dass jede Domainvariante den beabsichtigten Inhalt erreicht.

Die TLS-Dokumentation von Mozilla erläutert die Transportabsicherung. Für Ihr Vorhaben ist die praktische Folge: Prüfen Sie Name, Verbindung und Inhalt als zusammengehörige, aber getrennte Schritte. Ein Schloss im Browser beantwortet nicht alle organisatorischen oder inhaltlichen Sicherheitsfragen einer Website. Es ist ein Hinweis zur Verbindung, keine allgemeine Anbieterbewertung.

Welche Stelle verwaltet welche Information?

Domainregistrierung, DNS-Verwaltung und Webhosting können bei einem Unternehmen liegen oder auf mehrere Dienste verteilt sein. Finden Sie zuerst heraus, welche Nameserver für Ihre Domain zuständig sind und wo deren Einträge geändert werden. Ein DNS-Editor in einer Hostingverwaltung ist nur dann für den öffentlichen Domainbetrieb maßgeblich, wenn die Domain diese DNS-Server tatsächlich verwendet. Sonst bearbeiten Sie möglicherweise eine wirkungslose lokale Zone.

Dokumentieren Sie die Zuständigkeit und den berechtigten Zugang. Halten Sie auch fest, wer Änderungen freigibt. Eine Agentur sollte nicht unbemerkt die gesamte Zone ersetzen, wenn dort Einträge für E-Mail, Verifikation und weitere Subdomains stehen. Der Umzugsplan hilft, den Umfang einer gewünschten Änderung abzugrenzen. Für eine reine Websiteumschaltung kann die Domainregistrierung beim bisherigen Anbieter bleiben.

A und AAAA beschreiben unterschiedliche Wege

Ein A-Eintrag ordnet einem Namen eine IPv4-Adresse zu. Ein AAAA-Eintrag ordnet eine IPv6-Adresse zu. Cloudflare erläutert diese grundlegenden Typen in seiner DNS-Übersicht. Wenn beide veröffentlicht werden, sollten beide Wege die beabsichtigte Website erreichen. Dass ein Server eine IPv6-Adresse besitzt, bedeutet noch nicht, dass die Domain sie öffentlich veröffentlicht oder dass die Website dort korrekt eingerichtet ist.

Verwenden Sie nur die vom tatsächlichen Hostingbestand bestätigten Zieladressen. Raten Sie keine IPv6-Adresse aus einer IPv4-Adresse und übernehmen Sie keine Adresse einer fremden Website. Die zuständige Betreuung muss die Domain auf dem Zielserver eingerichtet haben. Sonst kann der Server unter der richtigen IP-Adresse eine Standardseite oder einen anderen virtuellen Auftritt ausliefern.

IPv6 muss wirklich als eigene Verbindung geprüft werden. Eine in einer Software angezeigte IPv4-abgebildete Adresse ist kein Nachweis für öffentliches natives IPv6. Wenn Ihr Prüfgerät keine IPv6-Verbindung hat, dokumentieren Sie diese Grenze. Sie können dann die veröffentlichten DNS-Einträge kontrollieren, aber den vollständigen IPv6-Verbindungsweg nicht aus dieser Umgebung bestätigen. Eine präzise offene Angabe ist hilfreicher als ein scheinbarer Erfolg.

Hauptdomain und www einzeln betrachten

Die Hauptdomain und der Name mit www sind zwei unterschiedliche Hostnamen. Sie können auf dieselbe Website führen, müssen aber beide passend eingerichtet sein. Legen Sie eine Hauptadresse fest und leiten Sie die andere Variante dorthin weiter. Prüfen Sie dabei nicht nur die Startseite. Eine Adresse mit Unterseite und Suchparameter sollte entsprechend dem gewünschten Verfahren am passenden Ziel ankommen.

Auch die weiterleitende Variante benötigt bei HTTPS ein passendes Zertifikat. Der Browser baut zuerst die TLS-Verbindung auf und erhält danach die HTTP-Weiterleitung. Wenn das Zertifikat schon am ersten Hostnamen nicht passt, hilft eine später gedachte Weiterleitung nicht. Fragen Sie deshalb ausdrücklich nach der Abdeckung beider Namen und prüfen Sie jede Variante mit normaler Namensprüfung.

Wie Zertifikate zur Domain kommen

Eine Zertifizierungsstelle muss die Kontrolle über die beantragten Domainnamen prüfen. Let's Encrypt beschreibt dafür verschiedene ACME-Prüfverfahren. Bei HTTP-01 wird eine bestimmte Antwort über einen definierten Webpfad geprüft; bei DNS-01 wird ein DNS-basierter Nachweis verwendet. Welches Verfahren Ihre Hostingumgebung nutzt, bestimmt die benötigten Voraussetzungen. Eine allgemeine Anleitung sollte diese Unterschiede nicht übergehen.

Eine fehlgeschlagene Ausstellung kann deshalb an DNS, Erreichbarkeit, Weiterleitungen oder der Bereitstellung des Nachweises liegen. Prüfen Sie die konkrete Meldung und verändern Sie nicht wahllos Einstellungen. Ein Schutz für die Website muss mit dem verwendeten Zertifikatsverfahren abgestimmt sein. Die zuständige Betreuung kann gegebenenfalls einen eng begrenzten Prüfpfad oder ein anderes geeignetes Verfahren verwenden. Der übrige geschützte Entwurf soll dadurch nicht versehentlich öffentlich werden.

Planen Sie auch die Erneuerung. Ein erfolgreich ausgestelltes Zertifikat ist kein einmaliger Dauerabschluss. Die benötigte Validierung muss künftig weiter möglich sein, und Fehlermeldungen müssen eine verantwortliche Person erreichen. Fragen Sie, ob und wo der Hostinganbieter den Erneuerungsstatus anzeigt. Speichern Sie keine privaten Schlüssel in allgemein erreichbaren Verzeichnissen oder in einer öffentlichen Projektdokumentation.

Warum ein alter AAAA-Eintrag auffällt

Ein häufiger Umzugsfehler betrifft nur eine Adressfamilie: Der A-Eintrag zeigt schon auf den neuen Server, AAAA bleibt beim alten. Besucher mit IPv6 können dann die alte Website erreichen, während ein IPv4-Test erfolgreich aussieht. Das ist kein bloßer Browsercacheeffekt. Kontrollieren Sie daher die Einträge beider Familien für jeden betroffenen Hostnamen und prüfen Sie anschließend die Verbindung getrennt.

Let's Encrypt dokumentiert, dass bei der Domainvalidierung mit vorhandenen IPv4- und IPv6-Adressen zunächst IPv6 bevorzugt wird. Ein antwortender, aber falsch eingerichteter IPv6-Server kann die Prüfung scheitern lassen. Daraus folgt für die Praxis: Ein erfolgreicher HTTP-Aufruf über IPv4 allein erklärt nicht jede Zertifikatsstörung. Prüfen Sie die konkrete IPv6-Konfiguration, statt auf eine vermeintlich automatische Ausweichroute zu vertrauen.

TTL und zwischengespeicherte Antworten

Die TTL beschreibt die vorgesehene Gültigkeitsdauer einer gespeicherten DNS-Antwort. Eine Änderung am autoritativen Server kann deshalb sichtbar sein, während ein anderer Resolver noch den vorherigen Wert verwendet. Ein nachträgliches Verkürzen der TTL entfernt nicht rückwirkend eine zuvor mit längerer Gültigkeit gespeicherte Antwort. Planen Sie Änderungen daher rechtzeitig und kontrollieren Sie den veröffentlichten sowie den gewöhnlich aufgelösten Zustand getrennt.

Vermeiden Sie pauschale Versprechen, dass eine Änderung überall nach einer festen kurzen Zeit angekommen sei. Unterschiedliche Einträge, Caches und Fehlerzustände können die Beobachtung beeinflussen. Notieren Sie stattdessen, wann der autoritative Zustand geändert und an welchen Stellen kontrolliert wurde. Wenn ein Gerät weiterhin eine alte Adresse verwendet, vergleichen Sie seine Auflösung mit dem dokumentierten Ziel, bevor Sie den Webserver erneut verändern.

Ein verständlicher Prüfablauf

Beginnen Sie mit der Zielidentität: Welche Domain, welche Hauptadresse und welche bestätigten Serveradressen sollen gelten? Lesen Sie dann die autoritativen A- und AAAA-Antworten für Hauptdomain und www. Prüfen Sie anschließend gewöhnliche DNS-Auflösung und den tatsächlichen HTTPS-Aufruf. Die einzelnen Ergebnisse gehören in eine kleine Tabelle mit Datum. So lässt sich eine Abweichung einem Schritt zuordnen.

Beim HTTPS-Aufruf prüfen Sie Zertifikatsname, erfolgreiche Verbindung, HTTP-Ergebnis und erwarteten Inhalt. Weiterleitungen gehören dazu. Nutzen Sie für eine technische Prüfung Werkzeuge, die Namensprüfung nicht abschalten. Ein Aufruf mit deaktivierter Zertifikatskontrolle kann bei der Fehlersuche helfen, belegt aber keine korrekt sichere öffentliche Verbindung. Beschreiben Sie solche Sonderprüfungen ausdrücklich als Diagnose.

Kontrollieren Sie eine Unterseite und eine Medienadresse. Eine Startseite kann aus einem Cache kommen, während Bilder noch auf eine alte oder ungesicherte Adresse zeigen. Der Browser meldet möglicherweise gemischte Inhalte, wenn eine HTTPS-Seite ungesicherte Ressourcen einbindet. Prüfen Sie die tatsächlichen Ressourcenadressen und beheben Sie sie an der Quelle. Eine erzwungene Browserausnahme ist kein brauchbarer Abschluss für Besucher.

HSTS erst nach stabiler Konfiguration bewerten

HSTS kann Browser anweisen, eine Website nur über HTTPS aufzurufen. Das ist eine bewusst zu planende Ergänzung, besonders wenn Subdomains einbezogen werden. Prüfen Sie zuerst, ob alle betroffenen Namen dauerhaft mit HTTPS funktionieren. Eine weitreichende Einstellung ohne vollständigen Bestand kann spätere Korrekturen erschweren. Lassen Sie sich den genauen Umfang erklären und dokumentieren Sie die Entscheidung.

Für ein kleines Portfolio genügt als erster konkreter Schritt eine sauber funktionierende Hauptadresse mit passendem Zertifikat und getesteten Weiterleitungen. Zusätzliche Maßnahmen sollten die vorhandene Konfiguration sinnvoll ergänzen. Der Leitfaden zur Anbieterprüfung hilft, diese Fähigkeiten am tatsächlichen Tarif zu klären. Technische Unterstützung durch eine Plattform bedeutet noch keine bestätigte Einrichtung auf Ihrer Domain.

Den Bestand nach jeder Änderung aktualisieren

DNS-Dokumentation bleibt nur hilfreich, wenn sie nach dem Umzug korrigiert wird. Notieren Sie zuständige Nameserver, Zieladressen, Hauptdomain und Verfahren der Zertifikatserneuerung. Die Unterlage soll keine Zugangsdaten öffentlich enthalten. Verweisen Sie intern auf deren sicheren Verwaltungsort. Eine übernehmende Betreuung sollte erkennen können, welche Angaben aktuell geprüft sind und welche aus einem älteren Zwischenstand stammen.

Wenn Sie später einen neuen Subdienst anschließen, prüfen Sie dessen DNS-Anforderungen gezielt. Ein neuer TXT-Eintrag für eine Verifikation braucht keinen gleichzeitigen Austausch der MX-Einträge. Behalten Sie bestehende Dienste im Blick und sichern Sie den Zonenstand vor größeren Eingriffen. Die Kombination aus enger Änderung und anschließender Kontrolle verringert unbeabsichtigte Nebenwirkungen.

• Öffentlich zuständige DNS-Verwaltung ist bekannt.
• A und AAAA verwenden bestätigte Zieladressen.
• Hauptdomain und www sind separat geprüft.
• HTTPS verwendet normale Hostnamenprüfung.
• Weiterleitungen erhalten die vorgesehenen Adressbestandteile.
• Zertifikatserneuerung und verantwortliche Person sind dokumentiert.

Diese Kontrolle ergänzt die Auswahl eines Tarifs wie Webhosting Starter. Sie ist keine besondere Eigenschaft nur großer Serverangebote. Eine verständlich dokumentierte Domainkonfiguration hilft kleinen und großen Websites gleichermaßen: Besucher erreichen den richtigen Inhalt, und die Betreuung kann Fehler anhand konkreter Belege untersuchen.

Ein kleines Domainprotokoll führen

Legen Sie für jede gewünschte Domainvariante eine Zeile an. Notieren Sie Hauptdomain und www getrennt, daneben die autoritativ veröffentlichten A- und AAAA-Werte. Eine technisch zuständige Person kann dafür eine Abfrage direkt an die öffentlich zuständigen Nameserver verwenden. Ergänzen Sie eine gewöhnliche Auflösung über den verwendeten Resolver. Wenn beide Ergebnisse voneinander abweichen, halten Sie diese Beobachtung mit Zeitpunkt fest und prüfen Sie die beteiligten Caches.

In derselben Zeile folgen die tatsächlichen HTTPS-Ergebnisse für IPv4 und, soweit ein nativer Zugang vorhanden ist, IPv6. Verwenden Sie die echte Domain mit normaler Zertifikatsprüfung. Kontrollieren Sie den erwarteten Seitentitel und eine konkrete Unterseite. Ein Server kann erfolgreich antworten und dennoch den falschen Auftritt ausliefern. Auch eine Medienadresse wird separat auf den beabsichtigten Inhalt geprüft.

Markieren Sie nicht mögliche Prüfungen ausdrücklich. Wenn das Testgerät keinen IPv6-Zugang besitzt, lautet der Status beispielsweise: AAAA autoritativ bestätigt, native Verbindung noch ungeprüft. Diese präzise Zeile enthält eine klare nächste Aufgabe. Nach deren Durchführung wird das echte Resultat ergänzt; eine frühere offene Prüfung bleibt in der Änderungshistorie nachvollziehbar.