Ich, die Subdomain und mein Freund der 301 :)

[johngrinder]

Hallo,

ich stehe vor einem kniffligen Problem, welches ich aus SEO sicht nicht beantworten kann:
ich habe einen Server mit der Webapplikation, zusätzlich gibts einen Webspace-Account - dieser hat die Aufgabe, für den Fall, dass der eigentliche Server mal down ist, noch eine Seite ala "Aus Wartungsgründen bla...etc.." auszuliefern sowie das Blog (permanent) zu hosten (welches ich v.a. auch im Sinne eines Ausfall als brauchbares Kundeninformationstool ansehe).

Die grundsätzliche Domainstruktur sollte sein:
- normale Page: www.meinedomain.com
- blog: blog.meinedomain.com

Nun weiss ich leider nicht weiter:
ich könnte "www." und "blog." auf dem eigentlich Server auflösen lassen, wobei der DNS "blog." auf den Webspace zeigt (und "www." eben einfach die Applikation bereitstellt) - das hätte allerdings zur Folge, dass im Falle einer Server-Downtime auch "blog." nicht mehr aufgelöst werden kann bzw. erreichbar ist - ausser jemand kennt die IP auswendig

Nun meinte der Provider, man könnte "www." auf dem Webspace belassen und auf die IP des eigentlichen Servers umleiten, wobei der eigentliche "Haupt-"Server dann einen DNS ala "www2." hätte - da aber das Umleiten durch einen HTTP301 geschen würde, sollte das - meinte er - egal sein. Die DNS "blog." wäre in diesem Fall so oder so auf dem Webspace gelagert. Im Falle einer Server-Downtime auf der Hauptmaschine würde das Script auf dem Webspace einfach umschalten und die "Wartungs-Standby-Seite" vom Webspace ausliefern.
Und hier weiss ich nun nicht: ist der 301er in dieser Konstellation schlecht für die die SuchmaschinEN (ich will nicht nur für Google optimieren).

Was wäre denn eine andere/sinnvolle Lösung für das Problem? Ich denke, so eine Problemstellung gibts öfter?

[wolli]

das löst man mit mod rewrite Flag [P]
damit bekommt auch die Suchmaschine nicht mit woher der Content kommt

[johngrinder]

Hi Wolli,

erst mal vielen Dank für den Post!

Glücklicherweise läuft der Webspace auf nem Apache - der Hauptserver ist nämlich ein IIS (heyy, weg mit dem Messer!!! ). Der Provider kann das auf dem Webspace einrichten.

Was mich zu dieser Methode aber generell noch interessieren würde:
a) ist das schon der richtige/optimale Weg, so einen Problemfall zu lösen?
b) der Traffic verdoppelt sich ja dann? Erst mal vom eigetnlichen Haupt-Server zum Webspace und von dort dann ins Netz?
c) Hat das denn irgendwelche Performance-Auswirkungen?


Regards

[Mork vom Ork]

ich habe einen Server mit der Webapplikation, zusätzlich gibts einen Webspace-Account
[…]
- normale Page: www.meinedomain.com
- blog: blog.meinedomain.com
[…]
Glücklicherweise läuft der Webspace auf nem Apache - der Hauptserver ist nämlich ein IIS

Ich sehe das Problem noch nicht so ganz. Wenn du zwei Server hast, hast du auch zwei IPs und kannst diese beiden entsprechend auf www. und blog. aufteilen. Oder habe ich dich deine Darstellung falsch verstanden?

[johngrinder]

Hi Mork,

das Problem ist die Namensauflösung:
blog.meinedomain.com und www.meinedomain.com muss ja aufgelöst werden - hinter dem Domainrecord meinedomain.com kann man nur eine IP hinterlegen.

"blog." und "www." müssen also vom Webserver auf der Maschine/bzw. Webspace aufgelöst werden... (oder kann man Subdomains auch beim Provider/DNS-Root hinterlegen?)

Es geht also darum, welche IP angesteuert wird, wenn a) "www." bzw. "blog." eingegeben wird und b) welcher Content ausgeliefert wird, wenn der eigentliche Haupt-Webserver (der IIS) mal ausfällt.

Habe ich es etwas besser darstellen können?

Regards

[n3m0]

"blog." und "www." müssen also vom Webserver auf der Maschine/bzw. Webspace aufgelöst werden... (oder kann man Subdomains auch beim Provider/DNS-Root hinterlegen?)

Abgesehen davon dass der DNS auf dem Webserver nichts verloren hat, hast Du keinen Backup-DNS?

[johngrinder]

Hi n3m0,

da habe ich mich etwas ungünstig ausgedrückt:
im szenario, dass der eigentliche Hauptwebserver (IIS) für das Weiterleiten des Traffic verantwortlich ist, ist da natürlich kein DNS-System/Server drauf installiert. Der Name wird bei Anfragedort eben nur entweder im Falle von "www." auf der Maschine selbst belassen und verarbeitet (also der Content geliefert) oder im Falle von "blog." auf eine andere IP (den Webspace) weitergeleitet, wobei er im zweiteren Falle als "Proxy" agiert (sozusagen), und den Inhalt vom Webspace abholen und ausliefern würde.
Und das ist eben das Problem: ist der Webserver mal down, kann der auf dem IIS installierte Dienst eben nicht mehr "blog.meinedomain.com" auflösen, was dazu führt dass ein User, der "blog.meinedomain.com" eingibt nicht mal mehr das Blog ansteuern kann...
(Das ganze hat also nichts mit eigenen DNS-Server-Installationen zu tun!)
Ist das so rum verständlich erklärt?
Das ist ja im Endeffekt das generelle Problem: wie wird die IP von "blog.meinedomain.com" aufgelöst, wenn der IIS down ist und der User nicht die IP im Kopf hat? (was er sicherlich nicht hat).
Denn: beim Provider, im "globalen Root-DNS-Record", kann ich ja nur die Domain+TLD eintragen, nicht aber die Subdomains - wäre das möglich, wäre die Lösung natürlich einfach: dann müsste ich einfach im "globalen Root-DNS-Record" einfach nur zwei Subdomains hinterlegen...da das aber nicht geht.

[Mork vom Ork]

das Problem ist die Namensauflösung:
blog.meinedomain.com und www.meinedomain.com muss ja aufgelöst werden - hinter dem Domainrecord meinedomain.com kann man nur eine IP hinterlegen.

Nein. Mal abgesehen davon, dass meinedomain.com gar nicht gefragt ist, sondern www. und blog.meinedomain.com, kann eine Domain auch auf mehrere IPs verweisen. Das wird zum Beispiel für eine einfache Form der Lastverteilung genutzt, hat aber nix mit deiner Frage zu tun.

"blog." und "www." müssen also vom Webserver auf der Maschine/bzw. Webspace aufgelöst werden...

Nein. Mit dem Webserver hat das erstmal überhaupt nichts zu tun, bestenfalls mit dem Server, also der Maschine, aber auch dies nur, wenn auf dieser Maschine neben dem Webserver auch der verantwortliche DNS-Server läuft - das wird jedoch kaum der Fall sein.

(oder kann man Subdomains auch beim Provider/DNS-Root hinterlegen?)

Jein.

Ja insofern, als dass jede Domain einen eigenständigen Datensatz haben kann. y.z kann eine IP haben, x.y.z kann eine andere IP haben, und auch a.y.z und a.b.c.x.y.z kann eine (oder mehrere, siehe oben) eigene IP haben. Verwaltet wird das alles im DNS, nicht im Webserver.

Nein, weil in den Rootservern des DNS nur die Nameserver-IPs der Top-Level-Domains (.de) abgelegt werden. In den TLD-Nameservern, zum Beispiel jenen der DENIC, sind die Nameserver-IPs der Second-Level-Domains (example.de) abgelegt. Und erst ab dieser dritten Nameserver-Ebene, die beim Provider oder Hoster untergebracht ist, werden die Subdomains verwaltet, wobei man das Spielchen auch noch über weitere, tiefere Ebenen treiben kann.

Was du vielleicht durcheinander gebracht hast, ist die Tatsache, dass auch Webserver Domains verwalten. Das passiert allerdings unabhängig vom DNS. Der Verbindungsaufbau geschieht immer über eine IP, dazu muss zuerst die Domain vollständig aufgelöst werden. Und anschließend, nach Verbindungsaufbau übermittelt nochmals der Browser dem Webserver, welche Domain er eigentlich ansprechen wollte.
Auf diese Art und Weise lassen sich unter ein- und derselben IP mehrere (Web-) Domains lagern.

Langer Rede, kurzer Sinn:

wäre die Lösung natürlich einfach: dann müsste ich einfach im "globalen Root-DNS-Record" einfach nur zwei Subdomains hinterlegen...da das aber nicht geht.

Doch, das ist die Lösung für dein Problem. Trage für www.meinedomain.com 1.2.3.4 ein und für blog.meinedomain.com 5.6.7.8.

[johngrinder]

Hi Mork,

bei einigen Sachen habe ich offensichtlich Wörter verwendet, die du/ihr anders interpretiert habt:

Nein. Mal abgesehen davon, dass meinedomain.com gar nicht gefragt ist, sondern www. und blog.meinedomain.com, kann eine Domain auch auf mehrere IPs verweisen. Das wird zum Beispiel für eine einfache Form der Lastverteilung genutzt, hat aber nix mit deiner Frage zu tun.

Vielleicht oute ich mich ja jetzt als Vollnoob (trotz technischer Ausbildung), aber habe das so verstanden:
der User gibt www.domain.com im Browser ein, dann geht die DNS-Anfrage für domain.com so lange "rum" bis zu einem DNS-Server der die Adresse 1.2.3.4 zurückliefert. Dann geht die Anfrage (mit dem Hostheader) weiter an den Server hinter "domain.com" - hier kann es dann sein, dass der Server sagt "die IP für WWW. ist IP 4.5.6.7" oder dass er gleich den Content ausliefert, weil er im Hostheader erkannt hat, dass die Subdomain auf seiner eigenen IP liegt?
Gerade fällt mir ein/auf, worin mein/unser Kommunikationsproblem liegt:
es gibt ja einen Unterschied zwischen Subdomain und Server - "wwwain.com" kann eine Subdomain sein aber auch ein Host, wenn ich nicht irre?

Das wird zum Beispiel für eine einfache Form der Lastverteilung genutzt, hat aber nix mit deiner Frage zu tun.

Hat nichts damit zu tun, aber: wird doch als "Round Robin DNS Load Balancing" bezeichnet?

verantwortliche DNS-Server läuft - das wird jedoch kaum der Fall sein

Nein, das st (natürlich) nicht so.

Doch, das ist die Lösung für dein Problem. Trage für www.meinedomain.com 1.2.3.4 ein und für blog.meinedomain.com 5.6.7.8.

Ok, soweit verstanden.
Dann bleibt nur noch das Problem, wie mache ich das mit dem dynamischen Umschalten, wenn der eigentliche WWW-Server down ist und vom "Backup-WebSpace" eine Achtung-Wartungsarbeiten-Seite ausgeliefert werden soll - wie oben zitiert mit mod/url-Rewrite?

Sorry für meine Fragen, aber das ganze DNS-Zeug ist ja wirklich nicht ganz "inkomplex"

[Mork vom Ork]

der User gibt www.domain.com im Browser ein, dann geht die DNS-Anfrage für domain.com so lange "rum" bis zu einem DNS-Server der die Adresse 1.2.3.4 zurückliefert. Dann geht die Anfrage (mit dem Hostheader) weiter an den Server hinter "domain.com" - hier kann es dann sein, dass der Server sagt "die IP für WWW. ist IP 4.5.6.7" oder dass er gleich den Content ausliefert, weil er im Hostheader erkannt hat, dass die Subdomain auf seiner eigenen IP liegt?

Nein, da geht bei dir einiges völlig verquer.

Auf Eingabe von httр://www.examрle.com/eine/testseite.html wird:

I. DNS-seitig:
Zum Auflösen der Domain www.examрle.com:
1. Ein Root-Nameserver ausgesucht.
2. Der Root-Nameserver nach Nameservern für .com befragt.
3. Der .com-Nameserver nach Nameservern für example.com befragt.
4. Der example.com-Nameserver nach Nameservern für www.examрle.com befragt.
5. Der Nameserver für www.examрle.com nach der IP für www.examрle.com gefragt.

Schritt 4 und 5 werden fast immer in einem Rutsch beantwortet, da es sich um denselben Nameserver handelt. Schritt 1 bis 5 wiederum laufen für den Webbrowser als ein Schritt ab. Er fragt also nach www.examрle.com und bekommt 1.2.3.4, alles andere dazwischen macht das Betriebssystem bzw. das DNS.

II. TCP-seitig:
Der Webbrowser hat jetzt für www.examрle.com die IP 1.2.3.4 und stellt damit eine Verbindung zum Webserver her.

III. HTTP-seitig:
Ist die Verbindung zur IP bzw. zum Webserver hergestellt, schickt der Browser an den Webserver in etwa folgende Zeilen:

GET /eine/testseite.html HTTP/1.0
Host: www.examрle.com

Die Domain wird also zweimal verwendet, und zwar komplett, erst, um die IP herauszufinden, und dann nochmals, um dem Webserver mitzuteilen, welche Domain angesprochen werden soll.
Insbesondere ist der „Hostheader“, den du angesprochen hast, Teil des HTTP-Protokolls und wird erst verwendet, wenn die tatsächliche IP über das DNS ermittelt wurde. Im DNS gibt es diesen Begriff gar nicht. Auch wird nicht erst das DNS nach dem Bruchstück example.com gefragt, um dann per HTTP mit www.examрle.com weiterzumachen.

es gibt ja einen Unterschied zwischen Subdomain und Server - "wwwain.com" kann eine Subdomain sein aber auch ein Host, wenn ich nicht irre?

Nein, das sind zwei verschiedene Begriffe. Eine Subdomain ist einfach jede Domain, die mindestens zwei Punkte enthält, oder der Teil einer Domain, der vor dem zweiten Punkt steht. Ein Host ist ein Computer- oder Softwaresystem, das einen Dienst zur Verfügung stellt; Host und Server lassen sich in gewissen Bereichen gleichsetzen, Subdomain ist aber eine andere Baustelle.
Allerdings hat ein Host bzw. ein Server (fast) immer einen Namen: Die (Sub-) Domain. Deshalb wird auch mal vom Host www.examрle.com gesprochen - genauso wie vom Herrn Müller gesprochen wird, da haben wir den Herrn, den Menschen, und seinen Namen Müller.

Das wird zum Beispiel für eine einfache Form der Lastverteilung genutzt,

Hat nichts damit zu tun, aber: wird doch als "Round Robin DNS Load Balancing" bezeichnet?

So ist es.

Dann bleibt nur noch das Problem, wie mache ich das mit dem dynamischen Umschalten, wenn der eigentliche WWW-Server down ist und vom "Backup-WebSpace" eine Achtung-Wartungsarbeiten-Seite ausgeliefert werden soll - wie oben zitiert mit mod/url-Rewrite?

Nein, wenn der Hauptserver platt ist, kann er auch nicht mehr mittels mod_rewrite Anfragen durchreichen.

Im Katastrophenfall änderst du einfach die IP-Adresse für www.examрle.com in jene des zweiten Rechners, d.h. blog.example.com und www.examрle.com hätten dann die gleiche IP-Adresse. Du musst allerdings zusätzlich dafür sorgen, dass der zweite Webserver mit der Domain www.examрle.com etwas anfangen kann, denn wie oben beschrieben, wird nicht nur das DNS nach der Domain befragt, sondern auch der Webserver.

Erwarte allerdings keine Wunder, so eine Änderung hat sich erst nach ein paar Stunden durch sämtliche Netzcaches gearbeitet. „Mal eben von jetzt auf gleich“ umschalten kann man nur, wenn man die IP-Zuordnung, d.h. das Routing ändert, dem Hauptserver seine IP-Adresse also wegnimmt und dem zweiten Server zuordnet. Diese Möglichkeit wirst du aber höchstwahrscheinlich nicht haben.
Nichtsdestotrotz ist das Ändern des DNS-Eintrags eine praktikable Lösung, um zumindest einen Großteil der Anfragen mit einem Pausenzeichen zu versorgen. Letzten und diesen Herbst war meine Kiste für eine Weile außer Betrieb, ich habe in der Zeit den DNS-Eintrag auf meinen DSL-Internetzugang gelegt und sämtliche Anfragen durch einen rudimentären Webserverdingens mit 503 beantwortet.

[xoni]

@ Mork vom Ork

ich kann zwar nichts zum Posting hier beitragen,
möchte mich aber für die ausführliche Darstellung
bedanken... habe gerade richtig was dazugelernt.

[johngrinder]

Hi Mork,

erst mal vielen Dank für deine ausführliche Erklärung - das war wirklich nötig (zumindest für mich)

Weg. dem Umleitung im Falle einer Downtime. Das ist durch die DNS-Diskussion jetzt bissl untergegangen:
der Vorschlag vom Provider war, dass "www." und "blog." auf den Webspace zeigen, dort aber eine (Permanent-)Weiterleitung auf den eigentlichen Webserver besteht - der Webspace würde also sozusagen als Proxy fungieren, der Traffic geht dabei also vom Webserver immer über den Webspace nach draussen gehen.
Im Falle einer Downtime würde die Proxyfunktionalität den Ausfall erkennen und nicht mehr auf den Webserver weiterleiten, sonder eine einfach HTML-Seite (mit Inhalt ala "Wartungsarbeiten usw.") ausliefern. Das ganze würde also auch ohne "umschreiben" von DNS-Einträgen umgesetzt werden.

Wie ist denn - jetzt mal ohne meine Frage - der "normale" Weg, wie man dieses Problem löst? Einfach zwei Webserver mit Load-Balancer davor?

[Mork vom Ork]

der Vorschlag vom Provider war, dass "www." und "blog." auf den Webspace zeigen, dort aber eine (Permanent-)Weiterleitung auf den eigentlichen Webserver besteht - der Webspace würde also sozusagen als Proxy fungieren, der Traffic geht dabei also vom Webserver immer über den Webspace nach draussen gehen.

Vorweg: Besser nicht Proxy und Weiterleitung in einem Atemzug verwenden. Wenn du von Weiterleitung sprichst, läuft das in der Regel auf die HTTP-Antwort 301 oder 302 hinaus, d.h. der Browser bekommt vom Webserver bei Frage nach A die Antwort, er möge es bitte stattdessen nochmals bei B probieren; der Browser macht entsprechend zwei Anfragen.
Ein Proxy leitet genau genommen durch, nicht weiter, d.h. fragt der Browser nach A, holt der Webserver/Proxy die Daten selbst von B und liefert sie aus; der Browser macht nur eine Anfrage.

Was nun deine Frage angeht: Den Webspace als Proxy einzusetzen geht natürlich auch, das hatte ich gar nicht auf dem Plan. Man könnte zwar argumentieren, dass der Webspace auch ausfallen kann (und dann doch wieder alles am Boden liegt), aber beim fremdverwalteten, allgemeinen Webspace ist das weniger wahrscheinlich als bei einem eigenen Server.
Ein Nachteil bleibt: Die Daten müssen einen längeren Weg nehmen. Wenn da erst großartig übers Internet geroutet werden müsste, sähe ich das kritisch - aber letztlich muss man's einfach ausprobieren.

Was du jedoch nicht machen solltest, und das wäre IIRC der Vorschlag deines Hosters, ist eine HTTP-Weiterleitung einzurichten. Weil die URLs sowohl des Webspace als auch des (vermeintlich) nachgeschalteten Servers dann für den Browser sichtbar sind, läuft das über kurz oder lang in ein heilloses URL-Durcheinander hinaus. Einige werden über die Webspace-URLs kommen, andere direkt über die Server-URLs, du wirst das nicht unter Kontrolle halten können.
Suchmaschinen verwirrst du zudem, und setzt du dann auch noch die dauerhafte Weiterleitung 301 ein, landen nur die Server-URLs in den Ergebnislisten, nicht die Proxy/Webspace-URLs (denn letztere existieren ja angeblich nicht mehr, das ist die Aussage von 301).

Also: Entweder nutzt du auf dem Webspace die in mod_rewrite optional vorhandene Proxy-Funktionalität oder du bastelst dir ein Proxy-Skript (nicht allzu schwer). Oder du lässt es ganz bleiben, weil du mehr Unsicherheiten einbaust als du absicherst.

Wie ist denn - jetzt mal ohne meine Frage - der "normale" Weg, wie man dieses Problem löst? Einfach zwei Webserver mit Load-Balancer davor?

Immer mehrere Webserver, die über irgendeinen Verteiler an die weite Welt angeschlossen sind. Wo der Verteiler nun sitzt, hängt von den Gegebenheiten ab, als sichere Punkte sehe ich nur die HTTP- (Proxy, wie bei dir) und die IP-Ebene (Router, Zuordnung der IP-Adresse), am besten beides.
Man darf nur nicht den Fehler machen, einen zentralen Knoten einzubauen. Wie zum Beispiel oben schon geschrieben ist es grundsätzlich witzlos, zwei Webserver mit einem einzigen Proxy zu betreiben - dann hat man lediglich den Schwachpunkt vom Webserver auf den Proxy verlagert. Aber im Einzelfall kann das natürlich doch noch vorteilhaft sein, wenn, wie auch schon oben geschrieben, eine Komponente (dein Server) wesentlich kritischer ist als der neue Knoten (dein Proxy/Webspace) - Abwägungssache.

[johngrinder]

Hi Mork,

erst noch ein Mal vielen Dank für deine ausführliche Darstellung, damit hast du wohl ne gute Referenz Erklärung für die Zukunft geschaffen

Weg. dem Proxy/Weiterleitung: da habe ich technisch nicht detailiert genug ausgedrückt, sieht man mal wieder, wie wichtig das ist

Bezüglich dem längeren Weg der Daten, wenn ich den Webspace als Proxy verwende: habe schon mit dem Provider gesprochen, der meinte das ist kein Problem, da die beiden RZ's gut angebunden sind (insgesamt geringfügige Verlängerung der Ping-Zeiten um die 10-15ms)

Danke nochmals!