Archiv der Kategorie: Internet

Drosselgeiseln der Telekom

Nachdem seit dem 22. April 2013 offiziell ist, dass die Telekom bei Ihren Call & Surf und Entertain Tarifen die Übertragungsgeschwindigkeit ab einem bestimmten Volumen auf nur noch 384 KBit/s drosseln möchte, hat man versucht das losgetretene PR-Desaster wieder abzumildern und dabei ein paar interessante Zahlen genannt, mit denen ich im folgenden etwas rechnen möchte. Zuerst eine Zusammenfassung der von der Telekom auf verschiedensten Wegen mitgeteilten Zahlen:

  • Es sollen 8 Milliarden Euro in den Netzausbau investiert werden, deswegen muss man Intensivnutzer stärker zur Kasse bitten.
  • Die Drosselung wird frühestens ab 2016 technisch umgesetzt werden, bis dahin rechne man mit 4mal so viel Datenaufkommen wie bisher.
  • Es wird im kleinsten Tarif ab 75 GB monatlichem Traffic gedrosselt werden.
  • Nur 3% der Breitbandkunden seien von der Drosselung betroffen, diese würden aber etwa 30% des Datenaufkommens generieren.
  • Der durchschnittliche Breitbandkunde generiert derzeit 15 bis 20 GB Datenaufkommen im Monat.
  • Auch 2016 soll es noch echte Flatrates geben, die dann aber 10 bis 20 EUR mehr kosten würden.
  • Die Telekom hat derzeit 12 Millionen Breitbandkunden.

Wenn wir nun ein bisschen mit diesen Zahlen rechnen fallen ein paar Diskrepanzen auf.

„8 Milliarden für den Netzausbau“

Wenn von 12 Millionen Breitbandkunden nur 3% einen Aufpreis von 20 EUR im Monat zahlen müssen, dann sind das im Jahr Mehreinnahmen von 43,2 bis 86,4 Millionen Euro pro Jahr. Der angedachte Netzausbau wäre daher erst nach 92 Jahren finanziert. D.h. die Behauptung, man müsse den Schritt gehen um den Netzausbau zu finanzieren, ist falsch.

„Alternative wäre Preiserhöhung für Alle gewesen“

Wenn von 12 Millionen Breitbandkunden nur 3% einen Aufpreis von 20 EUR im Monat zahlen müssen, dann entspräche dies einer allgemeinen Preiserhöhung von 60 Cent für Alle. Stattdessen könnte man auch Rabattaktionen für Neukunden oder Onlinebesteller abschaffen und hätte sich die negative Publicity erspart.

„Nur 3% der Kunden sind betroffen“

Wenn der Durchschnittskunde derzeit 15 bis 20 GB pro Monat generiert und sich das Datenaufkommen bis 2016 vervierfachen soll, dann generiert der Durchschnittskunde 2016 bereits 60 bis 80 GB pro Monat. Entweder sind also mit technischer Einführung der Drosselung 2016 bereits weitaus mehr Kunden betroffen als man heute behauptet oder aber irgendeine der Zahlen ist falsch.

Woher kommen diese Diskrepanzen?

Spätestens nach der Lektüre der beiden Heise-Artikel „Der stille Machtkampf“ (c’t 24/09) und „Schmalspur“ (c’t 08/11), die sich beide beinahe wie das Drehbuch zu den aktuellen Aktionen der Telekom lesen, drängt sich der Verdacht auf, dass man mit der angedrohten Drosselung eigentlich ein ganz anderes Ziel anstrebt und daher Zahlen gewählt hat, welche die breite Masse in Scheinsicherheit wiegen soll.

Man möchte die eigenen Breitbandkunden als „Drosselgeiseln“ missbrauchen, um damit große und erfolgreiche Content-Anbieter (z.B. YouTube) an den Verhandlungstisch zu zwingen. Diese sollen zukünftig für den zum Kunden transportierten Traffic bezahlen und sich somit von der Drosselung freikaufen (Stichwort „managed Services“, die die Telekom den Content-Anbietern zur Verfügung stellen will).

Das Internet, würde somit zu einer Ansammlung von „managed Services“ degenerieren, über die dann aber die Telekom und der Content-Anbieter gemeinsam volle Kontrolle hätten. Kleine Startups mit innovativen Ideen hätten kaum eine Chance, sich gegen die bestehenden Platzhirsche zu bewähren, weil die Einstiegshürden in die „managed Services“ zu hoch wären. Private Content-Anbieter (Blogger oder auch ganz normale Homepage-Betreiber) wären möglicherweise nur noch über eine „Kriechspur“ erreichbar. Das Internet, wie wir es heute kennen, würde nicht mehr länger existieren.

Nachtrag vom 06.06.2013:

Laut einem Artikel in der Welt vom 31.05.2013 gab die Telekom gegenüber des Bundesnetzagentur nun erstmals konkrete Zahlen heraus. Der Interessierte Leser kann obige Rechnungen ja mit den angepassten Zahlen nochmal selbst durchrechnen. 😉 An der löchrigen Argumentation ändern diese allerdings nichts.

Statt *.dip.t-dialin.net jetzt *.dip(0|1).t-ipconnect.de

Seit den guten alten T-Online-Zeiten war man es als T-Online-, T-Home- und Telekom-Zugangskunde gewohnt, dass der Reverse-DNS-Eintrag zur zugeteilten IPv4-Adresse dem Muster *.dip.t-dialin.net entsprach. Kunden von Telekom-Resellern (z.B. 1&1 je nach Anschluss) sowie von Telekom-Business-Zugängen hingegen hatten IPv4-Adressen nach dem Muster *.dip(0|1).t-ipconnect.de.

Seit dem 19. April 2013 (zumindest sehe ich in den Logs „meiner“ Server bis 18. April 2013 noch Zugriffe von *.dip.t-dialin.net) ist das nun anders, nun haben auch die direkten Telekom-Privatzugänge Reverse-DNS-Adressen aus *.dip(0|1).t-ipconnect.de.

Was ist daran nun bloggenswert? Die Telekom scheut unnötigen Aufwand wie der Teufel das Weihwasser (siehe den Mini-IPv6-Rollout für All-IP-Neuverträge), d.h. man hat das höchstwahrscheinlich nicht ohne Notwendigkeit getan. Aber was war der Grund dazu? Hat es gar irgendwas mit der häufig bemängelten YouTube-Performance bei der Telekom zu tun, zu der es am 18. April 2013 einen Blog-Eintrag des Telekom-Hilft-Teams gab? Sachdienliche Hinweise sind willkommen.

Nachtrag: Natürlich haben sich auch die Reverse-DNS-Adressen der neuen IPv6-Blöcke entsprechend geändert.

Extra für das Telekom-Hilft-Team: IPv6 mit Telekom-DSL erklärt

Liebes Telekom-Hilft-Team, da Ihr gerne die Geschichte vom Pferd hohen Aufwand erzählt, wenn man fragt, warum man mit einer DSL auf einem Analog/ISDN-Anschluss (oder als All-IP-Bestandskunde) kein IPv6 bekommen kann (obwohl es für alle DSL-Anschlüsse versprochen wurde, siehe http://www.heise.de/newsticker/meldung/Deutsche-Telekom-konkretisiert-IPv6-Plaene-1102458.html und http://www.zdnet.de/41538861/deutsche-telekom-bietet-ipv6-fuer-privatkunden-ab-ende-2011/), hier mal etwas technischen Hintergrund, damit Ihr es zumindest Konzern-Intern hinterfragen könnt, wenn Euch intern wiederum jemand die Geschichte vom Pferd hohen Aufwand erzählt.

Eure DSL-Anschlüsse laufen über zwei verschiedene Plattformen ab:

  • die „alte“ ATM-Plattform
  • die „neue“ GbE-Plattform

Die beiden Plattformen unterscheiden sich im wesentlichen darin, wie der DSLAM (das Gegenstück zum heimischen DSL-Modem) an den BRAS (Breitband-Zugangsserver an euren bundesweit 74 Breitband-Knoten) angebunden ist. Über beide Plattformen werden Standard-(Analog-), Universal-(ISDN-) und All-IP-(VoIP)-Anschlüsse mit DSL versorgt. Da neue All-IP-Anschlüsse IPv6 bekommen können (siehe Leistungsbeschreibung) und da neue All-IP-Anschlüsse über beide Plattformen (ATM und GbE) geschaltet werden, müssen folglich beide Plattformen (ATM und GbE) IPv6-tauglich sein. Es wäre also kein zusätzlicher Aufwand, allen DSL-Anschlüssen IPv6 freizuschalten.

Falls Ihr nun auf die Idee kommt, vom noch nicht IPv6-tauglichen DSLAM zu sprechen: Dem DSLAM sind IPv4 oder IPv6 vollkommen egal, der heimische DSL-Router verpackt IPv4 und/oder IPv6 in PPPoE-Pakete, die vom DSLAM nur weitergeleitet werden. Erst der BRAS packt wieder IPv4 und/oder IPv6 aus den PPPoE-Pakete aus, und dass alle BRAS bereits IPv6-tauglich sind, dass haben wir im obigen Absatz ja bereits geklärt.

So, nun hakt doch nochmal Intern nach, warum man IPv6 nicht für alle DSL-Anschlüsse freischaltet, und gebt Euch diesmal nicht mit der Geschichte vom Pferd hohen Aufwand zufrieden.

Warum denn überhaupt IPv6?

Ab und an treffe ich auf Leute, die noch nicht ganz verstanden haben, dass IPv6 nicht einfach aus Spaß eingeführt wird sondern eine technische Notwendigkeit darstellt. Hier ein paar Beispiele für typische Fragen und Antworten.

Warum denn IPv6?

  • Weil uns die IPv4 Adressen ausgehen bzw. der IANA am 01.02.2011 ausgegangen sind. Seitdem wird mit Reserven der regionalen Registries und Provider gearbeitet aber auch diese sind irgendwann leer.
  • Weil die IPv4 Adressen auch so nicht reichen würden: Mit IPv4 sind knapp 4,3 Milliarden Adressen möglich aber bereits heute gibt es mehr Menschen als Adressen, somit ist klar, dass mit IPv4 nicht jeder Mensch am Internet teilnehmen kann.

Damit wird die Überwachung noch viel schlimmer!

Nein, die Adress-Vergabe z.B. der Telekom oder M-Net bei IPv6 ist praktisch genauso wie bisher bei IPv4: Bei jedem Verbindungsaufbau erhält man einen anderen Adressblock (bei IPv4 war es nur eine Adresse), d.h. man ist genausowenig oder genausogut zurückverfolgbar wie bei IPv4.

Dann muss ich ja viele neue Geräte kaufen!

Nein. IPv4 existiert weiterhin und kann gleichzeitig mit IPv6 benutzt werden und wird noch über viele Jahre im Internet geroutet werden. Jedes relevante PC-Betriebssystem und somit jeder PC aus den letzten 10 Jahren unterstützt IPv6. Drucker und Printserver, die evtl. Probleme damit haben, muss man nicht umstellen sondern kann man noch über Jahre bei sich zu Hause per IPv4 nutzen.

Die IPv6-Adressen sind aber so unübersichtlich!

Sie sind länger, dass stimmt, aber trotzdem führt kein Weg an IPv6 vorbei. Gegen die unübersichtlichen IPv6-Adressen kann man weiterhin DNS benutzen, schließlich gibt ja bisher auch kaum jemand auswendig alle IPv4-Adressen ein.

Warum denn jetzt schon IPv6?

Wenn man bei seinem Internetprovider nach nativem IPv6 fragt, dann bekommt man recht gerne die (ausweichende) Antwort, dass IPv6 für den Kunden ja noch keine Rolle spiele, weil man ja „das ganze Internet“ noch wunderbar per IPv4 erreichen könne.

Ja, prinzipiell ist das schon richtig, aber leider leistet man mit dieser Argumentation nur dem bestehenden Henne-Ei-Problem Vorschub:

Schauen wir uns beide Enden der typischen Internet-Nutzung an: Auf der einen Seite der Inhaltsanbieter, der seine Inhalte nur per IPv4 anbietet, weil ja noch kaum Endkunden IPv6 haben, auf der anderen Seite der Endkunde, der von seinem Internetprovider kein natives IPv6 im Dualstack bekommt, weil ja noch kaum Inhaltsanbieter IPv6 haben. So wird das natürlich nichts, wenn beide Seiten „Beamtenmikado“ spielen und darauf warten, dass sich die jeweils andere Seite bewegt.

Zum Glück ist bei den Hostern schon Bewegung erkennbar, Hetzner und Strato bieten seit Jahren natives IPv6 für dedizierte Server, 1&1 bot für dedizierte Server bisher eine IPv6-Tunnellösung  an und führt mittlerweile einen offenen Test für natives IPv6 durch. Anders schaut es bei den Access-Providern aus: Bei O2 und Vodafone habe ich noch nichts von IPv6 gehört, bei der Telekom wird es mit ausgewählten Neuverträgen (Call & Surf mit IP-Telefonie) aktiviert, bei den Kabel-Internet-Anbietern kriegt man als Neukunde mittlerweile IPv6 per DS-Lite (natives IPv6, getunneltes IPv4). Lediglich bei M-Net wurde IPv6 nach dem offenen Test einfach für alle DSL-Kunden aktiviert.

Liebe Access-Provider, seit doch etwas mutiger, denn das spart Euch langfristig Kosten: Wenn Ihr dafür sorgt, dass schnell viele Benutzer per IPv6 zugreifen könnten, dann merken das die Inhaltsanbieter und ziehen schneller nach. Je schneller die Inhaltsanbieter nachziehen, umso schneller kann man IPv4 sterben lassen oder auf Verfahren wie DS-Lite oder CGN umsteigen, ohne dass es den Kunden massiv „weh tut“. D.h. Ihr könntet früher IPv4 loswerden und somit den Aufwand zur Netzadministration wieder reduzieren… Ihr müsst einfach nur mit IPv6 schneller aus den Startlöchern kommen.

Feedback (nicht) erwünscht?

Die Telekom gibt sich ja neuerdings sehr „Kundennah“ und nimmt mit dem Telekom-Hilft-Team auf Twitter und Facebook teil, hat die Feedback-Community ins Leben gerufen und die Telekom-Service-Foren geschaffen. Schaut man genauer hin entpuppt sich das ganze allerdings mehr als Schein denn als Sein.

Werfen wir erst einen Blick zurück in längst vergangene Zeiten: Als das Thema „Web 2.0“ für die Telekom noch neu war, war der erste Schritt eine bereits existierende und hervorragend funktionierende Plattform für Feedback, Service und Diskussionen – die t-online-Newsgroups – dichtzumachen. Kann ja nicht angehen, dass man sich – basierend auf bewährtem – in Richtung „Web 2.0“ öffnet und z.B. die bestehende Plattform mit einem Webinterface ergänzt. Nein, man schlägt stattdessen das, was man hat, erstmal gründlich kaputt. Ein gutes Jahr später hat man dann den Newsserver (zu dem Zeitpunkt der meistgenutzte Newsserver in Deutschland) komplett dicht gemacht.

Kommen wir nun zurück zur jetzigen Feedback-Community. Obwohl dort der Begriff „Feedback“ schon im Namen steht scheint man nicht sonderlich an Feedback interessiert zu sein. Kritisiert man die Produktgestaltung (z.B. fehlendes IPv6 bei Bestandskunden sowie ISDN- und Analoganschlüssen) zu deutlich kann es einem leicht passieren, dass ein Moderator das Thema für beendet erklärt und/oder auf die Service-Foren verweist (die wenig mit Feedback zu tun haben) und schließt (konnte ich selbst reproduzieren). Amüsanterweise stellt er in seinem Abschlußposting nochmal ein paar Gegenfragen…

@Kai, wie soll man auf Deine Gegenfragen antworten, wenn Du den Thread schließt?

Liebe Telekom, liebes Telekom-Hilft-Team, …

…wenn Ihr eine Feedback-Community betreibt, dann müsst ihr damit rechnen, dass sich die Kunden erlauben, diese für Feedback zu nutzen. Wenn Ihr kein Feedback bekommen wollt, dann nennt das Ding anders oder macht einfach einen Link auf die Service-Foren daraus.

…selbstverständlich kann Euch niemand (naja, fast, die BNetzA in manchen Dingen durchaus) die Produktgestaltung vorschreiben, aber es gehört dennoch zum guten Ton, mit seinem Geschäftspartner zu Reden. Es weckt beim Kunden keinerlei Vertrauen, wenn er auf Anfragen – egal wo – immer nur eine Mauer aus Nichtswissern, Nichtssagern oder Nichtsentscheidern stößt. Der Kunde bekommt dabei leicht den Eindruck, dass der Laden nur durch ein Wunder noch immer läuft, obwohl dort eigentlich keiner so recht weiß, was er tut.

Cyrus-Zickigkeiten

In meinem Bekanntenkreis bin ich einer der wenigen der (auch) Postfix mit Cyrus einsetzt – die geläufigere Kombination ist dort wohl Exim mit Dovecot. Mit Postfix habe ich bisher keine negativen Erfahrungen mit Cyrus war das auch so bis mir neulich eine etwas ältere Installation Spaß bereiten wollte.

20. Dezember

Es trudeln Meldungen zweier User ein, dass sich das Webmail komisch verhalte. Der Mailabruf per POP3 oder IMAP4 ist nicht komplett ausgefallen jedoch führt ein EXPUNGE zu Ende der TCP-Connection… und das Webmail möchte beim öffnen eines Ordner erstmal ein EXPUNGE ausführen. Im Logfile äußerst sich das so:

cyrus/master[7067]: service imap pid 8873 in BUSY state: terminated abnormally

Später gesellen sich noch Meldungen folgender Art dazu:

cyrus/imaps[11644]: DBERROR db4: 24 lockers

Okay, führe ich also ein manuelles Recovery der Cyrus-Datenbanken durch und… nichts ändert sich. Eine Recherche bei Google nach der ersten Fehlermeldung führt zu der Empfehlung Cyrus upzudaten und der Einheizkater schließt sich dieser Empfehlung an. Kommt mir zwar komisch vor, wo es doch bis vor wenigen Stunden noch funktioniert hat, aber in meiner Ratlosigkeit versuche ich das und… es funktioniert wieder.

Damit war das Thema für mich erstmal erledigt, doch es sollte wieder auf meinen Tisch zurückkommen.

22. Dezember

Wir fahren über die Weihnachtsfeiertage zur schwäbischen Verwandschaft. Dort angekommen fehlt mir die Motivation nochmal den Rechner anzuwerfen, daher merke ich erstmal nicht, dass bei Cyrus schon wieder etwas im Argen ist. Im Logfile finde ich später Meldungen folgender Art:

couldn't connect to lmtpd: Connection timed out_ 421 4.3.0 deliver: couldn't connect to lmtpd_

23. Dezember

Nagios begrüßt mich mit zwei Mails, der POP3- und IMAP4-Dienst seien gegen 5:23 ausgefallen. Zu der Zeit findet ein täglicher Restart der Cyrus-Dienste statt um liegengebliebene Prozesse – die leider bei TLS/SSL-verschlüsselten Sessions häufig auftreten – abzuräumen. Ich schaue dem System in die Eingeweide und stelle fest, dass ein cyr_expire-Prozess beinahe alle CPU-Leistung auffrisst aber nichts tut. Nach einem Versuch Cyrus per Restart zu motivieren finde ich das hier im Log:

cyrus/cyr_expire[19078]: DBERROR db4: PANIC: fatal region error detected; run recovery
cyrus/cyr_expire[19078]: DBERROR: critical database situation

Aha, das erinnert mich wieder an die Meldungen vom 20. Dezember. Also nochmal ein manuelles Recovery versucht, leider wieder ohne Verbesserung. Nach etwas Recherche wird mir klar dass cyr_expire sich um deliver.db bearbeitet, das normale Recovery jedoch mailboxes.db und annotations.db repariert. Da ich nichts finde, dass mir für eine Reparatur der deliver.db gedacht erscheint, benenne ich die Datei um und starte Cyrus ein weiteres Mal neu und… siehe da: Es läuft wieder.

26. Dezember

Wieder beglückt mich Nagios mit zwei Mails am Morgen. Der Server war von ca. 23:20 bis 01:10 nicht erreichbar. Nach einem Blick im Logfile ist er in der Zeit tatsächlich tot gewesen, wurde um 01:10 wieder gestartet und um 03:20 nochmals. Ich vermute einen kleinen Stromausfall in einem Teil des beheimatenden RZ. Mal sehen was der Betreiber dazu sagt. Nach obigen Cyrus-Incidents und einem unpuscheligen Bootsektor Anfang des Monats wünsche ich mir etwas Ruhe an dieser Baustelle.

Erster Test der VKVM bei Hetzner

Im Gegensatz zu den Karlsruher Mitbewerbern bietet Hetzner bei seinen dedizierten Servern keine serielle Konsole mit an. Zwar benötigt man dieses Feature nicht wirklich oft, praktisch ist es aber dennoch, wenn man ein Unwohlbefinden des Servers beim Bootvorgang genauer untersuchen möchte bzw. auch einfach nach einem Systemupgrade den Bootvorgang miterleben will.

Als Ersatz gibt es bei Hetzner schon längere auf Anfrage stundenweise die sogenannte LARA, die ich bisher zum Glück nicht gebraucht habe. Die LARA wird an die Keyboard-, Video- und Mouse-Anschlüsse angeschlossen und bietet dem Kunden dann über ein Java-Applet Zugriff auf seinen Server. Damit hat man sogar etwas mehr Möglichkeiten als mit einer seriellen Konsole, da man mit der LARA auch den Bootvorgang boch vor dem Bootloader beobachten kann. Im Notfall muss man aber erst eine Supportanfrage absetzen und drauf hoffen, dass zeitnah eine LARA verfügbar ist.

Als Zwischenlösung gibt es seit etwas über einem Jahr auch VKVM bei Hetzner. Dabei wird der Server über das Netzwerk in ein Rescue-System geboot und darin eine VM gestartet, auf die man per VNC zugreifen kann. Diese VM kann dann das System von der Platte des Servers starten, so dass man den kompletten Bootvorgang miterleben kann.

Nachdem ich nun auch einen noch nicht produktiven Server zur Hand hatte, um das mal auszuprobieren, habe ich die Gelegenheit genutzt. Besser man macht sich vorab mit dem Feature vertraut anstatt erst im Notfall wenn man dann eh schon aufgeregt ist und die Zeit knapp ist.

Als erstes wählt man im Hetzner Robot bei seinem Server unter Rescue VKVM in der zur Installation passenden Variante aus. Man erfährt sofort URL und Zugangsdaten der VKVM-Konsole. Nicht wundern braucht man sich darüber, dass die URL auf die Haupt-IP-Adresse des eigenen Servers verweist. Nun löst man den Restart des Servers aus; entweder per Reboot auf dem Server selbst oder – wenn dieser nicht mehr erreichbar ist – über den Hetzner Robot. Es dauert nun einige Zeit bis das Rescue-Virtualisierungs-System hochgefahren ist. Nach einiger Zeit kann man dann per Java-fähigemBrowser auf die genannte URL zugreifen und sich mit den genannten Zugangsdaten anmelden. Es startet ein Java-Applet über dass man Zugriff auf die Konsole des virtualisierten Systems erhält. In dieser Konsole sieht man nun eine etwas verwirrende Boot-Schleife, bei der scheinbar versucht wird, das lokale System zu starten, was jedoch nicht klappen mag. Des rätsels Lösung ist, auf folgende Frage mit Q zu antworten:

Boot from (N)etwork or (Q)uit?

Erst dadurch wird der Bootloader auf der Festplatte des eigenen Systems gestartet, der Default N bietet hingegen weitere Diagnose- und Rescue-Möglichkeiten an aber nichtden Zugriff auf das installierte System. Einen weiteren Fallstrick gibt es nun beim Start des installierten Systems: Benutzt man einen Kernel, der auf Hardware-Virtualisierungstechniken angewiesen ist, z.B. mit Xen-Support, so scheitert der Start, denn man ist ja bereits in einer virtuellen Umgebung in der keine Hardware-Virtualisierungstechniken mehr verfügbar sein können.

Hat man auch diese Hürde geschafft startet endlich das installierte System und ist dann auch aus dem Internet z.B. per SSH erreichbar, was für Arbeiten an den Konfigurationsdateien sicherlich etwas angenehmer ist als der Zugriff über die Konsole im Java-Applet.

Verzwickt ist zum Schluss nochmal der Wechsel zurück zum „echten“ System. Die Menüpunkte des Java-Applets, die einen Strg+Alt+Entf senden lassen bzw. einen Hardware-Reset durchführen lassen wirken sich nur auf die virtuelle Umgebung aus, d.h. man verläßt damit das Rescue-VKVM-System nicht. Erst durch einen richtigen Reboot aus dem Hetzner-Robot kommt man hier wieder raus.

Fazit: Von der Handhabung her etwas komplizierter als eine serielle Konsole her, von den Diagnose- und Reparaturmöglichkeiten möglicherweise sogar etwas besser.

IPv6 Glue Records bei SchlundTech

Mit IPv6 hantiere ich ja schon seit ca. 3 Jahren und nun habe ich meinen beiden Nameservern endlich auch IPv6 Glue Records verpasst.

Wenn man SchlundTech als Registrar benutzt ist die Vorgehensweise allerdings etwas trickreich: Ich musste den IPv6-Glue-Record per Leerzeichen getrennt im Feld des IPv4-Glue-Record eingeben, alle anderen Varianten – ein explizites Feld für IPv6-Glue-Records existiert nicht – warfen mir Fehlermeldungen um die Schlappohren.

Gespannt bin ich nun, ob die nächste Änderung des IPv4-Glue-Records für meine .net-Domain direkt klappen wird. Bisher war ich entweder auf manuelle Eingriffe des Support angewiesen oder aber musste den IPv4-Glue-Records durch ein Leerzeichen getrennt direkt im Feld des DNS-Server-Namens eingeben.

E-Plus und HSDPA

Wenn es um mobiles Internet geht, dann werden E-Plus bzw. die über das E-Plus-Netz realisierten Angebote ja gerne belächelt, da E-Plus erst letztes Jahr mit dem EDGE-Rollout begonnen und HSDPA bisher auch nur in so wenigen Zellen angeboten hat, dass die meisten Leute davon ausgingen, es gäbe gar kein HSDPA bei E-Plus.

Überrascht war ich daher vor ca. drei Wochen, als in unserem Wohnort plötzlich HSDPA verfügbar war. Bisher stand hier nur EDGE zur Verfügung. Zuerst dachte ich, dass UMTS und HSDPA vielleicht versehentlich aktiviert wurden und nach wenigen Tagen wieder weg sein würden. Nachdem der erfreuliche Zustand nun aber schon drei Wochen anhält und auch in vielen anderen Zellen seitdem HSDPA verfügbar ist, wo bisher maximal UMTS geboten wurde, scheint sich doch dauerhaft etwas zu tun bei E-Plus.