Warum es sinnvoll ist, Domains und Hosting zu trennen

Posted by jonas on Wednesday, November 20, 2013

Kundenbindung

Über Jahre und Jahrzehnte hinweg haben insbesondere Massen-Webhoster den Eindruck entstehen lassen, Domains und Hosting seien untrennbar miteinander verbunden: Wollte man irgendwo einen Webspace haben, brauchte man zwingend eine Domain dafür. Hatte man schon eine, musste man sie zwingend zum Hostingprovider umziehen.

Dahinter steht letztlich nichts anderes als ein Geschäftsmodell, bei dem man gerne auch noch an Domains mitverdienen möchte (weil man sich bei den Preisen für’s Hosting ja schon bis zum Dumping entblößt hat). Rein technisch gesehen haben beide Dinge jedoch ziemlich wenig miteinander zu tun.

Provider

Hostingprovider betreiben Infrastruktur. Sie haben mit Rechenzentren und Serverhardware zu tun; mit Strom und Klimatisierung; mit Traffic und Support.

Domainprovider hingegen sind eher eine Art Reseller unterschiedlichster Registrierungsstellen, oder besser gesagt: deren Aggregatoren, die dafür sorgen, dass man beispielsweise in einem hübschen Webinterface domain.de, domain.at, domain.ch und domain.com in einem Aufwasch bestellen kann und dabei fast der Eindruck entstehen könne, als würde hier letztlich domain.* verkauft, und das sei doch alles ganz einfach.

Top Level Domains

Was immer noch Einigen nicht ganz klar ist: Um .de-Domains anbieten zu können, muss man Mitglied der Genossenschaft DENIC eG werden. Für .at-Domains muss man Partner von nic.at werden; für .ch-Domains von Switch. Generische Top-Level-Domains wiederum bezieht man von der ICANN, die wiederum die Verwaltung für einige Jahre an Unternehmen delegiert, die sich darum bewerben müssen; bei .com-Domains ist das derzeit VeriSign.

Jedes dieser Unternehmen hat seine eigenen Preisstrukturen und Regularien, und jeder, der davon ausgeht, man klickt sich da für die gewünschte Domain einfach ein paar lustige Endungen, unterschätzt den zum Teil absurden Aufwand: .de-Domains haben eine Regionalbindung; man muss selbst in Deutschland leben oder dort einen administrativen Kontakt benennen. Bei .ch- und .at-Domains ist das hingegen nicht so. Möchte man .it-Domains registrieren, verlangt die zuständige Registry die Angabe von Personalausweis- und Steuernummer. Möchte man eine .sg-Domain, werden ein Handelsregisterauszug oder eine Personalausweiskopie fällig. Bei .ni-Domains kann man sich auf eine sechswöchige Registrierungsdauer einstellen. Oder vielleicht Interesse an .tm-Domains? Hier gelten zehn Jahre Mindestregistrierungsdauer, für die man direkt roundabout einen Tausender hinlegen darf. Für die Registrierung einer .ie-Domain hingegen müssen Handelsbeziehungen mit Irland nachgewiesen werden. Die unter anderem für Domainhacks beliebte TLD .us setzt voraus, dass die Nameserver physikalisch in den USA stehen müssen. In Norwegen wacht Norid darüber, dass Unternehmen maximal 100 Domains auf ihren Namen registrieren; bis 2011 war die Zahl sogar auf 15 begrenzt, und davor wiederum - noch bis 2001 - auf … eine.

Privatpersonen dürfen überhaupt erst seit 2011 .no-Domains registrieren, und das auch nur unter .priv.no. Und so weiter, und so weiter - und damit ist noch nichts über die komplexen Abrechnungsmechanismen, Domains mit oder ohne Laufzeitübernahme bei Providerwechsel, Whois Privacy, optionale oder obligatorische Treuhandservices, zusätzlichen Kosten für vorzeitige Löschungen oder auch nur für Inhaberwechsel gesagt. Die einen Registries wollen am liebsten die Domaininhaber in spe direkt bedienen und sträuben sich gegen Reselling-Bestrebungen. Die anderen Registries wie die DENIC scheuen Endkunden wie der Teufel das Weihwasser; wer Domains nicht über ein Genossenschaftsmitglied, sondern direkt bei der DENIC beziehen will, darf sich über bizarr hohe Kosten freuen.

Automatisierung

Mit anderen Worten: Dass man in irgendeinem Domainrobot für eine Wunschdomain ein paar TLDs ankreuzen kann und dann werden die „einfach so“ registriert und dann funktioniert das - das alles ist von Magie nicht allzu weit entfernt, und wir zollen jedem Domainregistrar, der dieses Kunststück fertigbringt, unseren tiefsten Respekt.

Für diese Art von Baustelle braucht es Profis, und was Domains angeht, sind wir das schlicht und einfach nicht. Wir sind selbst kein Domainregistrar, sind also bei keiner Registry direkt akkreditiert, sondern kaufen schlicht Domains unter einigen wenigen TLDs (die, bei denen sich die Kosten und der Beschaffungs-/Transferaufwand in Grenzen hält) bei zwei Registraren ein, InterNetX und http.net. Wir haben keinen eigenen Domainrobot entwickelt, weil sich der enorme Aufwand dafür - man muss sich ja nur mal vor Augen führen, dass die ganzen Abrechnungsmodelle und TLD-spezifischen Sonderregelungen ja letztlich auch in Algorithmen abgebildet werden müssen - für uns auch nicht rechnet, denn, und das mag für viele eine Überraschung sein: An Domains verdienen wir praktisch nichts außer ein paar Rundungs-Cents. (Naja, nicht ganz. An .de-Domains verdienen wir ein bisschen was, aber das geht dafür drauf, dass wir bei .com/.net/.org zwecks eines einheitlich eingeführten Preises drauflegen - dem schwankenden Dollarkurs und Verisigns laufenden Preiserhöhungen sei Dank.) Im Moment heißt jede Domainregistrierung für uns, per Hand im Webinterface eines der beiden Registrare herumzuklicken, was uns offengesagt zunehmend mehr davon abhält, echte Arbeit zu erledigen: Die Server am Laufen halten. Uns weiterentwickeln. Support, wissenschon.

Aber zurück zur Technik - was ist eine Domain letztlich denn mehr als ein simpler Datenbankeintrag bei irgendeiner Registry, deren verwaltungstechnisches Handling dann ein Registrar für einen übernimmt? Mal ganz ketzerisch gesagt: Wenn man mit seiner Domain umzieht, dann doch in aller Regel nicht, weil man mit dem Domainhandling, sondern weil man mit dem Hosting unzufrieden ist - entweder aufgrund von Ärgernissen wie einer lahmenden oder oft ausfallenden Website bis hin zu Support, der zu Fremdschämen anregt, oder umgekehrt vielleicht auch aufgrund eines guten geschäftlichen Händchens, das für ein Wachstum sorgt, bei dem man aus einem Webspace schlicht herauswächst und die Evolution über virtuelle Server, dedizierte Server, Cluster oder irgendwas Wolkiges durchläuft. Und dann das:

Umzug

Immer, immer, immer müssen die Domains mitziehen, und das heißt: AuthCodes generieren - bei den TLDs, die mit AuthCodes arbeiten. Oder Formulare ausfüllen. Oder beides. Domains unlocken. Whois-Privacy entfernen, damit die IRTP-Mail verschickt werden kann. Ach, da steht ja noch eine alte Mailadresse im Whois, die gar nicht mehr gilt. Also erst noch ein Domainupdate machen, und dann. Finanzielle Verluste wegen Wegfall von Restlaufzeiten. Zulange gewartet und bei .de-Domains ist der AuthInfo-Code dann schon wieder abgelaufen. Ganz vergessen, dass man Domains unter generischen TLDs 60 Tage nach Registrierung oder Umzug überhaupt nicht umziehen kann, und wenn man sich auf den Kopf stellt. Und so weiter, und so weiter.

Wer hingegen hat jemals den Hostingprovider gewechselt, weil er mit dem Domainhandling unzufrieden gewesen wäre? Eben: Niemand. Zumindest wenn wir mal die paar armen Seelen ausnehmen, die bei einem jener Bizarro-Provider Opfer^WKunde sind, die die Anzahl im DNS anlegbarer Subdomains arbiträr auf „zehn“ begrenzen (dann braucht man einen teureren Tarif) oder schon gleich überhaupt keine Änderungen von DNS-Einstellungen erlauben.

Aus dieser ganzen Situation kann man natürlich viele Schlüsse ziehen. Wir könnten halt eben doch unseren eigenen Domainrobot basteln, von dem unwahrscheinlich wäre, dass sich der Aufwand jemals rechnen würde. Aber das ließe sich ja kompensieren, in dem wir die Domains teurer machen. Wenn wir das allerdings tun, könnten wir auch direkt bei der (damit dann auch entsprechend entlohnten) Handarbeit bleiben, die wir jetzt schon machen und die, nebenbei gesagt, für eine ausgesprochen gute Qualität der Whois-Daten sorgt, weil wir hier dann on the fly Fehler korrigieren, Daten harmonisieren, ein Auge auf „Bist du vielleicht umgezogen; sollten wir diese und jene Domain nicht vielleicht auch anpassen?“ halten, und die auch schon die eine oder andere Fehl-Registrierung aufgrund einer simplen „Ist das vielleicht ein Tippfehler; diesen Begriff schreibt man doch eigentlich so und so“-Rückfrage vermieden haben.

Arbeitsteilung

Wenn wir aber nun in uns gehen, die betriebswirtschaftlichen Aspekte den Leuten überlassen, die an sowas Spaß haben, und die Angelegenheit unter dem Aspekt betrachten, wie die Welt aus unserer Sicht nun mal am ehesten laufen sollte, dann läuft für uns am Ende alles auf dieses Szenario raus:

  1. Du orderst eine Domain direkt bei einem Domainregistrar deines Vertrauens.
  2. Dort bleibt die Domain, und zwar bis zum Sankt-Nimmerleins-Tag.
  3. Du hostest, wo immer du willst, und lässt beim Domainregistrar einfach die DNS-Einträge auf die IPs des Hosters deiner Wahl verweisen. (Vielleicht sind das ja wir. *hust*)

Wechselst du den Hoster, machst du einfach Schritt 3 nochmal, dann eben mit anderen IPs.

Der einzige Nachteil dabei ist: Wenn du einmal verstanden hast, wie bekloppt und aufwendig und teuer und fehlerträchtig es ist, seine Domains immer und immer wieder umzuziehen, bist du vermutlich ein für allemal für alle Hoster verloren, die dich zwingen wollen, deine Domains auch zu ihnen umzuziehen, weil du dich von denen erpresst fühlst.

Aber das ist dann eben so, und es ist ja nicht so, dass es auf dem Hostingmarkt an Alternativen mangeln würde, die dir entsprechende Freiheiten einfach lassen - und damit meinen wir ganz explizit nicht nur uns. Und solltest du trotzdem zu einem Anbieter wechseln, der Hosting und Domains nur strikt verheiratet anbietet: Dann steht dir das ja immer noch frei. Von einem eigenständigen Domainregistrar kannst du ja schließlich genauso jederzeit umziehen wie von einem Hoster.

Domains bei Uberspace

Lange Rede, kurzer Sinn: Domains sind nicht unser Ding. Sie waren es nie wirklich.