Der 8. Juni 2011 wurde zum internationalen IPv6-Tag erklärt und alles, was im Internet Rang und Namen hat, wird für einen Tag auch über IPv6 erreichbar sein.
Dies dient unter anderem dazu, den neuen Standard einmal im wahren Leben zu testen und eventuell auftretende Fehler zu korrigieren.
Natürlich möchten wir nicht hinter Google, Facebook und Heise zurückstehen, deshalb werden ab heute die Adressen http.net, www.http.net und natürlich ipv6.http.net auch über IPv6 erreichbar sein.
Nachdem sich nun endgültig herumgesprochen hat, dass der Vorrat an IPv4-Adressen zur Neige gegangen ist, hat sich auch der DNS-Robot der http.net beeilt, IPv6 zu lernen. In einem ersten Schritt werden Resource Records vom Typ AAAA (sprich: Quad-A) unterstützt. Ganz analog zum alten Robot-Schlüssel
arecord
heißt der neue Schlüssel:
a4record
Dahinter wird eine IPv6-Adresse erwartet, die in einem beliebigen der üblichen Formate (entsprechend rfc3513) angegeben werden kann.
Wer also z.B. den Namen example.com auf die IPv6-Adresse
fdda:5cc1:23:4::1f
auflösen lassen möchte, kann folgendes Template an den DNS-Robot senden:
domain: example.com
primary: ns.routing.net
mailbox: dnsmaster@example.com
namesrv: ns.routing.net 213.160.64.64
namesrv: ns8.routing.net 213.160.65.64
namesrv: ns9.routing.net 83.133.190.5
arecord: @ 192.0.32.10
a4record: @ fdda:5cc1:23:4::1f
crecord: www @
A-Records und AAAA-Records können nebeneinander existieren. CNAME-Records können wie gewohnt als Aliase für Hostnamen verwendet werden, die an eine IPv4- oder IPv6-Adresse gebunden sind. Die Ausgabe für obige Beispiel-Zone würde etwa so aussehen:
;; QUESTION SECTION:
;www.example.com. IN ANY;; ANSWER SECTION:
www.example.com. 86400 IN CNAME example.com.
example.com. 86400 IN SOA ns.routing.net. dnsmaster.example.com. 2011021703 14400 3600 604800 86400
example.com. 86400 IN A 192.0.32.10
example.com. 86400 IN AAAA fdda:5cc1:23:4::1f
example.com. 86400 IN NS ns.routing.net.
example.com. 86400 IN NS ns8.routing.net.
example.com. 86400 IN NS ns9.routing.net.
Wer also seinem IPv6-fähigen Kühlschrank nun auch einen Hostnamen verpassen möchte, kann an unseren DNS-Robot schreiben. We love to resolve you 
Wie immer, wenn etwas immer größer und komplizierter wird, zeichnet sich ein Trend zur Lokalisierung ab. Das Internet ist ein topologischer Raum, der so hochdimensional geworden ist, dass man ihn nur noch als Überdeckung eines unfassbaren Etwas durch lokale Landkarten erklären kann. Das Kraftwerk der Globalisierung sehnt sich heute nach Semantik, sucht soziale Kontakte und organische Strukturen.Es möchte den Menschen nahe sein, ihre Gegend kennen und ihren Dialekt sprechen.
Die alten globalen und normativen Lösungen werden verfeinert und den Bedürfnissen angepasst. Zum Beispiel der IDNA-Standard. Die Intention von IDNA ist es, Abbildungen zu definieren, die eine Kommunikation zwischen den unterschiedlichen und eigenartigen Informationsspektren beliebiger lokaler Entitäten auf der Basis uralter und schwer veränderbarer Protokolle wie dem DNS-System ermöglichen.
Im August 2010 veröffentlichte die IETF die IDNA2008-Spezifizierungen in RFC 5890 – 5894. Eine Übersicht über die Unterschiede zwischen IDNA2003 und IDNA2008 bietet der Unicode Technical Standard #46 (Unicode IDNA Compatibility Processing). Bis dahin war IDNA eine globale Funktion, im Wesentlichen bestehend aus dem Nameprep-Mapping und dem Punycode-Algorithmus, wobei Nameprep effektiv durch eine Reihe von Tabellen definiert ist, die z.B. Groß- auf Kleinbuchstaben und "ß" auf “ss” abbilden. Der alte Standard hatte damit die Verantwortlichkeit für die konsistente Behandlung unterschiedlicher Sprachen innhalb des IDNA-Protokolls angesiedelt. Diese Lösung war global, einfach und unflexibel.
Mit IDNA2008 wurde eine neue Terminolgie geschaffen, die den Anforderungen an die lokale Unterschiedlichkeit von Applikationen und Benutzern gerecht werden und die Offenheit gegenüber zukünftigen Unicode-Versionen garantieren soll. Das Eszett, namentlich der Codepoint U+00DF (LATIN SMALL LETTER SHARP S), wurde auf Betreiben von DENIC als Ausnahme in die Kategorie PVALID (Protocol Valid) aufgenommen. Während also die deutsche Ligatur ß in der DE-Zone nun mit xn--zca aufgelöst wird, kann es gleichzeitig in einer anderen Zone mit ss aufgelöst werden. Ein Beitrag zur Lokalisierung und zur Konjunktur bei ISPs und Anwälten.
Dieser Codepoint bildet nun eine Deviation, d.h. unterschiedliche Applikationen können ihn abweichend verarbeiten. Man stelle sich vor, Alice greift von zu Hause aus auf ihr Konto unter http://www.sparkasse-gießen.de zu. Ihr Browser unterstützt IDNA2003, bildet also auf http://www.sparkasse-giessen.de ab und löst auf die IP-Adresse des Sparkassenservers auf. Nun besucht sie ihren Freund Bob und prüft dort ihren Kontostand. Bobs Browser unterstützt IDNA2008, benutzt also bei gleicher Eingabe stattdessen http://www.xn--sparkasse-gieen-2ib.de, was auf eine ganz andere IP-Adresse aufgelöst werden kann. Unter dieser könnte der Phishing-Server von Eve antworten, die so die Zugangsdaten von Alice ausspionieren kann.
Und wenn schließlich der Browser am Encoding der Diskussionsbeiträge verzweifelt, so wirkt das irgendwie selbstreferenziell:
Ãh???
Für den ISP-Developer ist Lokalisierung allerdings stets eine Herausforderung. Er ist dafür zuständig, dass die lokalen Einheiten untereinander und miteinander kommunizieren können. Und wer will sich heute schon noch in ASCII unterhalten.
Das kleine "ß" landet also eines Tages auf dem Schreibtisch und erklärt sich für gültig. Natürlich weiß die an Hunderten von Stellen tief in alle Systeme eingegrabene IDNA-Software noch lange nichts von den neuen RFCs. Der .NET System.Globalization-Namespace, der bis dahin zuverlässige Dienste beim Normalisieren, Validieren und Konvertieren auch der absonderlichsten Zeichen leistete, ist unter keinen Umständen dazu zu bewegen, ein "ß" in Domain-Namen zu akzeptieren. Und was so eine DLL nicht kann, das kann sie eben nicht – tja, auf hoher See, vor Gericht und vor Microsoft …
Am 26. Oktober 2010 kündigte DENIC an, praktisch ab sofort IDNA2008 zu unterstützen und zunächst in einer Sunrise-Phase allen Inhabern von Domains, die ein “ss” enthalten, die Gelegenheit zu geben, das Pendant mit "ß" zu registrieren. Es musste innherhalb von wenigen Stunden eine Ad-hoc-Lösung her. Und das einzig Naheliegende war, eine automatische Abfrage des DENIC-Web-Tools zu programmieren, das in dem Moment den einzigen bekannten ß-fähigen Konvertierungsmechanismus bot. Unsere Auszubildende setzte das prompt um, während eilig RFCs studiert und nach einer tragfähigen Lösung gesucht wurde. Diese bietet die GNU IDN Library Libidn. Die kann zwar auch noch kein "ß", ist aber fix gepatcht. Der Code liegt in C, Java und C# vor, da ist also für jeden etwas dabei.
Also wird http.net auch in Zukunft allen globalen Anforderungen und lokalen Bedürfnissen des Internets technisch gewachsen sein 
update:
Hier ist ein Hotfix für Libidn.
Wir möchten uns bei allen unseren Kunden für die Erreichbarkeits-Probleme, die gestern zum zweiten Mal in dieser Woche aufgetreten sind, entschuldigen und Sie über die Hintergründe informieren.
In der Nacht vom Montag zum Dienstag, erfolgte ein geplantes Upgrade der Router-Software in Vorbereitung auf die parallele Einführung von IPv6. Trotz intensiver Vorbereitung mit unseren Router-Consultants (einschl. vorherigem Probelauf im Testlab) traten unerwartete Störungen im Routing auf, deren Ursache in Zusammenarbeit mit dem Hardware-Hersteller (Juniper), unseren Router-Consultants und Leitungsprovidern noch analysiert wird.
Als Sofortmaßnahme hatten wir etliche Peerings heruntergefahren und die Arbeiten zur Erweiterung auf IPv6 gestoppt um die Detailanalyse nicht zu beeinflussen.
Gestern, am 2. September kam es ab 16:00 Uhr zu erneuten Problemen auf den Core-Routern, die sich zuerst in einer außergewöhnlich hohen CPU-Auslastung der Router zeigten. In Zusammenarbeit mit sofort hinzugezogenen externen Routing-Spezialisten konnte die CPU-Last durch Deaktivierung nicht essentiell benötigter Dienste auf Normalniveau gesenkt werden.
Trotzdem traten bei beiden Anbindungen, Versatel und Lambdanet, massive Paketverluste auf. Dabei wurden ICMP- und UDP-Pakete korrekt geroutet, während aber abgehende TCP-Pakete außerhalb unseres Netzes zum Teil nicht durchgeroutet wurden. Dieses Problem trat hauptsächlich auf, wenn die Route über eine Hamburger Netzknoten lief, beim selben Carrier über Frankfurt trat dieses Problem nicht auf, was die Fehlereingrenzung zusätzlich erschwerte.
Durch das Herunterfahren weiterer Peerings und das Deaktivieren einzelner mehrfach redundanter Backbone-Devices konnte das Routing stabilisiert werden. Gegen 22:00 Uhr zeigten unsere Systeme wieder ein normales Routing-Verhalten an. Wir waren zeitgleich mit mehreren Kunden in regem E-Mail und Telefonkontakt und möchten uns an dieser Stelle für die vielfachen Hinweise und Problemdarstellungen aus Kundensicht bedanken.
Eine nun folgende Tiefenanalyse aller Vorgänge dieser Woche wird aufzeigen, welches Zusammenspiel einzelner Faktoren ursächlich für diese Probleme war. Die daraus gewonnenen Erkenntnisse bilden die Grundlage für die zukünftige Vermeidung einer solchen Situation.
Als weitere Sofortmaßnahme priorisieren wir die Erweiterung von Bestands-Domains auf einen 3. Nameserver, der sich in einem Düsseldorfer Hochleistungsrechenzentrum befindet. Darüber hinaus planen wir die Erweiterung des DNS-Systems um einen 4. Standort, voraussichtlich Amsterdam. Dies erhöht zusätzlich auch die Stabilität der Zonenverwaltung bei DOS-Attacken.
Wir versichern Ihnen, dass wir die Ereignisse der letzten Tage bis ins kleinste Detail analysieren werden und alle notwendigen Maßnahmen im administrativen und technischen Bereich unverzüglich ergreifen und umsetzen werden, damit sich diese Probleme nicht wiederholen.
Wir bitten um Entschuldigung und danken für das weitgehend von Ihnen erfahrene Verständnis.
Viele Internetuser haben es heute festgestellt, die DNS-Auflösung bei .de-Domains funktionierte vorübergehend nur unzuverlässig.
Wem das nichts sagt: Domains mit der Endung .de konnten kurzfristig nicht aufgerufen werden, da einige für die .de-Zone zuständigen Nameserver, die Domainnamen in IP-Adressen umwandeln, nicht ordnungsgemäß funktionierten.
Wer den Schaden hat, braucht für den Spott nicht zu sorgen; unter Denic Mitgliedern wurde bereits gewitzelt: “Heute bei der #denic: ‘Klaus, machst Du mal das Internet aus?’ ‘Jo, erledigt’” 
Da die Nameserver a-z.nic.de heißen, hat man bei tagesschau.de aus der telefonisch erteilten Auskunft geschlossen, dass “demnach alle deutschen Internetadressen zwischen den Buchstaben “E” und “O” …” betroffen seien. Komisch nur, das tagesschau.de selbst kurzfristig auch nicht erreichbar war
Aber nun ist alles gut, das Internet wurde inzwischen wieder hochgefahren
