Wohnzimmerhostblogger

Ich hab einen Kunden, der hostet einige seiner Seiten auch woanders - sein gutes Recht. Aus purem Interesse surfe ich einigen Kunden schon mal hinterher und schau mir ihre Seiten an (ganz legitim, sofern die Adressen öffentlich zugänglich sind).

Heute morgen hat eine seiner Seite nicht getan. Wollte nicht. Der Webserver war einfach unten - also nicht die Maschine, sondern die Software Als Aufmerksamer Surfer habe ich ihm das natürlich per Mail erzählt und gerade eben Antwort bekommen:

Die Webseiten sind wohl vor kurzer Zeit umgezogen, auf einen anderen Server bei seinem Provider. Nur mit dem feinen Unterschied, dass er die Domains wiederum woanders eingekauft hat und vergessen hat die DNS-Einträge ändern zu lassen.

Da frage ich mich doch, ob es sinnvoll ist, sich die Leistungen gestreut einzukaufen. Ich weiß nichtmals, ob er dabei Geld spart... Die Qualität scheint mir jedoch etwas drunter zu leiden :hmm:

Nur damit keine Missverständnisse auftreten: Ich hab ihm gleichsam verboten die Seite zu mir umzuziehen - nur damit nicht der Anschein entsteht ich würde versuchen wollen ihn abzuwerben, dem war nämlich ganz und gar nicht so!

Oder auch "Das ist Paranoid!" "Das ist eine Killer-Apllikation" "Ausgeklappt ist das Formular der Overkill" - allesamt Reaktionen von Kunden die gestern im Kundeninterface das neue Formular zum ändern der Passwörter für einen Benutzeraccount gefunden haben.

Nunja... Manchmal mag es gefährlich sein, wenn man für mehrere Dienste das selbe Passwort verwendet, praktisch ist es aber allemal - und mit dem Sicherheitswahn kann man es auch ein wenig übertreiben. Im Kundeninterface habe ich nun versucht ein gesundes Mittelmaß zu finden: Öffnet man das Formular zur Passwortänderung, präsentieren sich einem drei zusammengeklappte Passwortgruppen wo der eilige Benutzer mal eben schnell zwischen einem und drei neuen Passwörtern eintippen kann. Die dürfen gleich sein, müssen sie aber nicht.

Das ist aber noch nicht alles! Denn was wären zusammengeklappte Gruppen, könnte man sie nicht ausklappen. Klappt man also alle Gruppen genüßlich aus, kommen insgesamt 15 verschiedene Passwortfelder zu Tage bei denen man wirklich für jeden Dreck irgendein Passwort eintragen kann.

Sicher: Auch hier mag es wieder übertrieben und vollkommen unnötig zu sein, aber es ist schön die Möglichkeit zu haben. Es sagt ja niemand, dass man die Gruppen ausklappen muss

Gestern morgen meldete sich ein Kunde bei mir und meinte, dass eine Weiterleitung nicht funktioniert. Sicherlich, diese Aussage war nicht ganz richtig, denn die Weiterleitung funktioniert nur teilweise nicht. Und eben dieses Teilweise hängt sehr stark vom Absender der E-Mail ab.

Nach ein wenig Recherche habe ich nun SPF in Verdacht schuld an der ganzen Sache zu sein, denn es scheint, dass es immer dann schief geht, sobal die Mail an die Weiterleitung von einer Domain kommt die auch einen SPF-Datensatz beherbergt.

Nachgeprüft habe ich es noch nicht, aber ich denke, dass mein Mailserver, sofern er eine Mail weiterleitet ein "MAIL FROM: absender@domain.tld" sendet und - sofern der empfangende Mailserver SPF-Checks macht - die Mail zurückweist, da mein Server z.B. keine Absender @gmx.de versenden darf.

Bleiben nun zwei Fragen: Wer sollte vorrang haben - Schutz gegen Spam und Absenderfäschung (SPF) oder die Weiterleitungen? Ich bin da ja eher für ersteres zumal ich für zweiteres schon einen Plan aushäcke, der sich auch just auf die Zweite Frage bezieht: Wie lösen wir das Problem?

Wäre es nicht sinnvoll bzw. in Anbetracht der Tatsachen angemessen beim Weiterleiten einer E-Mail ein "MAIL FROM: alias@weiterleitung.tld" (also die Adresse der Weiterleitung) zu senden anstatt des ursprünglichen "MAIL FROM: absender@domain.tld". Solange kein Bounce entsteht, funktioniert das eigentlich recht gut und ist auch Nachvollziehbar. Aber was, wenn doch ein Bounce entsteht? Wäre dann sowas wie "MAIL FROM: postmaster@anderedomain.tld" sinnvoll um die Bounces abzufangen?

Ehrlich gesagt: Die perfekte Lösung scheint es nicht zu geben oder ich habe sie noch nicht gefunden. Ich frage mich, ob da jemand dran gedacht hat, als SPF geschaffen worden ist.

Und was erzähl ich nun dem Kunden?
Eine Weiterleitung, die nur partiell funktioniert, ist wohl nicht gerade etwas, was man gerne im Portfolio hat...

Lieber Blogleser, bitte notieren sie sich schon mal folgendes in Ihrem Terminkalender:

Irgendwann im September 2006: Der Wohnzimmerhostblogger fährt in den Urlaub, vermutlich in die benachbarte Schweiz.

Gestern, am Montag, dem 26. Juni 2006, war es endlich so weit: Die 10 Millionste .de-Domain ist registriert worden!

Damit sichert die TLD weiter ihren 2. Platz auf der internationalen Rangliste der Domains und verkürzt den Weg zu ihrem Vordermann auf ca. 43 Millionen Domains

Schade nur - aber abzusehen - dass die Ehre die 10 Millionen vollzumachen einem der Riesen (wenn auch nicht so offensiv operierenden) der Branche vergönnt war: Der Telekom höchstpersönlich.

Leider habe ich zu denen rein gar kein Kontakt - zumindest nicht, was das Internet-Geschäft angeht - sonst würde ich sicherlich eine Flasche Sekt springen lassen

Ich habe heute ca. 2 Stunden meines kostbaren Morgens einem Kunden gewidmet. Wohlgemerkt einem Neukunden, der seine zwei Domains zu mir umziehen wollte. Da es sich hierbei um einen geschäftlichen Kunden handelt, war natürlich oberstes Gebot, dass alles so gut wie möglich funktioniert und so gut wie kein Ausfall besteht. Von daher habe ich folgendes vorgesehen und auch umgesetzt:

1. Der Webserver wird schon vor dem Transfer konfiguriert und der Content wird von der alten Maschine umgezogen
2. Selbiges gilt für den Mailserver, nur dass dieser zusätzlich eventuell ab morgen mittag alle Mails, die ggf. noch auf dem alten Mailserver liegen abholt und in die neuen Mailboxen einsortiert.

Der springende Vorteil hierbei war sicherlich, dass die Webseite keine dynamischen Inhalte hat, die auf eine Datenbank oder das Dateisystem des Webservers angewiesen sind (aber auch hier hätte ich eine Lösung parat) sodass die IP hinter der Domain eigentlich egal ist, solange beide Webserver noch die selbe Seite parat haben. Der Kunde kann weiterhin auch schon bedenkenlos seine (unzähligen) Mailkonten auf meinen Server umstellen, da ich die Mails freundlicherweise für ihn abholen kann, sodass eigentlich keine Mail verloren geht, sondern lediglich eine Verzögerung von ca. 5 Minuten bekommt.

Darüber hinaus überarbeite ich gerade meine Authentifizierungsmodule, sodass rein theoretisch eine Anmeldung mit den alten Benutzernamen möglich wird. Für den aktuellen Fall wird das (sofern ich den NSS-Part nicht heute fertig und produktiv bekomme) leider zu spät sein, allerdings ist es schön die Option für die Zukunft zu haben.

In einem recht jungen Weblog eines Kunden habe ich gerade eine interessante Story gefunden:

Domain-Grabbing unter Bloggern!

Der Matthias hat sich die Domain von Timo geklaut und das anscheinend nur, weil der Provider von Timo ein wenig länger für die Bereitstellung der Domain gebraucht hat.

Ich finde das - besonders unter Bloggern - ein wenig unfair, zumal ich wohl die beiden viel zu wenig kenne, als das ich wissen würde, was genau der Matthias mit der Domain von Herrn Timo machen wollen würde... Immerhin scheint man drüber reden zu wollen.

Bis es soweit ist, schließe ich mich doch Herrn Timo an!

Nachdem die DeNIC ein wenig rumgesponnen hat und ich zeitweilig das ganze als eine Art Glücksspiel gesehen habe, habe ich heute eine Mail von der DeNIC bekommen, in der sie mir eine Ticket-ID für die letzte Woche an die DeNIC verschickte Mail mitgeteilt haben und (automatisch) versprachen, dass sich in Kürze jemand meinem Problem annehmen würde.

Ob das jemand getan hat - ich weiß es nicht. Jedenfalls habe ich ca. 10 Minuten nach dem Erhalt dieser Mail aus purem Spass noch einmal den Zonecheck ausgeführt und siehe da: Es funktionierte!!!

Daraufhin habe ich sofort ein Modify auf der Domain ausgeführt und versucht meine Nameserver in der Domain einzutragen. Beim ersten Versuch wollte das nicht so recht funktionieren, beim zweiten Mal hats dann aber getan. Immerhin... 5 Tage sind für diesen Vorgang verstrichen. Sowas wird nur von dem Transfer einer com/net/org-Domain getoppt. Ich glaube ich werde mich in der Rechnung für den Kunden ein wenig erkenntlich zeigen.

Ich bin es leid... Sooo leid, ja sooo leid...

[Mon Jun 26 11:12:54 2006] [info] [client 210.xxx.xxx.148] (104)Connection reset by peer: core_output_filter: writing data to the network
[Mon Jun 26 11:12:54 2006] [info] [client 210.xxx.xxx.148] (32)Broken pipe: core_output_filter: writing data to the network
[Mon Jun 26 11:13:11 2006] [info] [client 210.xxx.xxx.148] (104)Connection reset by peer: core_output_filter: writing data to the network
[Mon Jun 26 11:13:11 2006] [info] [client 210.xxx.xxx.148] (32)Broken pipe: core_output_filter: writing data to the network
[Mon Jun 26 11:13:16 2006] [info] [client 172.xxx.xxx.53] (104)Connection reset by peer: core_output_filter: writing data to the network
[Mon Jun 26 11:13:17 2006] [info] [client 172.xxx.xxx.53] (32)Broken pipe: core_output_filter: writing data to the network
[Mon Jun 26 11:13:19 2006] [info] [client 172.xxx.xxx.53] (104)Connection reset by peer: core_output_filter: writing data to the network
[Mon Jun 26 11:13:19 2006] [info] [client 172.xxx.xxx.53] (32)Broken pipe: core_output_filter: writing data to the network
[Mon Jun 26 11:13:20 2006] [info] [client 172.xxx.xxx.53] (104)Connection reset by peer: core_output_filter: writing data to the network
[Mon Jun 26 11:13:20 2006] [info] [client 172.xxx.xxx.53] (32)Broken pipe: core_output_filter: writing data to the network

Selbe Server wie gestern, nur ein anderes Problem. Nach den ersten Analysen des Problems scheint es nicht an den Maschinen selbst, sondern frühestens an dem ersten Punkt der Übergabe zu meinem dortigen Hoster zu liegen.

Irgendwie ist mir das ein wenig zu viel an Fehlern, zumal ich mich da ohnehin nicht wohl gefühlt habe - wäre es so gewesen, würde ich den Fehler auch verkraften. Ich denke ich werd den bestehenden Vertrag einfach auslaufen lassen und dann die Maschinen da weg holen - das wird zwar (nett gesagt) ein Haufen Arbeit, aber wenn es der Sicherung meiner Service-Qualität gilt, eine Hürde, die ich wohl nehmen muss.

Mit ASCII fing das Problem an, mit ISO-8859-X wurde es temporär gelöst, UTF-8 räumt vorerst mit allem auf - sofern wir nicht demnächst auf extra-terrestrisches Leben treffen, das gerne bereit ist mit uns zu kommunizieren (anstatt uns auszulöschen) und wir deren Zeichensatz auch noch unterstützen müssen.

Doch hat sich UTF-8 noch lange nicht als Standard durchgesetzt und somit gibt es schon mal gerne einen Zeichensalat - so passiert ist es mir gestern Abend - Mit MySQL. Ich sehe mich schon irgendwo ein wenig als Vorreiter in Sachen UTF-8, denn meine Webserver laufen schon lange auf diesem Zeichensatz. Meine neueren Datenbank-Server tun dies ebenfalls und bisher dachte ich, würde es da mit der Migration keine Probleme geben, dank individueller Festlegung der Kodierung für jede Tabelle. Doch Trugschluss!

Es kommt nicht nur auf den Zeichensatz der Tabelle an, nein, bei MySQL gibt es an anderer Stelle noch viele weitere Punkte, bei denen man auf die richtigen Angaben achten muss. So werden die Daten z.B. für die Kommunikation mit dem Client nochmal extra kodiert. Sollte man nun also von einem MySQL-Server der latin1 sprach auf einen der utf8 spricht wechseln, sollte man entweder für den gesamten Datenbankserver den Zeichensatz für Client-Verbindungen auf latin1 zurücksetzen, oder dies pro Verbindung tun:

SET character_set_client=latin1;
SET character_set_connection=latin1;
SET character_set_results=latin1;

... so sollten auch in Zukunft "alte" Anwendungen mit der neuen Datenbank laufen, während neue Anwendungen sich gleich schon mal an UTF-8 gewöhnen können.

... wurde wohl ein Router zwischen meinen Servern in Düsseldorf und der T-Com.

Von daher kann es bei einigen Präsenzen wohl noch ein weilchen zu einer Unerreichbarkeit kommen - allerdings nicht für die gesamte Welt da draußen, sondern nur für einen ausgewählten Kreis von Internetnutzern.

Laut Lamdanet hat irgendwer bei der T-Com es verschlafen die Route zu ändern... Ich hab wohl schon oft genug erwähnt, dass das die Kategorie von Störungen ist, die ich nicht ausstehen kann, denn bei denen bin ich gänzlich Machtlos - mehr als Meckern kann ich nicht, und da bin ich auch noch recht schlecht drin

Froh sein kann ich wohl, dass bisher nur eine einzige Störungsmeldung von einem Kunden herein gekommen ist. Hier hab ich mich flexibel gezeigt und seine Präsenzen einfach mal ganz spontan auf einen anderen Server in einem anderen Rechenzentrum umgezogen... Ist halt doof, dass das mit dem DNS da zu verzögrungen kommt, aber so kann er wenigstens bald gut weiterarbeiten. Auch wenn ich traurigerweise ne Menge Arbeit hatte ihn von dem Hintergrund der Störung zu überzeugen

Hereinspaziert, hereinspaziert!
Meine Damen und Herren, treten sie ruhig näher und bestaunen Sie die DeNIC-Slotmaschine!

Dieses unglaubliche wunderwerk der Technik wird alles bisher dagewesene in den Schatten stellen und ihnen den Atem rauben! Einfach unsagbar: Aus bestehenden (wahrscheinlich) 100% richtigen Datensätzen geht die DeNIC-Maschine hin und zerstückelt und verfälscht sie. Aus diesem neuen Datensalat wird willkürlich ein Ergebnis generiert:

Das Zonenproblem besteht immernoch, nach fast zwei Tagen. Auf meine Mail hat noch niemand reagiert - aber es ist ja auch Wochenende und Deutschland spielt. Komisch nur das dies nicht die einzige .de-Domain in dieser Zeit war und alle auf die selbe Art und Weise registriert wurden... Was ist da also los? :hmm:

Gestern Abend hat ein Kunde bei mir noch eine Domain bestellt. Was dann passiert ist eigentlich immer das selbse:

1. Ich starte einen Domain-Request
2. Meine Nameserver werden für die Domain konfiguriert
1. Zone (SOA) wird angelegt
2. Meine 3 Nameserver werden eingetragen
3. Je nachdem ob die Domain bereits existiert wird ein Transfer gestartet oder die Domain wird bei der Registry neu registriert

Der Vorgang ist immer der selbe und hat sich schon seit Monaten nicht verändert.

Nun ist die DeNIC etwas strenger, was die Registrierung/Modifizierung von .de-Domains angeht und checkt vorher die delegierten Nameserver durch, ob sie auch allen Anforderungen entsprechen. Sollten sie es nicht tun, wird zumindest die Modifizierung der Domain zurückgewiesen (im Falle einer Registrierung dümpelt die Domain dann ohne Nameserver durchs Internet).

So geschehen gestern Abend.

Die DeNIC meinte zuerst, dass mein ns3 keinen SOA-Eintrag für diese Zone habe, eine Stunde später hatte auf einmal keiner meiner 3 Nameserver einen SOA und heute morgen war es angeblich ns1 der die Zone nicht kannte.

Ich habe das natürlich sofort überprüft indem ich zum einen die Datenbestände gesichtet habe und auch die Nameserver manuell abgefragt habe. Alle Daten waren korrekt und den Richtlinien der DeNIC entsprechend.

In meiner Verzweifelung habe ich die Nameserver in den Debug-Modus geschaltet, wo wirklich jede Anfrage in einem Protokoll vermerkt wird. Und siehe da: Ich konnte so viele Modify's machen wie ich wollte - die DeNIC hat eigentlich nur die MXes abgefragt, aber eine SOAs oder NSes...

Die spinnt die DeNIC...

Update: Jetzt kennen wieder angeblich alle 3 Nameserver die Zone nicht *kopfschüttel*

Heute Morgen hat mich die Keule des Markenrechts nur knapp verfehlt...

Ich bin recht froh, dass es nun so ausgegangen ist, zumal ich - aus leichtsinn *grml* - total im Unrecht war

Wenn jemand mehrere (n) Domains Domains bei mir beziehen will oder ein Reseller ist (und das nachweislich), gebe ich schon mal gerne ein paar Rabatte auf die normalen Preise. Ist klar... Wenn man eine Menge Domains verkauft und wegen Rabatt weniger Gewinn macht, macht man immernoch mehr Gewinn, als wenn man keine Domain verkauft

Jetzt habe ich vor ca. einer Woche ein Angebot für einen Interessenten geschrieben, der mir was von n Domains erzählte und gerne einen guten Preis von mir wollte. Dem habe ich ihm auch gemacht, sodass ich gestern Nacht eine Mail von ihm in meiner Box hatte. Er hat sich also für mich entschieden. Leider will er nun doch nur mit ca. n / 2 Domains zu mir umziehen, was eigentlich den Preis (der ohnehin schon großzügig war) nicht mehr rechtfertigt. Da ich gestern Abend aber mal gut drauf und ohnehin schon müde war, habe ich einfach mal diskussionslos nachgegeben und ihm den selben Preis gewährt. Was nicht ist kann ja noch werden!