Domains, DNS und Webhosting

Vom Namen zum Webinhalt – fünf getrennte Ebenen

Beim Aufruf einer Website wirken mehrere Systeme hintereinander. Zuerst existiert ein registrierter Domainname. DNS ordnet diesem Namen Informationen zu. Ein Resolver ermittelt daraus die nötige Zieladresse oder weitere Serviceparameter. Danach baut der Client eine Transport- und gegebenenfalls TLS-Verbindung auf. Erst anschließend spricht der Browser HTTP mit dem Webserver und fordert eine konkrete Ressource an.

Diese Ebenen werden im Alltag häufig vermischt. Ein DNS-Fehler ist aber kein Webserverfehler, ein abgelaufenes Zertifikat kein Registrierungsproblem und ein HTTP-404 kein fehlender DNS-Eintrag. Saubere Diagnose beginnt deshalb immer mit der Frage, auf welcher Ebene die Kette erstmals vom erwarteten Zustand abweicht.

• Domain: registrierter Name im hierarchischen Namensraum.
• DNS: verteilte Datenbank, die Namen mit Resource Records verknüpft.
• Resolver: Komponente, die DNS-Antworten ermittelt und zwischenspeichert.
• Transport/TLS: Netzwerkverbindung und gegebenenfalls kryptografisch geschützter Kanal.
• HTTP/Webserver: Protokoll und Anwendungsebene, über die konkrete Webressourcen ausgeliefert werden.

Domainname, Hostname und URL sind nicht dasselbe

Ein Domainname ist ein Name im DNS-Baum. Ein Hostname ist ein Domainname, der in einem bestimmten Kontext einen Rechner oder Dienst bezeichnet und den dafür geltenden Syntaxregeln entsprechen muss. Eine URL enthält dagegen ein Schema, einen Hostnamen und gegebenenfalls Port, Pfad, Query und Fragment. In https://example.org/archiv/a.htm ist example.org nur der Hostanteil.

Diese Trennung ist technisch wichtig. DNS kennt den Pfad /archiv/a.htm nicht. Er wird erst nach erfolgreicher Namensauflösung in der HTTP-Anfrage an den Webserver übertragen. Deshalb kann DNS nicht direkt einzelne HTML-Dateien auf unterschiedliche Server verteilen, solange nicht unterschiedliche Hostnamen oder andere vorgelagerte Mechanismen verwendet werden.

Der DNS-Namensraum als Baum

DNS organisiert Namen hierarchisch. Ganz oben steht die Root-Zone. Darunter folgen Top-Level-Domains wie .de, .com oder .org. Unter einer TLD werden weitere Namen delegiert. Ein vollständiger Domainname besteht aus Labels, die durch Punkte getrennt werden; gelesen wird die Hierarchie logisch von rechts nach links.

Die Schreibweise mit abschließendem Punkt kennzeichnet einen Fully Qualified Domain Name eindeutig relativ zur DNS-Wurzel, etwa example.org. In Benutzeroberflächen wird dieser letzte Root-Punkt meist weggelassen. In Zonendateien kann die Unterscheidung zwischen absolutem und relativem Namen dagegen entscheidend sein.

Labels, Länge und Groß-/Kleinschreibung

DNS-Namen bestehen aus Labels. Das klassische DNS-Protokoll begrenzt ein einzelnes Label auf 63 Oktette und den vollständigen binär kodierten Domainnamen auf 255 Oktette einschließlich Längenangaben und Root-Abschluss. Praktische Anwendungssyntax kann zusätzliche Grenzen setzen.

DNS-Namen werden bei normaler Namensauflösung ohne Unterscheidung der Groß-/Kleinschreibung verglichen. Die Schreibweise kann in Darstellung erhalten bleiben, semantisch sind WWW.Example.org und www.example.org für die DNS-Namensauflösung jedoch derselbe Name. Pfade einer Website können dagegen je nach Server und Dateisystem sehr wohl groß-/kleinschreibungssensitiv sein.

Internationalisierte Domainnamen und Punycode

Das klassische DNS transportiert keine beliebigen Unicode-Zeichen direkt in Labels. Internationalisierte Domainnamen werden deshalb über IDNA in eine ASCII-kompatible Form überführt. Sichtbare Unicode-Namen und die technisch verwendete A-Label-Darstellung müssen dabei auseinandergehalten werden.

Die Darstellung internationalisierter Namen ist sicherheitsrelevant, weil ähnlich aussehende Zeichen aus unterschiedlichen Schriftsystemen verwechselt werden können. Browser und Registries setzen deshalb zusätzliche Regeln und Darstellungsstrategien ein. Für Konfiguration, Zertifikate und Diagnose sollte stets klar sein, welche kanonische ASCII-Form tatsächlich verwendet wird.

Registry, Registrar, Registrant und DNS-Provider

Bei einer Domainregistrierung wirken unterschiedliche Rollen zusammen. Die Registry verwaltet die Registrierungsdaten einer Top-Level-Domain. Ein Registrar vermittelt Registrierungen für Domaininhaber. Der Registrant ist der registrierende beziehungsweise nutzungsberechtigte Inhaber im jeweiligen Vertragsmodell. DNS-Hosting kann beim Registrar liegen, muss es aber nicht.

Auch Webhosting ist eine getrennte Rolle. Eine Domain kann bei Anbieter A registriert, bei Anbieter B per DNS gehostet und auf Webservern von Anbieter C ausgeliefert werden. Diese Trennung erhöht Flexibilität, macht Dokumentation und Zugangssicherung aber wichtiger.

RDAP statt klassischem WHOIS-Denken

Registrierungsdaten wurden historisch häufig über WHOIS abgefragt. Der modernere Registration Data Access Protocol, RDAP, liefert strukturierte Registrierungsdaten und unterstützt standardisierte Antwortformate, Internationalisierung, sicheren Zugriff und differenzierte Sichtbarkeit besser als das alte textorientierte WHOIS-Modell.

ICANN verwendet RDAP für seine Registrierungsdatenabfragen und beschreibt das Protokoll als Ersatz für den klassischen WHOIS-Port-43-Zugriff. Welche personenbezogenen oder administrativen Daten öffentlich sichtbar sind, hängt dabei von Registry, Registrar, Rechtsrahmen und Zugriffsberechtigung ab.

Registrierung, Verlängerung und Ablauf

Eine Domain ist keine einmalig gekaufte Sache im Sinn dauerhaften Eigentums. Die Nutzungsberechtigung hängt von Registrierung, Laufzeit, Verlängerung und den Regeln der jeweiligen TLD ab. Wird eine Domain nicht rechtzeitig verlängert, können je nach Registry unterschiedliche Status- und Wiederherstellungsphasen folgen.

Für langfristige Webarchive ist die Domainverlängerung deshalb ein betrieblicher Kernprozess. Automatische Verlängerung, aktuelle Zahlungsdaten, erreichbare Kontaktdaten und gesicherter Registrarzugang sind wichtiger als viele sichtbare Webfunktionen. Eine perfekt erhaltene Website verliert ihre öffentliche Adresse, wenn die Domainverwaltung ausfällt.

Registrarzugang, Transfer-Schutz und Kontosicherheit

Die Domainverwaltung ist ein besonders kritisches Konto, weil ein Angreifer durch Änderungen an Nameservern oder Registrierungsdaten die gesamte Website und E-Mail-Infrastruktur umleiten kann. Starke Authentisierung, getrennte Wiederherstellungswege und sorgfältiger Umgang mit Transfer- und Änderungsfunktionen sind deshalb wesentlich.

Sicherheitsmechanismen eines Registrars ersetzen keine eigene Dokumentation. Es sollte nachvollziehbar sein, welcher Registrar zuständig ist, welche Nameserver autoritativ sind und welche Kontakte für Wiederherstellung existieren. Geheimnisse gehören dabei nicht in öffentlich zugängliche Projektdateien.

Delegation – Zuständigkeit im DNS-Baum weiterreichen

DNS skaliert, weil Zuständigkeit delegiert wird. Eine übergeordnete Zone veröffentlicht NS-Einträge, die auf die autoritativen Nameserver einer untergeordneten Zone verweisen. Der Resolver folgt dieser Kette von Root über TLD bis zur gesuchten Zone.

Delegation ist keine HTTP-Weiterleitung. Sie bestimmt, welche Nameserver für DNS-Daten zuständig sind. Ein Wechsel der Webserveradresse kann innerhalb derselben Delegation erfolgen, ohne Registrar oder TLD zu ändern. Ein Nameserverwechsel verändert dagegen die DNS-Zuständigkeit selbst.

Zone und Domain – ähnlich klingend, aber nicht identisch

Eine Domain bezeichnet einen Teilbaum des DNS-Namensraums. Eine Zone ist der administrativ zusammenhängende Teil dieses Baums, für den ein Satz autoritativer Nameserver Daten bereitstellt. Unterhalb einer Zone können weitere Unterzonen delegiert werden.

Dadurch kann example.org als Domain viele Unterdomains enthalten, während sub.example.org als eigene Zone an andere Nameserver delegiert ist. Die Zonengrenze wird durch Delegation definiert, nicht durch die bloße Zahl von Punkten im Namen.

Autoritative Nameserver – Quelle für eine Zone

Ein autoritativer Nameserver beantwortet Anfragen anhand der Zone, für die er zuständig ist. Er muss die Daten nicht erst rekursiv bei anderen Servern ermitteln. Antworten aus eigener Autorität unterscheiden sich damit grundsätzlich von gecachten Antworten eines rekursiven Resolvers.

Für zuverlässigen Betrieb wird eine Zone typischerweise über mehrere autoritative Server bereitgestellt. Diese sollten nicht lediglich unterschiedliche Namen für denselben einzelnen Ausfallpunkt darstellen. Moderne DNS-Provider verteilen autoritative Dienste häufig geographisch und über Anycast.

Rekursive Resolver – Stellvertreter des Clients

Ein Endgerät fragt normalerweise nicht selbst Root-, TLD- und autoritative Nameserver nacheinander ab. Stattdessen übergibt ein Stub Resolver die Frage an einen rekursiven Resolver. Dieser ermittelt die Antwort, nutzt seinen Cache und liefert das Ergebnis zurück.

Rekursive Resolver können beim Internetzugangsanbieter, im lokalen Netz, im Betriebssystem, in einer Organisation oder bei einem öffentlichen Resolverdienst liegen. Die Wahl beeinflusst Datenschutz, Fehlerverhalten, Filterung und Cachecharakteristik.

Iterative Auflösung – Schritt für Schritt zur zuständigen Zone

Bei iterativer Auflösung erhält der Resolver nicht immer sofort die endgültige Antwort. Ein Root-Server verweist auf die zuständigen TLD-Server; diese verweisen auf die autoritativen Server der Zieldomain. Erst dort liegt typischerweise der gesuchte A-, AAAA- oder andere Resource Record.

Dieses Verfahren erklärt, warum DNS ein verteiltes System ist. Kein einzelner Server muss eine vollständige globale Datenbank halten. Caches reduzieren zusätzlich die Zahl nötiger Schritte und entlasten die Hierarchie.

Beispielhaft:
Client → rekursiver Resolver
Resolver → Root:      www.example.org?
Root → Resolver:      zuständig für .org
Resolver → .org:      www.example.org?
.org → Resolver:      autoritativ für example.org
Resolver → autoritativ: www.example.org A/AAAA?
autoritativ → Resolver: Antwort
Resolver → Client:    gecachtes Ergebnis

DNS-Caching – Geschwindigkeit gegen Aktualität

Resolver speichern Antworten für eine begrenzte Zeit. Dadurch müssen wiederholte Fragen nicht erneut durch die gesamte Hierarchie aufgelöst werden. Caching reduziert Latenz und Last, bedeutet aber zugleich, dass Änderungen nicht überall sofort sichtbar werden.

Die Lebensdauer wird wesentlich durch TTL-Werte beeinflusst. Ein niedriger TTL-Wert kann geplante Migrationen beschleunigen, erhöht aber die Abfragehäufigkeit. Ein hoher Wert reduziert Last und stabilisiert Caches, verlängert jedoch die Zeit, in der alte Daten weiterverwendet werden können.

TTL – kein weltweiter Countdown-Schalter

Die Time to Live eines Resource Records gibt an, wie lange eine Antwort von einem Cache weiterverwendet werden darf. Jeder Resolver startet seinen eigenen Countdown zu dem Zeitpunkt, an dem er die Information erhält. Es gibt deshalb keinen globalen Zeitpunkt, zu dem eine DNS-Änderung plötzlich überall gleichzeitig umspringt.

Vor Migrationen kann eine rechtzeitig vorher reduzierte TTL sinnvoll sein. Wird die TTL erst gleichzeitig mit der Zieladresse geändert, können Resolver die vorherige hohe TTL bereits gecacht haben. Nach erfolgreicher Umstellung kann der Wert wieder auf einen betrieblich sinnvollen Zustand erhöht werden.

Negative Antworten werden ebenfalls gecacht

DNS kann nicht nur positive Antworten zwischenspeichern. Auch die Information, dass ein Name oder bestimmter Datentyp nicht existiert, kann gecacht werden. Das erklärt Situationen, in denen ein gerade neu angelegter Hostname bei manchen Resolvern noch eine Zeit lang als nicht vorhanden erscheint.

Bei Fehlersuche sollte deshalb zwischen NXDOMAIN, NODATA und anderen Fehlerzuständen unterschieden werden. Ein fehlender A-Record bei vorhandener Domain ist etwas anderes als ein vollständig nicht existierender Name.

A-Record – Name auf IPv4-Adresse

Der A-Record ordnet einem DNS-Namen eine IPv4-Adresse zu. Ein Hostname kann mehrere A-Records besitzen; Resolver und Clients können daraus unterschiedliche Ziele auswählen. DNS liefert dabei zunächst Adressen, nicht automatisch eine Garantie für Erreichbarkeit oder funktionierenden Webdienst.

Ein A-Record ist außerdem nicht „der Domain-Eintrag“. Dieselbe Zone kann parallel NS, SOA, MX, TXT, CAA und viele weitere Datentypen enthalten. Eine Website kann sogar ohne A-Record erreichbar sein, wenn ausschließlich IPv6 mit AAAA genutzt wird und die Clientumgebung dies unterstützt.

AAAA-Record – IPv6 im DNS

Der AAAA-Record ordnet einem Namen eine IPv6-Adresse zu. Dual-Stack-Websites veröffentlichen häufig sowohl A als auch AAAA. Der Client entscheidet anschließend anhand seiner Netzwerkkonnektivität und Implementierungsstrategie, welche Adresse verwendet wird.

Ein falsch konfigurierter AAAA-Record kann problematischer sein als gar kein IPv6-Eintrag: Clients können eine IPv6-Verbindung versuchen, obwohl der Serverpfad nicht korrekt funktioniert. IPv6 sollte deshalb ebenso real getestet werden wie IPv4.

NS-Records – autoritative Zuständigkeit ausdrücken

NS-Records benennen die Nameserver einer Zone. Bei einer Delegation erscheinen entsprechende Informationen an der übergeordneten Zonengrenze und in der delegierten Zone selbst. Inkonsistenzen zwischen Parent und Child erschweren Diagnose und können zu unerwartetem Verhalten führen.

Nameservernamen benötigen wiederum Adressen. Liegt der Nameservername innerhalb der delegierten Domain selbst, kann die übergeordnete Zone zusätzliche Adressinformationen als Glue bereitstellen, damit die Auflösung nicht in einer zirkulären Abhängigkeit endet.

Glue Records – die Delegationsschleife auflösen

Angenommen, example.org wird an ns1.example.org delegiert. Um ns1.example.org zu finden, wäre eigentlich bereits eine Auflösung innerhalb example.org nötig – genau jener Zone, deren Server zunächst gefunden werden sollen. Glue-Adressen in der Parent-Zone lösen dieses Henne-Ei-Problem.

Glue ist Hilfsinformation der Delegation und nicht identisch mit dem autoritativen A- oder AAAA-RRset im Kind. Beide sollten konsistent gepflegt werden.

SOA – Verwaltungsdaten einer Zone

Der Start of Authority Record gehört zu jeder normalen DNS-Zone. Er enthält unter anderem den primären administrativen Servernamen, ein Kontaktfeld in DNS-Schreibweise, eine Seriennummer und Zeitparameter für klassische sekundäre Zonensynchronisation.

Die Seriennummer dient dazu, Änderungen zwischen autoritativen Servern zu erkennen. Bei modernen API-basierten DNS-Plattformen sind interne Mechanismen oft stärker abstrahiert, der SOA-Record bleibt trotzdem Teil des Protokollmodells.

CNAME – Alias auf einen anderen Namen

Ein CNAME erklärt einen DNS-Namen zum Alias eines anderen kanonischen Namens. Der Resolver folgt dieser Kette und ermittelt anschließend die Records des Zielnamens. CNAME ist nützlich, wenn mehrere Namen logisch an einen zentral verwalteten Zielnamen gekoppelt werden sollen.

Ein Name mit CNAME kann nach den klassischen DNS-Regeln nicht gleichzeitig normale andere Datensätze wie MX oder eigene A-Records tragen. Besonders am Zonenapex kollidiert das mit den dort erforderlichen NS- und SOA-Daten. Proprietäre ALIAS- oder ANAME-Funktionen mancher Anbieter sind deshalb Providermechanismen und keine normalen CNAME-Records.

Zonenapex – warum die nackte Domain besonders ist

Der Apex einer Zone ist der Zonenname selbst, etwa example.org. Dort müssen SOA und NS existieren. Ein gewöhnlicher CNAME würde mit diesen Daten kollidieren. Deshalb lässt sich der Apex nicht einfach nach demselben CNAME-Muster wie www.example.org behandeln.

Moderne Service-Binding-Mechanismen und anbieterinterne Flattening-Lösungen adressieren bestimmte Einsatzfälle, dürfen aber nicht gedanklich mit einem standardmäßigen CNAME am Apex gleichgesetzt werden.

MX – Mailzustellung unabhängig vom Webserver

MX-Records benennen Mailserver und Prioritäten für eine Domain. Die Website kann auf einem völlig anderen Anbieter liegen als E-Mail. Ein Webhostingumzug sollte deshalb MX-Einträge nicht beiläufig verändern, wenn die Mailinfrastruktur unverändert bleiben soll.

Diese Trennung ist einer der häufigsten Gründe, DNS-Zonen vor einem Umzug vollständig zu inventarisieren. Eine Zone besteht nicht nur aus den Records, die für die Website sichtbar relevant sind. E-Mail-DNS wird ausführlich auf email-und-mailprotokolle.htm behandelt.

TXT – allgemeiner Textcontainer mit vielen Protokollrollen

TXT-Records tragen frei definierte Zeichenfolgen und werden von zahlreichen Protokollen genutzt. Beispiele sind Domainverifikation, E-Mail-Richtlinien und Dienstkonfigurationen. Dass verschiedene Systeme denselben Recordtyp verwenden, bedeutet nicht, dass sämtliche TXT-Werte inhaltlich zusammengehören.

Ein häufiger Fehler ist, mehrere unabhängige TXT-Inhalte versehentlich zu einem Wert zusammenzuführen oder beim DNS-Umzug nicht vollständig zu übernehmen. Jede Anwendung interpretiert nur die für sie definierten Präfixe und Strukturen.

SRV – Dienst, Protokoll, Ziel und Port

SRV-Records können Dienste mit Priorität, Gewicht, Port und Zielhost beschreiben. Damit muss ein Client nicht zwingend davon ausgehen, dass ein Dienst auf einem festen Standardport derselben Domain läuft.

SRV funktioniert nur für Anwendungen, die den Recordtyp ausdrücklich unterstützen. Für normale Webbrowser ist SRV nicht der allgemeine Mechanismus zur Auswahl eines HTTPS-Webservers. Für HTTP existieren heute stattdessen eigene SVCB-/HTTPS-Mechanismen.

PTR und Reverse DNS

Reverse DNS ordnet IP-Adressen über spezielle Reverse-Zonen Namen zu. Für IPv4 wird in-addr.arpa verwendet, für IPv6 ip6.arpa. Der dafür verwendete PTR-Record ist nicht einfach die umgekehrte Form eines A-Records, sondern Teil eines eigenen delegierten Namensraums.

PTR-Daten werden typischerweise vom Inhaber beziehungsweise Provider des IP-Adressbereichs kontrolliert, nicht automatisch vom Betreiber der vorwärts auflösenden Domain. Besonders Mailserver verwenden konsistentes Reverse DNS als einen von mehreren Vertrauenshinweisen.

CAA – Zertifikatsausstellung begrenzen

Certification Authority Authorization erlaubt einem Domaininhaber, über DNS festzulegen, welche Zertifizierungsstellen für die Domain Zertifikate ausstellen dürfen beziehungsweise welche zusätzlichen Parameter gelten. Der Record ist damit eine zusätzliche Kontrollschicht im Zertifikatsprozess.

CAA ersetzt weder TLS noch die Prüfung eines ausgestellten Zertifikats. Es wirkt vor der Ausstellung als Autorisierungsinformation für Zertifizierungsstellen. Eine falsche CAA-Konfiguration kann legitime Zertifikatsausstellung blockieren und sollte deshalb dokumentiert werden.

TLSA und DANE – Zertifikatsbezug über DNSSEC

TLSA-Records können im Rahmen von DANE Informationen zur TLS-Zertifikats- beziehungsweise Schlüsselerwartung über DNS veröffentlichen. Damit diese Aussage vertrauenswürdig ist, ist DNSSEC eine zentrale Grundlage des Modells.

DANE ist technisch besonders im Mailbereich relevant, aber nicht identisch mit dem normalen Web-PKI-Modell der Browser. Die Mechanismen sollten deshalb nicht ungeprüft vermischt werden.

SVCB und HTTPS – moderne Service-Binding-Records

SVCB und HTTPS-Records liefern einem Client vor dem Verbindungsaufbau zusätzliche Informationen zu einem Dienst. Dazu können alternative Endpunkte und Parameter für Transportprotokolle gehören. Der HTTPS-Record ist speziell auf HTTP-Dienste ausgerichtet.

Diese Records können Verbindungsaufbau effizienter machen und neue Protokollinformationen transportieren. Sie ersetzen jedoch nicht die grundlegende DNS-Hierarchie. Auch ein HTTPS-Record muss über normale Resolver- und Autoritätsmechanismen gefunden werden.

HTTPS AliasMode und der Apex-Sonderfall

Der HTTPS-Record kann in einem AliasMode verwendet werden und damit für den HTTP-Dienst Eigenschaften bieten, die klassische CNAME-Konstruktionen am Apex nicht erlauben. Das ist ein standardisierter Service-Binding-Mechanismus, aber kein allgemeines Umschreiben sämtlicher DNS-Daten der Zone.

Beim Einsatz sollte geprüft werden, welche Clients und Hostingplattformen die vorgesehenen Parameter tatsächlich unterstützen. Fallbackpfade über A und AAAA bleiben für breite Erreichbarkeit wichtig.

Wildcard-DNS – passend für fehlende Namen, nicht für alles

Ein Wildcard-Record kann Antworten für bestimmte sonst nicht vorhandene Namen erzeugen. Das wirkt praktisch für dynamische Subdomainmodelle, führt aber leicht zu Missverständnissen. Existierende spezifische Namen und Delegationen haben eigene Regeln; eine Wildcard ist kein pauschaler Textplatzhalter über den gesamten Baum.

Für klassische statische Websites ist ein expliziter Hostname oft leichter zu warten. Wildcards sollten nur eingesetzt werden, wenn der Anwendungsfall sie wirklich benötigt und Zertifikats-, Routing- und Sicherheitsfolgen verstanden sind.

NXDOMAIN, NODATA, SERVFAIL und REFUSED

DNS-Fehlerzustände unterscheiden sich deutlich. NXDOMAIN bedeutet, dass der abgefragte Name nicht existiert. NODATA beschreibt vereinfacht den Fall, dass der Name existiert, aber der angefragte Recordtyp fehlt. SERVFAIL weist auf einen Fehler beim Verarbeiten oder Validieren hin. REFUSED bedeutet, dass ein Server die Anfrage nicht bedienen will.

Diese Unterschiede sind für Diagnose entscheidend. Ein DNSSEC-Validierungsfehler kann beispielsweise als SERVFAIL beim validierenden Resolver sichtbar werden, obwohl ein nicht validierender Blick scheinbar Daten findet.

DNS über UDP und TCP

Klassisches DNS verwendet überwiegend UDP für normale Abfragen und TCP, wenn es erforderlich ist. Erweiterungen wie EDNS vergrößern die praktikable UDP-Nachrichtengröße, dennoch muss DNS mit Fragmentierungs- und Fallbackfragen umgehen.

Die pauschale Aussage „DNS ist UDP“ ist deshalb falsch. Zonentransfers nutzen TCP, große Antworten können TCP-Fallback auslösen, und verschlüsselte DNS-Transportvarianten verwenden wiederum eigene Transportmodelle.

EDNS – DNS erweitern, ohne das Grundformat zu ersetzen

Extension Mechanisms for DNS schaffen einen Erweiterungsrahmen für zusätzliche Optionen und größere Nachrichten, ohne das klassische DNS-Nachrichtenformat grundsätzlich zu ersetzen. Der OPT-Pseudorecord transportiert solche Erweiterungsinformationen.

DNSSEC wäre ohne EDNS-Unterstützung praktisch problematisch, weil kryptografische Signaturen Antworten vergrößern. Gleichzeitig müssen Netzwerkpfade mit größeren UDP-Datagrammen sorgfältig umgehen.

DNSSEC – Herkunft und Integrität von DNS-Daten absichern

DNSSEC ergänzt DNS um kryptografische Signaturen. Ein validierender Resolver kann damit prüfen, ob ein signiertes RRset authentisch aus der erwarteten Vertrauenskette stammt und unterwegs nicht verändert wurde. DNSKEY, DS und RRSIG bilden zentrale Teile dieser Vertrauenskette.

DNSSEC verschlüsselt die DNS-Inhalte nicht. Abfragen und Antworten können weiterhin sichtbar sein. Sein Zweck ist Authentizität und Integrität, nicht Vertraulichkeit. Diese Unterscheidung ist wesentlich, weil DNSSEC, DoT und DoH unterschiedliche Probleme adressieren.

Chain of Trust – von der Root zur signierten Zone

Die DNSSEC-Vertrauenskette verknüpft übergeordnete und untergeordnete Zonen. Eine Parent-Zone veröffentlicht einen DS-Record, der auf Schlüsselmaterial der Child-Zone verweist. Der validierende Resolver kann dadurch vom bekannten Trust Anchor bis zu den signierten Daten der Zielzone prüfen.

Ein Schlüsselwechsel muss so koordiniert werden, dass diese Kette nicht zeitweise bricht. Genau deshalb ist DNSSEC-Betrieb nicht nur das Aktivieren einer Checkbox, sondern Schlüssel- und Delegationsmanagement.

DNSKEY, DS und RRSIG

DNSKEY veröffentlicht öffentliche DNSSEC-Schlüssel einer Zone. RRSIG enthält Signaturen über RRsets. DS verbindet die Delegation der übergeordneten Zone mit dem Schlüsselzustand der untergeordneten Zone.

Private Signierschlüssel gehören nicht in DNS. Sie müssen geschützt verwaltet werden. DNS veröffentlicht nur die zur Validierung notwendigen öffentlichen Daten und Signaturen.

NSEC und NSEC3 – Nichtexistenz kryptografisch beweisen

DNSSEC muss nicht nur vorhandene Daten signieren, sondern auch glaubwürdig zeigen können, dass ein Name oder Recordtyp nicht existiert. NSEC und NSEC3 liefern dafür authentisierbare Nachweise.

Diese Mechanismen machen deutlich, dass „keine Antwort“ kryptografisch schwieriger zu belegen ist als ein vorhandener Datensatz. Eine signierte Zone benötigt deshalb Strukturen für positive und negative Aussagen.

Was DNSSEC ausdrücklich nicht löst

DNSSEC schützt nicht vor jeder Form von DNS- oder Netzstörung. Es bietet keine Vertraulichkeit und verhindert keine Denial-of-Service-Angriffe. Es schützt auch nicht automatisch Registrarkonten, Webserver, TLS-Schlüssel oder fehlerhafte DNS-Daten, die vom legitimen Zonenbetreiber selbst signiert wurden.

Eine kryptografisch gültige falsche Adresse bleibt falsch. DNSSEC bestätigt die Herkunft der veröffentlichten Information, nicht deren betriebliche Sinnhaftigkeit.

DNS over TLS – Resolvertransport verschlüsseln

DNS over TLS schützt DNS-Verkehr über TLS vor einfachem Mitlesen und Manipulation auf dem Transportweg zwischen den beteiligten Endpunkten. Typisch ist der Schutz zwischen Client beziehungsweise Stub und rekursivem Resolver.

DoT verändert nicht die inhaltliche DNS-Vertrauenskette. Der Resolver sieht die Anfrage weiterhin, und die weitere rekursive Auflösung kann andere Transportpfade verwenden. DNSSEC und DoT können deshalb sinnvoll nebeneinander existieren.

DNS over HTTPS – DNS in einem HTTPS-Austausch

DNS over HTTPS überträgt DNS-Abfragen als HTTP-Austausch über HTTPS. Das schützt den Transport zum DoH-Endpunkt und nutzt die bestehende HTTPS-Infrastruktur. Für Netzwerkbetreiber kann dadurch DNS-Verkehr schwerer von anderem HTTPS-Verkehr zu unterscheiden sein.

DoH verschiebt Vertrauen zum gewählten Resolverdienst. Verschlüsselter Transport bedeutet nicht, dass der Resolver die angefragten Namen nicht kennt. Datenschutz muss daher sowohl Transport als auch Betreiber und Protokollierung betrachten.

QNAME-Minimierung – nicht jedem Server den ganzen Namen zeigen

Bei klassischer rekursiver Auflösung kann ein Resolver mehr vom vollständigen angefragten Namen offenlegen, als eine übergeordnete Zone für die Delegationsentscheidung benötigt. QNAME-Minimierung reduziert diese Information und sendet an Zwischenstufen nur den jeweils erforderlichen Namensanteil.

Das Verfahren verbessert Datenschutz innerhalb der DNS-Auflösung, ohne das grundlegende DNS-Protokoll zu ersetzen. Es ist jedoch nur ein Baustein und macht DNS nicht vollständig vertraulich.

Hosts-Datei, lokaler Cache und DNS – mehrere Namensquellen

Betriebssysteme können vor oder neben DNS lokale Namensquellen auswerten. Eine Hosts-Datei kann Namen statisch auf Adressen abbilden. Browser und Betriebssysteme führen zusätzlich eigene Caches. Deshalb kann ein einzelner Rechner trotz korrektem autoritativem DNS noch eine abweichende lokale Antwort verwenden.

Bei Diagnose sollte deshalb geprüft werden, welche Resolverkette tatsächlich genutzt wird. Ein Test gegen einen autoritativen Nameserver beantwortet eine andere Frage als ein normaler Browseraufruf über den Systemresolver.

Split DNS und interne Namensräume

Organisationen können für denselben Namen intern andere Antworten bereitstellen als öffentlich. Dieses Split-Horizon- beziehungsweise Split-DNS-Modell ermöglicht interne Dienste oder private Adressen unter bekannten Namen.

Die Kehrseite ist Diagnosekomplexität. Ein Fehler kann nur im internen Netz auftreten, während externe Tests einwandfrei aussehen. Dokumentation muss deshalb festhalten, welche Resolverquelle in welchem Netz zuständig ist.

Anycast – dieselbe IP an vielen Standorten

Große DNS- und CDN-Dienste nutzen häufig Anycast. Dieselbe IP-Adresse wird aus mehreren Netzknoten angekündigt, und das Routing führt Clients typischerweise zu einem topologisch günstigen Standort.

Anycast ist keine DNS-Funktion im engeren Sinn. DNS kann auf eine Anycast-Adresse zeigen, aber die Auswahl des konkreten Standorts erfolgt anschließend durch das IP-Routing. Damit werden Namensauflösung und Netzrouting erneut als getrennte Ebenen sichtbar.

Webhosting – Dateien, Prozesse und Netzanschluss bereitstellen

Webhosting stellt die technische Umgebung bereit, in der eine Website über HTTP beziehungsweise HTTPS erreichbar ist. Bei einer statischen Website genügt im Kern ein Webserver, der Dateien aus einem DocumentRoot ausliefert. Dynamische Anwendungen benötigen zusätzlich Laufzeiten, Prozesse, Datenbanken oder andere Dienste.

Der Hostinganbieter muss nicht Registrar oder DNS-Provider sein. Diese Trennung ermöglicht Wechsel einzelner Komponenten, verlangt aber saubere Zuordnung von Domain, Nameservern, Zertifikaten und Serverkonfiguration.

Shared Hosting – viele Websites auf verwalteter Infrastruktur

Beim Shared Hosting teilen sich viele Kunden eine vom Anbieter verwaltete Serverplattform. Webserver, Betriebssystem, Sicherheitsupdates und häufig auch Mail-, Datenbank- oder Backupfunktionen werden weitgehend zentral betrieben.

Für statische Websites kann dieses Modell sehr effizient sein: wenig Administrationsaufwand, vorhersehbare Oberfläche und geringe Kosten. Einschränkungen bestehen bei tiefen Systemänderungen, speziellen Diensten oder individuellen Netzanforderungen.

Managed Hosting – mehr Kontrolle ohne vollständige Systempflege

Managed-Angebote kombinieren dediziertere Ressourcen oder virtuelle Server mit Betriebsleistungen des Providers. Welche Aufgaben tatsächlich übernommen werden, variiert erheblich und muss vertraglich beziehungsweise technisch geklärt sein.

Der Begriff „managed“ ist keine Protokolleigenschaft. Entscheidend ist konkret, wer Betriebssystemupdates, Webserverkonfiguration, Sicherungen, Monitoring und Wiederherstellung verantwortet.

VPS – virtuelle Maschine mit eigener Systemumgebung

Ein Virtual Private Server stellt eine virtualisierte Betriebssystemumgebung mit eigener Konfiguration bereit. Dadurch sind Webserver, Laufzeiten und Systemdienste frei wählbarer als im klassischen Shared Hosting.

Diese Freiheit erhöht die Verantwortung. Sicherheitsupdates, Firewall, Benutzerkonten, SSH, Logrotation und Dienstkonfiguration müssen aktiv gepflegt werden, sofern der Anbieter sie nicht ausdrücklich übernimmt.

Root-Server und dedizierte Systeme

Ein dediziertes beziehungsweise vollständig administrierbares System bietet maximale Kontrolle über Hardware- oder virtuelle Ressourcen. Für eine kleine statische Website ist diese Kontrolle häufig technisch unnötig und erhöht die Wartungsfläche.

Der passende Hostingtyp richtet sich nicht nach Prestige, sondern nach Anforderungen. Ein statisches Archiv mit wenigen serverseitigen Funktionen kann auf einfacher verwalteter Infrastruktur langfristig robuster sein als auf einem komplexen selbst administrierten Stack.

Statisches Hosting – fertige Dateien statt Anwendungsserver

Statische Websites liefern vorab erzeugte HTML-, CSS-, JavaScript- und Mediendateien aus. Es gibt keinen serverseitigen Anwendungscode, der für jeden Seitenaufruf Inhalte zusammensetzt. Das reduziert Abhängigkeiten und Angriffsfläche.

Für SSLXY passt dieses Modell besonders gut zur Archivfunktion: Dateien bleiben direkt lesbar, Sicherungen sind einfach, Serverwechsel erfordern keine komplexe Datenbankmigration und historische Stände können als vollständige Dateisätze erhalten bleiben.

DocumentRoot, Verzeichnisstruktur und URL-Pfade

Der Webserver ordnet URL-Pfade einer Konfiguration und häufig einem Dateisystembereich zu. Ein DocumentRoot definiert dabei den Basisbereich für statische Inhalte. Die URL /archiv/a.htm kann intern auf eine Datei unterhalb dieses Wurzelverzeichnisses zeigen.

Die Zuordnung ist Serverkonfiguration, keine Eigenschaft von DNS. Ein Domainumzug kann daher DNS unverändert lassen und nur Serverpfade verändern – oder umgekehrt. Saubere Root-relative Links reduzieren Probleme, wenn Seiten innerhalb derselben Domain in unterschiedlich tiefen URL-Pfaden liegen.

Virtual Hosts – viele Domains auf einer IP-Adresse

Ein einzelner Webserver kann viele Hostnamen bedienen. Bei HTTP überträgt der Client den gewünschten Hostnamen, und der Server wählt daraufhin die passende virtuelle Website. Bei HTTPS muss zusätzlich bereits während des TLS-Aufbaus klar sein, für welchen Namen die Verbindung gedacht ist.

Server Name Indication ermöglicht, den Hostnamen im TLS-Handshake zu signalisieren. Dadurch können mehrere HTTPS-Websites dieselbe IP-Adresse nutzen und trotzdem unterschiedliche Zertifikate erhalten.

IPv4 und IPv6 parallel betreiben

Webhosting kann über IPv4, IPv6 oder beide Protokolle erreichbar sein. DNS veröffentlicht dafür A- und AAAA-Records. Ein Dual-Stack-Client kann mehrere Verbindungswege ausprobieren und entscheidet anhand seiner Netzbedingungen.

Betrieblich sollten beide Protokollfamilien separat geprüft werden. Firewallregeln, TLS, Webserverbindungen und Routing können auf IPv6 anders konfiguriert sein als auf IPv4. Ein vorhandener AAAA-Record sollte deshalb als echte Betriebszusage verstanden werden.

Ports 80 und 443 – Konvention und Protokollzuordnung

HTTP wird klassisch über TCP-Port 80 angeboten, HTTPS über Port 443. Bei HTTP/3 verwendet HTTPS QUIC über UDP, typischerweise ebenfalls auf Port 443. Der Port allein bestimmt jedoch nicht vollständig die Anwendung; Client und Server müssen das Protokoll gemeinsam sprechen.

Firewall und Hostingplattform müssen den benötigten Transport zulassen. Ein Webserver kann auf zusätzlichen Ports lauschen, normale URLs verwenden ohne explizite Portangabe jedoch die Standards des jeweiligen Schemas.

TLS – kryptografischer Kanal vor dem HTTP-Austausch

HTTPS ist HTTP über einen kryptografisch geschützten Transport. TLS authentisiert typischerweise den Server über Zertifikate, vereinbart Schlüsselmaterial und schützt anschließend Vertraulichkeit und Integrität der übertragenen HTTP-Daten.

TLS schützt nicht automatisch den Webserver vor kompromittierten Dateien oder fehlerhaften Anwendungen. Ebenso sagt ein gültiges Zertifikat nicht, dass der Inhalt sachlich korrekt oder vertrauenswürdig ist. Es bestätigt primär die kryptografische Verbindung zum zertifizierten Namenskontext.

TLS 1.3 – aktueller Standardstand 2026

TLS 1.3 wurde 2026 in einer aktualisierten Standardspezifikation neu veröffentlicht. RFC 9846 beschreibt weiterhin TLS-Version 1.3, löst aber die frühere RFC-8446-Fassung ab und präzisiert Anforderungen sowie Sicherheitsdetails.

Für aktuelle Dokumentation sollte deshalb nicht mehr so getan werden, als sei RFC 8446 die neueste normative TLS-1.3-Spezifikation. Der Protokollname und die Versionsnummer bleiben TLS 1.3; geändert wurde die maßgebliche Standardspezifikation.

Zertifikat, privater Schlüssel und Vertrauenskette

Ein Serverzertifikat bindet einen öffentlichen Schlüssel beziehungsweise eine Zertifikatsidentität an Domainnamen und wird von einer Zertifizierungsstelle signiert. Der Browser prüft Namensübereinstimmung, Gültigkeit, Vertrauenskette und weitere Sicherheitsanforderungen.

Der private Schlüssel bleibt auf der kontrollierten Serverseite und darf nicht mit dem Zertifikat verwechselt werden. Ein gestohlener privater Schlüssel ist wesentlich kritischer als ein öffentlich einsehbares Zertifikat.

Subject Alternative Name – welche Hostnamen ein Zertifikat abdeckt

Moderne Zertifikatsprüfung orientiert sich an den im Zertifikat eingetragenen Namen. Ein Zertifikat für www.example.org deckt nicht automatisch example.org oder beliebige Subdomains ab. Die benötigten Namen müssen passend enthalten sein.

Beim Domain- oder Hostnamenwechsel sollte das Zertifikat deshalb vor der Umschaltung für alle neuen Ziele verfügbar sein. DNS allein kann keinen TLS-Namensfehler reparieren.

Wildcard-Zertifikate – begrenzte Namensabdeckung

Ein Wildcard-Zertifikat kann eine Ebene von Subdomains abdecken, etwa *.example.org. Es deckt nicht automatisch den Zonenapex example.org und nicht beliebig tiefe Namen wie a.b.example.org ab.

Wildcard-Zertifikate vereinfachen bestimmte Infrastrukturen, erhöhen aber den Wirkungsbereich eines einzelnen privaten Schlüssels. Für wenige feste Hostnamen können getrennte oder explizit benannte Zertifikate leichter zu begrenzen sein.

Automatisierte Zertifikatsausstellung und Erneuerung

Moderne Hostingplattformen automatisieren Zertifikatsausstellung und Verlängerung häufig vollständig. Das reduziert das Risiko manueller Ablaufdaten, setzt aber funktionierende Domainvalidierung, DNS- oder HTTP-Erreichbarkeit und eine zuverlässige Automatisierung voraus.

Automatisierung sollte überwacht werden. Ein Zertifikat kann technisch noch wochenlang gültig sein, obwohl die nächste Erneuerung wegen geänderter DNS-Records, Berechtigungen oder Rate-Limits bereits scheitert.

HTTP – Methode, Ziel, Felder, Status und Inhalt

HTTP ist ein zustandsloses Anwendungsprotokoll. Ein Client sendet eine Anfrage mit Methode, Ziel und Feldern; der Server antwortet mit Statuscode, Feldern und gegebenenfalls Inhalt. GET, HEAD, POST und andere Methoden besitzen definierte Semantik.

Die semantische Ebene ist grundsätzlich unabhängig davon, ob HTTP/1.1, HTTP/2 oder HTTP/3 für den Transport verwendet wird. Deshalb beschreibt die moderne HTTP-Spezifikation gemeinsame Semantik getrennt von den jeweiligen Versionen der Nachrichtenübertragung.

Statuscodes – 200, 301, 404 und 500 sind unterschiedliche Aussagen

HTTP-Statuscodes bilden Klassen: 2xx steht für erfolgreiche Verarbeitung, 3xx für Umleitung, 4xx für clientbezogene beziehungsweise anfragebezogene Fehler und 5xx für serverseitige Fehlerzustände. Ein 404 bedeutet, dass die angeforderte Ressource nicht gefunden wurde, nicht dass DNS oder Domainregistrierung fehlen.

Für SEO und Archivpflege ist der tatsächliche HTTP-Status entscheidend. Eine hübsche Fehlerseite mit Status 200 ist technisch keine echte 404-Antwort und kann als Soft-404 missverstanden werden.

301 und andere Redirects – URLs kontrolliert umziehen

HTTP-Redirects teilen einem Client mit, dass eine Ressource an einer anderen URL liegt. Ein 301 signalisiert eine dauerhafte Verschiebung. Für langfristige URL-Migrationen ist eine gezielte Weiterleitung auf die inhaltlich passende neue Ressource meist sinnvoller als pauschales Umleiten aller alten Pfade auf die Startseite.

Redirects gehören zum Webserver beziehungsweise zur Anwendungsebene. DNS kann nur Hostnamen zu Diensten führen und kennt keine einzelnen alten HTML-Pfade.

HTTP/2 – multiplexte Streams über eine Verbindung

HTTP/2 führt ein binäres Framing ein und ermöglicht mehrere parallele HTTP-Streams innerhalb einer Verbindung. Headerkompression und Priorisierungsmechanismen reduzieren bestimmte Kosten klassischer HTTP/1.1-Verbindungsmuster.

Die sichtbaren HTTP-Methoden, Statuscodes und URLs bleiben grundsätzlich dieselben. Eine Website muss deshalb nicht inhaltlich neu gebaut werden, nur weil der Server HTTP/2 ausliefert.

HTTP/3 – HTTP über QUIC

HTTP/3 bildet HTTP-Semantik über QUIC ab. QUIC stellt verschlüsselte, streamorientierte Übertragung über UDP bereit und integriert Transport- und Sicherheitsmechanismen enger als die klassische Kombination HTTP über TCP plus TLS.

Mehrere Streams blockieren sich bei Paketverlust nicht auf dieselbe Weise wie unabhängige HTTP/2-Streams innerhalb einer einzelnen TCP-Verbindung. Für den Webseiteninhalt bleibt HTTP/3 dennoch eine Transportfrage; HTML-Dateien müssen nicht wegen HTTP/3 anders geschrieben werden.

ALPN – Protokollauswahl während TLS

Application-Layer Protocol Negotiation erlaubt Client und Server, im TLS-Kontext auszuhandeln, welches Anwendungsprotokoll verwendet wird. Dadurch kann beispielsweise HTTP/2 ausgewählt werden, ohne einen zusätzlichen Klartext-Aushandlungsschritt einzuführen.

HTTP/3 nutzt QUIC mit eigener TLS-Integration, folgt aber ebenfalls dem Grundprinzip expliziter Protokollvereinbarung. Die DNS-Servicebindung über HTTPS-Records kann Clients zusätzliche Hinweise liefern.

Brotli und Deflate – Übertragung komprimieren

Textressourcen wie HTML, CSS, JavaScript, JSON oder SVG lassen sich vor der Übertragung komprimieren. Der Server wählt anhand der Clientfähigkeiten eine passende Inhaltskodierung und kennzeichnet diese in der HTTP-Antwort.

Kompression spart Bandbreite, sollte aber nicht blind auf bereits komprimierte Bild-, Video- oder Archivformate angewandt werden. Statische Hostingumgebungen können komprimierte Varianten häufig effizient erzeugen oder zwischenspeichern.

HTTP-Caching – getrennt vom DNS-Cache

Browser- und Proxy-Caches für Webressourcen sind eine andere Ebene als DNS-Caches. Cache-Control, ETag und Last-Modified steuern, wann HTML, Bilder oder andere Inhalte erneut angefordert beziehungsweise validiert werden.

Bei Änderungen kann deshalb die DNS-Auflösung bereits aktuell sein, während der Browser noch eine ältere Ressource zeigt. Umgekehrt kann HTML frisch geladen werden, obwohl der DNS-Resolver weiterhin dieselbe gecachte Serveradresse verwendet.

ETag und 304 – unveränderte Inhalte nicht erneut übertragen

Ein ETag ist ein Validator für eine Repräsentation. Der Client kann bei einer späteren Anfrage seinen bekannten Wert mitsenden. Ist die Ressource unverändert, kann der Server mit 304 Not Modified antworten und den eigentlichen Inhalt nicht erneut übertragen.

Für statische Archive ist Revalidierung oft sinnvoller als pauschales no-store. So bleibt Aktualität kontrollierbar, ohne jede Ressource bei jedem Aufruf vollständig neu zu laden.

HSTS – HTTPS für künftige Verbindungen erzwingen

HTTP Strict Transport Security teilt einem Browser über eine HTTPS-Antwort mit, dass eine Domain für einen definierten Zeitraum nur noch über HTTPS angesprochen werden soll. Dadurch werden spätere versehentliche HTTP-Aufrufe lokal auf HTTPS gehoben.

HSTS ist eine starke Betriebszusage. Lange Laufzeiten, includeSubDomains oder Preload sollten erst aktiviert werden, wenn sämtliche betroffenen Hosts dauerhaft HTTPS-fähig sind. Eine falsch gesetzte langfristige Richtlinie kann Subdomains ungewollt unzugänglich machen.

Security Header – ergänzende Browsergrenzen

Header wie Content-Security-Policy, X-Content-Type-Options, Referrer-Policy und Permissions-Policy begrenzen Browserverhalten oder Informationsweitergabe. Sie ersetzen keine sichere Serverkonfiguration, können aber die Folgen bestimmter Fehler deutlich reduzieren.

Eine Richtlinie muss zum tatsächlich ausgelieferten Inhalt passen. Besonders hashbasierte CSP ist bytegenau: Bereits eine kleine Änderung im Inline-CSS oder JavaScript macht den zuvor berechneten Hash ungültig.

CSP-Hashes – Sicherheit verlangt Synchronität

Eine Content Security Policy kann Inline-Styles oder -Skripte über kryptografische Hashes freigeben. Der Browser berechnet den Hash des real empfangenen Blocks und vergleicht ihn mit der Richtlinie. Stimmt er nicht exakt, wird der Block verworfen.

Damit wird der Veröffentlichungsprozess selbst Teil der Sicherheitsarchitektur. HTML-Datei und CSP-Header müssen aus demselben Endstand stammen. Ein Hash einer lokal älteren Fassung kann mathematisch korrekt und für die Live-Datei trotzdem falsch sein.

Apache, nginx und andere Webserver – Umsetzung statt Webstandard

Webserver implementieren HTTP, TLS-Anbindung, virtuelle Hosts, Dateiauslieferung, Logging und zahlreiche Zusatzfunktionen. Apache und nginx sind bekannte Beispiele, aber weder HTML noch DNS hängen konzeptionell von einem bestimmten Serverprodukt ab.

Serverkonfiguration ist produktspezifisch. Direktiven aus einer .htaccess-Datei gehören zum Apache-Kontext und lassen sich nicht unverändert auf andere Server übertragen. Eine Migration erfordert deshalb die Übersetzung der beabsichtigten Wirkung, nicht nur das Kopieren von Konfigurationssyntax.

.htaccess – verzeichnisbezogene Apache-Konfiguration

Auf entsprechend konfigurierten Apache-Servern kann .htaccess Einstellungen innerhalb eines Verzeichnisbaums steuern. Typische Anwendungen sind Rewrite-Regeln, eigene Fehlerdokumente, Header oder Cachevorgaben.

Die Datei wird nur berücksichtigt, wenn der Server dies erlaubt. Manche Hostingplattformen schränken Direktiven ein oder verwenden völlig andere Webserver. Eine funktionierende .htaccess ist daher Teil des konkreten Hostingzustands, nicht der Website als universeller Standard.

URL-Rewriting und kanonische Hosts

Rewrite-Regeln können HTTP auf HTTPS umleiten, www-Varianten vereinheitlichen oder alte Pfade auf neue URLs führen. Solche Regeln laufen nach dem DNS-Schritt: Der Client muss den Webserver bereits erreicht haben.

Kanonisierung sollte deterministisch sein. Mehrere gegeneinander laufende Regeln erzeugen Redirect-Schleifen oder lange Ketten. Ein klar definierter Zielhost und eine einzige bevorzugte URL pro Inhalt erleichtern Betrieb und Suchmaschineninterpretation.

Eigene Fehlerseiten und echte HTTP-Fehler

Ein Webserver kann bei 404, 403 oder 500 eigene HTML-Seiten anzeigen. Entscheidend ist, dass der ursprüngliche Statuscode erhalten bleibt. Eine interne Fehlerdokumentzuordnung ist daher oft besser als eine externe Weiterleitung auf eine Fehlerseite.

Bei 404-Seiten sind root-relative Links besonders robust, weil dieselbe Fehlerseite für fehlende URLs in unterschiedlich tiefen Pfaden erscheinen kann.

Access Log und Error Log – Betrieb sichtbar machen

Webserverlogs zeigen Anfragen, Statuscodes, übertragene Daten und technische Fehler. Access Logs dokumentieren Zugriffe; Error Logs enthalten serverseitige Diagnose. Beide sind für Migrationen, Fehlersuche und Sicherheitsanalyse wertvoll.

Logs können personenbezogene oder sicherheitsrelevante Informationen enthalten. Aufbewahrung, Zugriffsschutz und Datenminimierung müssen deshalb bewusst geregelt werden. Das technische Thema wird auf cgi-und-logfiles.htm vertieft.

Monitoring – DNS, TLS und HTTP getrennt prüfen

Ein sinnvoller Verfügbarkeitstest prüft nicht nur, ob irgendeine URL einen Status 200 liefert. Domainablauf, DNS-Auflösung, Nameservererreichbarkeit, Zertifikatsgültigkeit, HTTP-Status und tatsächlicher Seiteninhalt sind getrennte Messpunkte.

Mehrstufiges Monitoring erleichtert Diagnose. Ist DNS erfolgreich, TLS aber nicht, liegt der Fehlerbereich anders als bei NXDOMAIN. Ist TLS korrekt, aber HTTP 500, muss der Webserver beziehungsweise die Anwendung untersucht werden.

CDN – Inhalte näher am Client zwischenspeichern

Content Delivery Networks verteilen oder cachen Inhalte an mehreren Standorten. DNS, Anycast und HTTP-Caching können gemeinsam dazu beitragen, Anfragen zu einem geeigneten Edge-Standort zu führen.

Ein CDN verändert die Fehlerkette. Der Browser kann mit einem Edge-Server sprechen, während dieser Inhalte vom Origin bezieht. Diagnose muss deshalb unterscheiden, ob ein Fehler am Edge, im Cache, in DNS oder am Origin entsteht.

Reverse Proxy – vorgelagerter HTTP-Endpunkt

Ein Reverse Proxy nimmt Clientverbindungen entgegen und leitet Anfragen an interne Backendserver weiter. Er kann TLS terminieren, Caching, Kompression, Routing oder Sicherheitsfilter übernehmen.

Für statische Websites kann ein Reverse Proxy unnötig sein; bei größeren Infrastrukturen schafft er eine klare Trennung zwischen öffentlichem Eintrittspunkt und internen Diensten. Jede zusätzliche Schicht muss jedoch dokumentiert und überwacht werden.

Load Balancing – mehrere Server für einen Dienst

Mehrere Webserver können hinter einem Load Balancer denselben Hostnamen bedienen. DNS sieht dann gegebenenfalls nur die Adresse des Balancers oder mehrere gleichwertige Endpunkte. Der Balancer verteilt Anfragen anhand seiner Regeln.

Zustandslose statische Websites lassen sich besonders einfach verteilen, weil jeder Server denselben Dateibestand ausliefern kann. Dynamische Anwendungen benötigen zusätzlich Strategien für Sitzungen, Datenbanken und konsistenten gemeinsamen Zustand.

Origin – der eigentliche Ursprung hinter Cache und Proxy

Im CDN- und Proxykontext bezeichnet Origin den Server beziehungsweise Dienst, von dem der vorgelagerte Knoten Inhalte bezieht. Der Origin kann öffentlich erreichbar oder auf Zugriffe des CDN begrenzt sein.

Ein DNS-Eintrag der öffentlichen Website muss deshalb nicht zwingend direkt auf den Origin zeigen. Bei Migrationen ist zu klären, welche Adresse öffentlich, welche intern und welche nur als Backendziel verwendet wird.

FTP, SFTP und Deployment – Dateien auf den Server bringen

Frühe Webhostingumgebungen wurden häufig direkt per FTP gepflegt. SFTP verwendet dagegen SSH als Transport und ist technisch nicht einfach „verschlüsseltes FTP“. Moderne Deploymentverfahren reichen von Dateisynchronisation bis zu Versionskontroll- und Buildpipelines.

Für ein statisches Archiv bleibt der Kern derselbe: Der veröffentlichte Dateisatz muss vollständig und nachvollziehbar auf den Webspace gelangen. Abgebrochene oder teilweise Uploads können HTML, TXT, CSP-Dateien und Konfiguration in unterschiedliche Stände versetzen.

Shell-Accounts – frühes Webhosting als Unix-Arbeitsumgebung

In der frühen Webzeit bedeutete Hosting häufig nicht nur einen grafischen Dateimanager. Shell-Accounts boten direkten Zugang zu einer Unix-Umgebung, Dateirechten, Verzeichnissen, Editoren, CGI-Verzeichnissen und Logdateien. Webbetrieb war dadurch eng mit Systemverständnis verbunden.

Die dokumentierte SSLXY-Webspur beginnt 1996 in genau diesem Umfeld aus Shell-Account, HTML, CGI und Logdateien. Die Vertiefung liegt auf shell-accounts-und-hosts.htm und erste-webseiten-1995-1996.htm.

CGI – wenn Webhosting Programme startet

Common Gateway Interface machte aus statischem Webspace eine programmierbare Serverumgebung. Ein Webserver konnte externe Programme starten, Anfragedaten über definierte Schnittstellen bereitstellen und deren Ausgabe als HTTP-Antwort verwenden.

Damit entstanden neue Hostinganforderungen: Ausführungsrechte, Interpreter, sichere Eingaben, Prozessressourcen und Error Logs. Die Technik wird auf programmierung-und-skripting.htm und cgi-und-logfiles.htm ausführlicher behandelt.

Dateirechte – lesen, schreiben und ausführen begrenzen

Webserverprozesse benötigen nur die Rechte, die für ihre Aufgabe erforderlich sind. Statische Dateien müssen meist lesbar sein, aber nicht durch den Webprozess verändert werden können. Upload- oder Anwendungsverzeichnisse benötigen gegebenenfalls gezielte Schreibrechte.

Zu großzügige Rechte erleichtern Fehlerausbreitung. Zu restriktive Rechte führen dagegen zu 403- oder Serverfehlern. Rechte sollten deshalb als Teil der Serverarchitektur dokumentiert werden, nicht durch wiederholtes pauschales Freigeben erraten werden.

Benutzer, Gruppen und Besitzverhältnisse

Unix-artige Hostingumgebungen unterscheiden Dateibesitzer, Gruppen und andere Benutzer. Der Webserver kann unter einem eigenen Dienstkonto laufen, während Uploads einem Hostingkonto gehören. Daraus entstehen unterschiedliche Schreib- und Lesepfade.

Ein funktionierender Zustand sollte nicht davon abhängen, dass sämtliche Dateien weltweit beschreibbar sind. Saubere Besitz- und Gruppenmodelle reduzieren Sicherheitsrisiken und erklären viele vermeintlich rätselhafte Berechtigungsfehler.

Backups – Domain, DNS und Webdateien getrennt sichern

Eine Website-Sicherung sollte mehr umfassen als HTML-Dateien. DNS-Zone, Webserverkonfiguration, Zertifikatsautomation, Redirectregeln und Dokumentation der Registrar- beziehungsweise Providerzuständigkeiten gehören zum Wiederherstellungsplan.

Umgekehrt ersetzt ein Webhostingbackup keine Kontrolle über die Domainregistrierung. Ein Provider kann Dateien wiederherstellen, aber nicht zwingend eine verlorene Domain oder ein kompromittiertes Registrarkonto. Die allgemeine Sicherungsstrategie liegt auf datensicherung-und-backups.htm.

DNS-Zone vor Änderungen inventarisieren

Vor einem Nameserver- oder Providerwechsel sollte der vollständige DNS-Bestand dokumentiert werden. Dazu gehören nicht nur A und AAAA der Website, sondern NS, MX, TXT, CAA, SRV, Verifikationsrecords, Subdomains und gegebenenfalls DNSSEC-Daten.

Ein unvollständiger Export ist ein klassischer Migrationsfehler. Die Website funktioniert anschließend, während E-Mail, Verifikation oder ein Spezialdienst ausfällt. Eine tabellarische Vorher-/Nachher-Liste macht den Wechsel kontrollierbarer.

Webhosting umziehen, ohne die Domain zu verlieren

Ein Hostingwechsel kann vorbereitet werden, während die Domain weiterhin auf den alten Server zeigt. Der neue Webspace wird vollständig eingerichtet, über eine Testadresse oder lokale Namenszuordnung geprüft und erst anschließend im DNS aktiviert.

Dadurch bleibt die eigentliche Umschaltung klein: A/AAAA oder ein entsprechender Zielrecord ändert sich, während Domainregistrierung und Nameserver bestehen bleiben. Diese Trennung reduziert Risiko.

Nameserverwechsel – die gesamte Zone zieht um

Ein Nameserverwechsel ist weitreichender als ein Webserverwechsel. Die autoritative Zuständigkeit wechselt. Deshalb muss die neue DNS-Zone vor der Delegationsänderung vollständig und korrekt vorhanden sein.

DNSSEC erhöht die Anforderungen zusätzlich, weil DS- und Schlüsselzustände über die Delegationsgrenze zusammenpassen müssen. Ein falsch koordinierter Wechsel kann validierende Resolver vollständig aussperren.

TTL vor einer geplanten Migration reduzieren

Wenn ein Webserverwechsel ansteht, kann eine vorab reduzierte TTL die Lebensdauer alter gecachter Zieladressen verkürzen. Die Änderung muss jedoch früh genug erfolgen, damit die vorherige längere TTL aus den Resolvercaches auslaufen kann.

Nach der Umstellung sollte der alte Server noch eine Übergangszeit erreichbar bleiben, wenn dies betrieblich möglich ist. So werden Clients abgefangen, deren Resolver noch alte Daten verwenden.

Parallelbetrieb während der Umschaltung

Bei kritischen Migrationen können alter und neuer Server zeitweise denselben Inhalt ausliefern. Für statische Websites ist das besonders einfach, weil keine verteilten Schreibzustände synchronisiert werden müssen.

Der Parallelbetrieb sollte zeitlich begrenzt und kontrolliert sein. Nach Ablauf der erwarteten Cachezeiten kann der alte Endpunkt entfernt oder gezielt weitergeleitet werden.

Canonical-URL – Inhaltspräferenz, keine Netzwerkumleitung

Ein rel=canonical-Element teilt Suchmaschinen die bevorzugte URL eines Inhalts mit. Es ist keine HTTP-Weiterleitung und verhindert nicht, dass Benutzer eine andere URL aufrufen.

Technische Kanonisierung sollte deshalb auf mehreren Ebenen konsistent sein: bevorzugter HTTPS-Host, Redirects von Alternativen, interne Links und Canonical-Metadaten sollten dieselbe URL-Struktur widerspiegeln.

www oder ohne www – beides kann korrekt sein

www ist technisch lediglich ein Hostname unterhalb einer Domain. Eine Website kann unter www.example.org oder direkt unter example.org betrieben werden. Wichtig ist nicht die Wahl selbst, sondern eine eindeutige kanonische Strategie.

Wenn beide Varianten erreichbar sind, sollte eine auf die andere weiterleiten. DNS kann dafür unterschiedliche Records setzen; die eigentliche dauerhafte URL-Vereinheitlichung erfolgt über HTTP-Redirects.

Subdomains – organisatorische Struktur im Namensraum

Subdomains können Dienste, Regionen, Archive oder technische Umgebungen trennen. DNS erlaubt beliebige zusätzliche Labels innerhalb der administrativen Grenzen. Ob eine Subdomain als eigene Zone delegiert wird oder innerhalb derselben Zone bleibt, ist eine separate Entscheidung.

Zu viele Subdomains können Verwaltung und Zertifikate unnötig verkomplizieren. Für statische Archive sind stabile Pfade unter einer Domain häufig einfacher als für jedes Thema ein eigener Hostname.

Staging und Testumgebungen

Eine Testumgebung erlaubt Änderungen an Serverkonfiguration, TLS, Redirects oder Dateien, bevor die öffentliche Domain betroffen ist. Sie sollte jedoch nicht versehentlich von Suchmaschinen als zweiter öffentlicher Inhaltsbestand behandelt werden.

Testhosts benötigen ebenso Zugangsschutz und aktuelle Software wie Produktionssysteme. Eine vergessene Staginginstanz kann langfristig eine größere Angriffsfläche darstellen als die eigentliche Website.

DNS diagnostizieren – autoritativ und rekursiv getrennt testen

Ein DNS-Test sollte zunächst feststellen, welche Nameserver autoritativ sind und welche Antwort diese direkt liefern. Danach kann geprüft werden, was ein bestimmter rekursiver Resolver sieht. So lassen sich Zonenfehler von Cache- oder Resolverproblemen unterscheiden.

A, AAAA, NS, SOA, CAA und DNSSEC-Zustand sollten je nach Problem einzeln betrachtet werden. Eine pauschale Aussage „DNS geht“ ist bei komplexeren Fehlern zu grob.

TLS diagnostizieren – Name, Kette und Protokoll getrennt prüfen

Bei TLS-Problemen sind Zertifikatsname, Gültigkeitszeit, Zertifikatskette, Server Name Indication und unterstützte Protokollversionen getrennte Prüfbereiche. Ein Browserfehler kann aus jedem dieser Bereiche stammen.

DNS kann dabei korrekt sein und trotzdem auf einen Server zeigen, dessen Zertifikat den Hostnamen nicht abdeckt. Umgekehrt kann ein perfektes Zertifikat auf einem Server liegen, den der DNS-Record noch nicht erreicht.

HTTP diagnostizieren – Header und Status vor der Optik

Bevor eine Seite visuell beurteilt wird, liefert der HTTP-Status wichtige Informationen. Redirectketten, Cache-Header, Content-Type, Content-Security-Policy und Serverantworten können direkt erklären, warum ein Browser anders reagiert als erwartet.

Entwicklerwerkzeuge zeigen zusätzlich Netzwerkreihenfolge und blockierte Ressourcen. Eine optisch zerfallene Seite kann beispielsweise vollständig geladenes HTML besitzen, während CSS aufgrund einer CSP-Regel blockiert wird.

„DNS-Propagation“ – nützliches Wort, technisch oft zu ungenau

Nach einer DNS-Änderung wird häufig von weltweiter Propagation gesprochen. Tatsächlich wird nicht eine zentrale neue Zone Stück für Stück um den Globus kopiert. Autoritative Daten ändern sich, während rekursive Resolver und andere Caches alte Antworten bis zum Ablauf ihrer Gültigkeit weiterverwenden.

Bei Nameserverdelegationen kommen zusätzlich Parent-Zone, Glue, Resolvercaches und möglicherweise DNSSEC-Zustände hinzu. Präziser ist deshalb die Frage, welche konkrete Information an welcher Cache- oder Delegationsebene noch alt ist.

Cache leeren hilft nur auf der richtigen Ebene

Das Leeren eines lokalen DNS-Caches kann eine veraltete Antwort auf dem eigenen Rechner beseitigen. Es ändert jedoch weder den Cache des rekursiven Providers noch autoritative Daten oder Browser-HSTS-Zustände.

Ähnlich wirkt ein Browser-Reload nur auf Webressourcen und nicht automatisch auf Betriebssystem- oder Resolvercache. Diagnose sollte gezielt die betroffene Schicht zurücksetzen, statt alle Caches gleichzeitig zu löschen und dadurch Beobachtungen unklar zu machen.

Domain-Hijacking – Infrastruktur beginnt beim Konto

Wird ein Registrarkonto übernommen, kann ein Angreifer Nameserver oder Domainzustände verändern und damit Website sowie E-Mail umleiten. Dieser Angriff findet oberhalb des Webservers statt; dessen lokale Sicherheit kann dabei vollständig intakt bleiben.

Mehrfaktor-Authentisierung, starke Wiederherstellungswege, Änderungsbenachrichtigungen und minimale Zahl privilegierter Konten gehören deshalb zur Websicherheit genauso wie TLS und Serverupdates.

DNS-Manipulation, Cache Poisoning und Validierung

DNS wurde ursprünglich nicht für kryptografische Authentizität entworfen. Angriffe auf Resolverzustände oder Netzpfade können falsche Antworten einschleusen, wenn keine geeigneten Schutzmechanismen greifen.

DNSSEC ermöglicht kryptografische Validierung autoritativer Daten. Verschlüsselte Resolvertransporte schützen zusätzlich bestimmte Kommunikationswege. Kein einzelner Mechanismus ersetzt jedoch sichere Registrar-, Provider- und Serverkonten.

Hosting-Härtung – nur notwendige Dienste betreiben

Ein Webserver sollte nur die Dienste und Module bereitstellen, die tatsächlich benötigt werden. Unbenutzte administrative Oberflächen, alte Laufzeiten und offene Ports erhöhen die Angriffsfläche.

Bei statischen Seiten ist die Härtung besonders klar: Schreibrechte minimieren, serverseitige Laufzeiten vermeiden, unnötige Dienste deaktivieren, sichere Header setzen und Updates der verbleibenden Plattformkomponenten pflegen. Die Vertiefung liegt auf server-haertung.htm.

API-Tokens, DNS-Schlüssel und Zugangsdaten

DNS-Provider-APIs und Zertifikatsautomation können hochprivilegierte Tokens verwenden. Solche Geheimnisse dürfen nicht in öffentlich ausgelieferten HTML-, JavaScript- oder Repository-Dateien landen.

Besser sind eng begrenzte Rechte, getrennte Geheimnisspeicher und kurze beziehungsweise rotierbare Zugangsdaten. Ein Token, das nur einen bestimmten DNS-Record ändern darf, begrenzt den Schaden gegenüber einem vollständigen Kontoschlüssel.

Externe Abhängigkeiten und DNS als Lieferkette

Webseiten laden häufig Skripte, Schriften oder Bibliotheken von Drittanbietern. Jeder zusätzliche Hostname erweitert DNS-, TLS- und Verfügbarkeitsabhängigkeiten. Fällt der Drittanbieter aus oder ändert Inhalte, kann die eigene Seite betroffen sein.

Ein statisches Archiv mit lokalen Ressourcen reduziert diese Kette. Selbst gehostete Dateien sind nicht automatisch sicherer, aber Kontrolle, Archivierung und Reproduzierbarkeit werden einfacher.

Datenschutz beginnt vor dem ersten Seiteninhalt

Bereits DNS-Anfragen können erkennen lassen, welche Domains ein Client auflösen möchte. Beim Verbindungsaufbau entstehen weitere Metadaten, und HTTP-Logs können IP-Adressen, Zeitpunkte und Pfade enthalten. Datenschutz ist deshalb nicht erst eine Frage von Cookies.

DoT, DoH, QNAME-Minimierung und moderne TLS-Mechanismen adressieren unterschiedliche Teile dieser Metadatenkette. Vollständige Unsichtbarkeit gegenüber allen beteiligten Netz- und Dienstkomponenten entsteht dadurch nicht.

Verfügbarkeit – Redundanz nur dort, wo sie wirklich wirkt

Mehrere Nameserver erhöhen DNS-Verfügbarkeit nur, wenn sie nicht denselben Ausfallpunkt teilen. Mehrere Webserver helfen nur, wenn Routing oder Load Balancing sie erreichbar macht. Ein zweiter Server ohne automatischen Umschaltpfad ist zunächst nur eine Reserve.

Für kleine Archive kann einfache, gut gewartete Infrastruktur zuverlässiger sein als komplexe Hochverfügbarkeitsarchitektur. Jede Redundanz benötigt Tests, Synchronisation und dokumentierte Wiederherstellung.

Ablaufdaten überwachen – Domain und Zertifikat

Domainregistrierungen und Zertifikate besitzen unterschiedliche Lebenszyklen. Ein automatisiert erneuertes Zertifikat kann weiterhin funktionieren, obwohl die Domainverlängerung gefährdet ist; umgekehrt kann eine langfristig registrierte Domain mit abgelaufenem Zertifikat HTTPS verlieren.

Monitoring sollte beide Ebenen getrennt beobachten. Besonders wichtig sind Warnungen, die ausreichend früh vor einem kritischen Termin erfolgen und an tatsächlich betreute Kontaktwege gehen.

Änderungen klein halten und rückrollbar machen

DNS- und Hostingänderungen sollten möglichst eine Ebene zur Zeit verändern. Wird gleichzeitig Registrar, Nameserver, Webserver, Zertifikat und URL-Struktur gewechselt, wird Fehlerursachenanalyse unnötig schwer.

Ein dokumentierter Ausgangszustand, kleine Changes und Rückfalloptionen machen Migrationen beherrschbar. Bei statischen Seiten kann eine vollständige Kopie des vorherigen Webroots besonders einfach als Rückrollstand erhalten bleiben.

DNS als Teil des technischen Archivs

Eine historische Website besteht nicht nur aus HTML-Dateien. Welche Domain auf welchen Host zeigte, welche Mail- und Nameserverrollen existierten und welche Redirects aktiv waren, kann für spätere Rekonstruktion wesentlich sein.

Zonenauszüge, Konfigurationsnotizen und datierte Serverstände sollten dabei keine Zugangsdaten enthalten. Ziel ist die dokumentierte technische Topologie, nicht die Archivierung aktiver Geheimnisse.

Webhosting als Zeitgeschichte

Frühe Shell-Accounts, FTP-Verzeichnisse, CGI-Binärpfade und textbasierte Logfiles repräsentieren eine andere Hostingwelt als heutige verwaltete Plattformen, CDNs und automatisierte TLS-Bereitstellung. Beide erfüllen dieselbe Grundaufgabe: einen Namen zuverlässig zu Webinhalten führen.

Gerade diese Kontinuität ist für SSLXY relevant. Die Webspur seit 1996 zeigt, wie sich Transport, Sicherheit und Werkzeuge verändern, während langlebige Pfade, verständliche Dateien und kontrollierte Abhängigkeiten ihren Wert behalten.

sslxy.de – eigenständige Archivdomain und statische Auslieferung

sslxy.de ist als eigenständige Domain das private, nicht-kommerzielle Technik- und Webarchiv. Die aktuelle Website setzt auf statisches HTML, CSS und gezieltes Vanilla JavaScript. DNS, TLS und Webserverkonfiguration bilden dafür die unsichtbare Infrastruktur unterhalb der sichtbaren Dokumente.

Der Name sslxy selbst entstand aus einem technischen String der Jahre 1995/96 im Umfeld eines Shell-Accounts, FTP, CGI und Logdateien. Die Namensgeschichte wird auf der Hauptseite und in den Webvertiefungen dokumentiert; diese Seite konzentriert sich auf die Domain- und Hostingtechnik dahinter.

Langfristige Webpflege – Stabilität vor ständigem Plattformwechsel

Eine über Jahrzehnte gepflegte Website stellt andere Anforderungen als ein kurzfristiger Testauftritt. URLs sollten nicht unnötig brechen, Redirects müssen dauerhaft nachvollziehbar bleiben, Zertifikate und Domains dürfen nicht vergessen werden und Hostingwechsel müssen gewachsene Pfade respektieren.

Statische Dateien erleichtern diese Kontinuität. Ein HTML-Dokument von heute bleibt grundsätzlich direkt lesbar und lässt sich ohne proprietäre Laufzeit archivieren. Infrastrukturmodernisierung kann dadurch unterhalb der Inhalte erfolgen.

Technischer Stand 2026 – DNS und Webtransport

Die Basis des DNS bleibt weiterhin die klassische, verteilte Architektur von DNS-Namensraum, Zonen, Resolvern und Resource Records. Darüber liegen Erweiterungen für Sicherheit und Datenschutz: DNSSEC authentisiert Daten, DoT und DoH schützen Resolvertransporte, QNAME-Minimierung reduziert unnötig offengelegte Namensanteile.

Für Webverbindungen bilden HTTPS, das aktuelle TLS-1.3-Regelwerk, HTTP/2 und HTTP/3 den modernen Transportkontext. SVCB- und HTTPS-Records können zusätzliche Serviceinformationen schon über DNS bereitstellen. RDAP ist der moderne standardisierte Zugang zu Registrierungsdaten.

Typische Missverständnisse

„Die Domain liegt auf dem Server“ ist ungenau: Registrierung, DNS und Hosting sind getrennte Ebenen. „DNS leitet eine URL um“ ist falsch: DNS kennt Hostnamen, keine HTTP-Pfade. „DNSSEC verschlüsselt DNS“ verwechselt Authentisierung mit Vertraulichkeit. „HTTPS bedeutet sichere Website“ verwechselt sicheren Transport mit sicherem Inhalt.

Auch „ein niedriger TTL macht Änderungen sofort“ stimmt nicht, wenn alte höhere TTL-Werte bereits gecacht sind. „www ist Pflicht“ ist ebenso falsch wie „www ist veraltet“. Entscheidend ist konsistente technische Konfiguration.

• Domainregistrierung ist nicht gleich DNS-Hosting.
• DNS-Hosting ist nicht gleich Webhosting.
• DNS kennt keine einzelnen HTML-Pfade.
• TLS-Zertifikate und DNSSEC lösen unterschiedliche Vertrauensprobleme.
• DoH und DoT verschlüsseln Transport zum jeweiligen Resolverendpunkt, nicht automatisch die gesamte Namensauflösung.
• HTTP-Caches und DNS-Caches sind getrennte Systeme.
• Ein 404 ist ein HTTP-Zustand, kein DNS-Fehler.
• Ein CNAME am Zonenapex ist nach klassischem DNS nicht frei mit SOA/NS kombinierbar.

Praxischeck für eine langfristig wartbare Domain

Eine stabile Webdomain entsteht weniger durch exotische Funktionen als durch dokumentierte Zuständigkeiten, vollständige DNS-Daten und kleine kontrollierte Änderungen. Die folgende Checkliste eignet sich für statische Archive ebenso wie für klassische Unternehmenswebsites.

Nicht jede Domain benötigt DNSSEC, CDN, HTTP/3 oder mehrere Hostingstandorte. Jede eingesetzte Schicht sollte einen nachvollziehbaren Nutzen haben und betrieblich gepflegt werden können.

• Registrar und verantwortliches Zugangskonto sind dokumentiert und abgesichert.
• Domainverlängerung und Kontaktwege werden überwacht.
• Autoritative Nameserver und DNS-Provider sind eindeutig bekannt.
• Die vollständige DNS-Zone ist inventarisiert und gesichert.
• A/AAAA, MX, TXT, CAA und Spezialrecords werden nicht bei Webumzügen vergessen.
• DNSSEC wird nur mit dokumentiertem Schlüssel- und Delegationsprozess betrieben.
• Webserver, TLS und HTTP werden getrennt von DNS getestet.
• IPv4 und IPv6 werden jeweils real geprüft, wenn beide veröffentlicht sind.
• Canonical-Host und Redirectstrategie sind eindeutig.
• Eigene 404- und andere Fehlerseiten liefern den korrekten HTTP-Status.
• Webdateien, Serverkonfiguration und DNS-Zustand besitzen getrennte Wiederherstellungswege.
• Änderungen erfolgen möglichst einzeln, dokumentiert und rückrollbar.
• CSP-Hashes werden nur aus der tatsächlich ausgelieferten bytegenauen Enddatei übernommen.

Verwandte Themen im SSLXY-Archiv

Domains, DNS und Hosting sind die Infrastrukturbrücke zwischen Webentwicklung, Serverbetrieb, E-Mail und Sicherheit. Die wichtigsten direkten Vertiefungen liegen auf den folgenden SSLXY-Seiten.