Otto's Technik Blog: Webhosting

Ein typisches Webhosting besteht aus diesen Servicekomponenten :

Domainregistrierung, DNS
Webserver, SSL Zertifikate
Mailserver

Normalerweise befindet sich alles bei einem Provider, die Verwaltung und die Funktionen können sich individuell unterscheiden. Es ist aber auch möglich Services bei einem anderen Provider zu nutzen. Warum sollte man das tun?

Umzug vorbereiten,
Funktionalitäten des Providers testen,
einzelne Services auslagern.

Möglich wird dies durch Manipulation der DNS Einträge.

Allgemeine Annahmen

Der Domainservice liegt bei Provider A, damit man DNS Einträge beim Provider B anlegen kann muss diese Domain dort eigerichtet werden: "ist schon registriert und soll später umgezogen werden"

Scenario 1 - Webserver und Mailserver Provider B

DNS 2 NS Record Einträge zu dem Nameserver bei Provider B

Damit werden alle DNS Einträge bei Provider B administriert, nur die NS Einträge bei Provider A spielen noch eine Rolle. Die Namensauflösung ist quasi komplett auf den anderen Nameserver delegiert.

Geeignet für:

Delegation einer kompletten Subdomain auf einen anderen Host,
Umzug einer kompletten Website,
Vorbereitung Domaintransfer.

Der Umzug der Homepage geht hiermit beinahe unterbrechungsfrei und hat Möglichkeiten zu testen. Der Umzug von Postfächern erfordert immer die Mitarbeit des Users! Achtung: Je nach Aufgabe gelten nur einzelne Schritte:

Domain bei Provider B einrichten,
Inhalt des Web zu Provider B kopieren und Anpassungen (Datenbank, SSL) vornehmen,
Postfächer einrichten,
NS Einträge bei Provider A ändern und testen (Wartezeit)
Wartezeit nutzen um Postfachinhalte zu übertragen (Tools vom Provider oder Mailstore Home),
Homepage testen und eventuell DNS Eintrag auf alten Host ändern,
Postfächer testen,
Bei Umzug den final Domaintransfer vollziehen.

Scenario 2a - Webserver Provider B

DNS Host Record zur Adresse Provider B,
oder CNAME auf DDNS Hostadresse.

Alle DNS Einträge werden beim Provider A administriert, etwaige Einträge beim Provider B spielen keine Rolle. Damit kann man einzelne verteilte Hosts unter einer Stammdomain erreichbar machen. Gut geeignet um die Funktionalität eines Webservice bei Provider B zu testen. Da sich der Nameserver nicht ändert, ist in der Regel keine Wartezeit zwischen der Einrichtung und dem Test nötig, nur lokale Caches müssen berücksichtigt werden.

Provider B kann dabei auch der Host zu Hause sein.

Scenario 2b - Webserver bei Provider B mit Let's Encrypt SSL Zertifikaten

2 NS Record bei Provider A auf die NS bei Provider B setzen,
alle Mail relevanten Records müssen 1:1 von Provider A nach Provider B übertragen werden, siehe auch Scenario 3.

Hierbei werden vom Let's Encrypt Agenten dynamisch DNS Einträge zur Autorisierung erzeugt. Die DNS Verwaltung für den Webservice wird quasi umgekehrt.

Scenario 3 - Mailserver Provider B

MX Record bei Provider A zur Adresse Provider B,
Mail relevante TXT, SRV Records bei Provider A entsprechend Provider B setzen.

Die komplette Einrichtung für eine Mailumgebung ist aufwendiger als für einen Webhost, da zahlreiche Einträge eine Rolle spielen:

MX Records für die Erreichbarkeit des Mailservers.
TXT Records für die Sicherheit (SPF und DKIM)
SRV Records für automatische Konfiguration des Mailclients.

Der Umzug eines Mailhosts geht nicht ohne Einfluss beim Benutzer, da sich in der Regel mindestens die Hostnamen für IMAP und SMTP ändern. SRV Records können die Sache für den Benutzer vereinfachen.