Domain, DNS, Hosting und TLS einfach erklärt.

1. Der Browser zerlegt die Adresse. Aus https://www.beispiel.de/kontakt erkennt er das Protokoll HTTPS, den Hostnamen www.beispiel.de und den Pfad /kontakt.
2. DNS löst den Namen auf. Ein rekursiver Resolver sucht nach einer gespeicherten oder autoritativen Antwort. Dabei kann er über die DNS-Hierarchie zu den Nameservern gelangen, die für die Domain zuständig sind.
3. Der Browser verbindet sich mit dem Ziel. Die DNS-Antwort führt typischerweise zu einer IPv4- oder IPv6-Adresse. Davor können weitere Namen, Lastverteiler oder Schutzdienste liegen.
4. TLS sichert die Verbindung. Browser und Server handeln Parameter aus. Der Server weist seine Identität durch ein Zertifikat nach, beide Seiten erzeugen Sitzungsschlüssel für die verschlüsselte Übertragung.
5. HTTP fordert den Inhalt an. Erst jetzt sendet der Browser die eigentliche Anfrage. Der Webserver oder die Anwendung antwortet mit Statuscode, Headern und Inhalt.

Die Reihenfolge erklärt typische Fehlerbilder. Meldet der Browser, der Name sei nicht auflösbar, sollte zuerst DNS geprüft werden. Erscheint eine Zertifikatswarnung, ist der Server möglicherweise erreichbar, aber Zertifikat, Name oder Gültigkeit passen nicht. Ein HTTP-Fehler 500 entsteht später: Die Verbindung steht, doch die Anwendung kann die Anfrage nicht erfolgreich verarbeiten.

In der Praxis werden einzelne Antworten zwischengespeichert. Der eigene Rechner, der Browser, ein Unternehmensnetz oder ein öffentlicher Resolver kann einen DNS-Datensatz bis zum Ablauf seiner TTL behalten. Deshalb sehen nicht alle Nutzer eine Änderung im selben Moment. Die unterschiedlichen Zeitpunkte entstehen durch die verteilten Zwischenspeicher.

TLS 1.3 ist in RFC 8446 als Protokoll beschrieben, das eine Kommunikation gegen Abhören, Manipulation und Nachrichtenfälschung schützen soll. Für einen normalen Websitebesuch bedeutet das: Dritte auf dem Übertragungsweg sollen den Inhalt nicht einfach lesen oder unbemerkt verändern können. Außerdem erhält der Browser einen kryptografischen Nachweis, dass er mit einem Server für den angeforderten Namen spricht.

Ein Zertifikat enthält keine Bewertung der Texte, Produkte oder Geschäftspraxis einer Website. Auch eine betrügerische Seite kann ein gültiges Zertifikat für ihre eigene Domain besitzen. Ebenso verhindert TLS keine Sicherheitslücke in einem veralteten Redaktionssystem, kein schwaches Passwort und keinen versehentlich öffentlichen Datensatz. Die Aussage lautet nur: Die Verbindung zu diesem Namen ist unter den ausgehandelten Bedingungen geschützt.

04.1Zertifikate müssen erneuert werden

Zertifizierungsstellen prüfen vor der Ausstellung, ob der Antragsteller die Kontrolle über den betreffenden Namen nachweisen kann. Let’s Encrypt beschreibt dafür automatisierte Verfahren und kurzlebige Zertifikate. Beantragung und Erneuerung sollten in einem gepflegten Hosting automatisiert erfolgen. Trotzdem braucht es eine Überwachung, denn fehlerhafte DNS-Einträge, gesperrte Validierungswege oder geänderte Serverkonfigurationen können eine Erneuerung verhindern.

04.2Weiterleitungen schließen Lücken

Ein gültiges HTTPS-Angebot genügt nicht, wenn Besucher noch dauerhaft über unverschlüsseltes HTTP bleiben können. Der Webserver sollte Anfragen kontrolliert auf die kanonische HTTPS-Adresse weiterleiten. Interne Links, Canonical-Angaben, Sitemaps und eingebundene Ressourcen verwenden ebenfalls HTTPS. So entstehen weder gemischte Inhalte noch widersprüchliche Varianten derselben Seite.

Vor einem Hostingwechsel wird die bestehende DNS-Zone exportiert und jeder Eintrag einem Dienst zugeordnet. Parallel entsteht auf dem neuen Hosting eine testbare Kopie der Website. Datenbanken, Formulare, Weiterleitungen, Dateirechte und benötigte Laufzeitversionen werden geprüft, bevor öffentlicher Verkehr umgestellt wird. Erst wenn das Ziel unter einer Testadresse oder lokalen Zuordnung funktioniert, ändern sich die produktiven DNS-Werte.

Der alte Server bleibt während einer angemessenen Übergangszeit erreichbar. Das verhindert zwar nicht jeden Sonderfall, reduziert aber das Risiko, dass Besucher mit einer noch zwischengespeicherten Antwort ins Leere laufen. Bei dynamischen Systemen braucht es zusätzlich einen Plan für Inhalte oder Bestellungen, die während des Übergangs entstehen. Ein bloßes Kopieren am Vortag reicht dort nicht.

06.1Störungen nach Schicht eingrenzen

Die Diagnose beginnt mit einer einfachen Frage: Ist der Name auflösbar, lässt sich eine TLS-Verbindung aufbauen und welcher HTTP-Status folgt? Danach werden DNS-Antwort, Zertifikat, Webserver, Anwendung und abhängige Dienste einzeln betrachtet. So wird nicht vorschnell der Domainanbieter verantwortlich gemacht, wenn tatsächlich nur ein Anwendungspfad fehlerhaft ist.

06.2Änderungen nachvollziehbar halten

Zu jeder produktiven Änderung gehören Zeitpunkt, alter Wert, neuer Wert, verantwortliche Person und Rückweg. Besonders DNS-Oberflächen verleiten zu spontanen Eingriffen, deren frühere Werte später fehlen. Eine kleine Änderungsnotiz spart im Fehlerfall oft mehr Zeit als jedes zusätzliche Werkzeug.

Ruhrstack betrachtet diese Übergänge im Rahmen von Hosting und technischer Betreuung gemeinsam mit Website, DNS und sicherer Auslieferung. Wer zunächst die Grenzen eines standardisierten Angebots prüfen möchte, findet im Beitrag zu Website-Baukästen eine Entscheidungshilfe.

Sind Domain und Hosting dasselbe?

Nein. Die Domain ist der registrierte Name. Das Hosting stellt die technische Umgebung bereit, die Website oder andere Dienste ausliefert. DNS verbindet Namen und Ziel. Eine Domain kann ohne Website registriert sein, und ein Server kann Inhalte bereitstellen, die noch nicht über die gewünschte Domain erreichbar sind.

Müssen Domain, DNS und Hosting beim selben Anbieter liegen?

Nein. Eine Bündelung kann Verwaltung und Support vereinfachen, technisch sind getrennte Anbieter möglich. Wichtig sind klare Zuständigkeiten, persönliche Administrationszugänge und eine Dokumentation der Abhängigkeiten. Bei einer Trennung muss eindeutig sein, wo Nameserver und einzelne DNS-Einträge tatsächlich gepflegt werden.

Wie lange dauert eine DNS-Änderung?

Das hängt vor allem vom bisherigen Datensatz, seiner TTL und den beteiligten Zwischenspeichern ab. Viele Änderungen werden schnell sichtbar, andere Nutzer erhalten bis zum Ablauf gespeicherter Antworten noch den alten Wert. Eine pauschale weltweite Umschaltzeit ist deshalb ungenau.

Macht ein TLS-Zertifikat eine Website sicher?

Es schützt die Verbindung zum passenden Server vor typischen Angriffen auf dem Übertragungsweg. Es beseitigt keine Schwachstellen in Anwendung, Zugangsschutz oder Serverkonfiguration und bestätigt nicht die Seriosität des Inhalts. TLS ist eine notwendige Sicherheitsschicht, aber nicht die gesamte Website-Sicherheit.