Jemand, womöglich aus der Branche, möchte, aus welchen Gründen auch immer, nicht, dass derjenige, der über die Domain verfügt, sein Geschäft damit betreibt. Wir sprechen von einer Branche, in der man keine kleinen Brötchen backt. Nein, ganz und gar nicht.

Die Dienstleistung, die er in Anspruch nimmt, um seinem Anliegen Nachdruck zu verleihen, wird in einer anderen, nicht weniger prächtig gedeihenden Branche angeboten. Dort gibt es Botnetze jeder Kapazität zu mieten, zusammen mit Rundum-Sorglos-Paketen zu verschiedenen Tarifen. Die berühmtesten Botnetze bestehen aus Millionen von weltweit verteilten Rechnern, die sich ihre Backdoors wahrscheinlich wiederum zusammen mit den Produkten der ersten Branche installiert haben.

Unser Freund kauft ordentlich ein, denn er hat wahrscheinlich irgendwann – einen Schnaps in der Hand – versprochen, dass kein Provider der Welt diese Domain jemals konnektieren wird. Etwa so, als würde man einem Markthändler das Geschäft dadurch vermiesen, dass man jede Markthalle in die Luft sprengt, in der er seinen Stand aufstellen will. Auf drei Nameservern der http.net war die Zone für etwa eine Stunde eingetragen. Der Rest ist (hoffentlich bald!) Geschichte.

Ein Beispiel Schritt für Schritt

Nehmen wir an, eine DE-Domain soll registriert werden. Im Bestellformular wählt man zunächst Domainnamen und Auftragsart:

Im nächsten Schritt werden die Kontakt-Handles ausgewählt oder erstellt. Das ist nichts Neues und wird hier nicht besprochen. Als nächstes ist die Delegation für die Domain anzugeben. Damit teilt man der Registry mit, welche Nameserver für die Domain zuständig sein sollen. Bei einer DE-Domain hat man hier folgende Möglichkeiten:

1. Eigene Nameserver
2. Nameserver der http.net
3. Nameserver der DENIC (NSentries)

Wenn man eigene Nameserver verwendet, muss man selbst für die Eintragung einer geeigneten DNS-Zone auf den angegebenen Nameservern sorgen. Wenn man NSentries verwendet, kann man ein paar Resource-Records angeben, die DENIC zusammen mit der Domain einträgt. Wenn Sie unsere Nameserver benutzen, so mussten Sie bisher separat einen Auftrag an unseren DNS-Robot generieren, um die Zone dort einzutragen.

Neu: Wenn Sie unsere Nameserver verwenden, können jetzt gleichzeitig einen Auftrag an den DNS-Robot generieren, so dass zuerst die Zone eingetragen wird. Ganz analog zu NSentries können Sie also hier direkt einige wichtige Resource-Records für die Domain angeben. Das gilt natürlich nicht nur für DE-Domains, sondern für beliebige TLDs. Aktivieren Sie die Checkbox “Zonendaten eintragen” um das Formular zu erweitern:

Die Syntax der Express-DNS-Einträge orientiert sich an den NSentries. Sie können bis zu 6 Address- und Mail-Exchange-Records eintragen. Wie es geht, sollte schnell klar werden, wenn Sie auf “Beispiel anzeigen” klicken. Dann wird passend zum Domainnamen ein Standard-Beispiel generiert:

Benutzen Sie die Beispiel-Daten als Vorlage für Ihre eigenen Einträge. Wenn Sie beim Klick auf “weiter” die Checkbox

Die Angaben auf dieser Seite als Standardwerte speichern.

aktiviert haben, werden Ihre Express-DNS-Einträge als Vorlage gespeichert und bei der nächsten Benutzung des Formulars mit dem jeweiligen Domainnamen geladen, so dass Sie Ihre Standard-Konfiguration nur einmal eintragen müssen.

Nachdem Sie auf “weiter” geklickt haben, sehen Sie im letzten Schritt, in der Zusammenfassung des Auftrages, das Template, das an den Domain-Robot gesendet wird. Hier können Sie natürlich auch noch Änderungen vornehmen, wenn Ihr Auftrag spezielle Zusatzangaben erfordert oder Sie etwas ändern möchten:

Wenn Sie die Express-DNS-Option verwendet haben, sehen Sie hier ein Kombi-Template. Der Domain-Robot sendet den DNS-Teil solcher Templates zunächst an den DNS-Robot und verarbeitet den Domain-Teil zwei bis drei Minuten später, um sicherzustellen, dass die Zone zuerst eingetragen wird, falls dies für den Domain-Auftrag erforderlich ist.

Feedback erwünscht!

Wie bei all unseren Innovationen gilt auch hier: Wir haben versucht, aus Ihren Anregungen, unserer Erfahrung und den technischen Möglichkeiten das aus unserer Sicht Beste zu machen. Am liebsten möchten wir aber das Beste aus der Sicht unserer Partner realisieren. Deshalb: Ideen, Anregungen, Verrisse – alles erwünscht!

Heute haben wir uns mal den Robot vorgenommen und haben gedacht: wie wär’s mit einem kleinen Hack!

Warum sollte man nicht einfach bei einem Domain-Template auch ein DNS-Template mit senden können? Eine bessere Verknüpfung der Komponenten war schließlich auch in den Kommentaren zur Umfrage gefordert worden. Was das Partnerweb und andere Schnittstellen betrifft, wird das ein wenig aufwändiger werden, aber beim SMTP-Robot ist die Lösung eigentlich ganz einfach. Schreiben wir doch mal auf, was wir haben wollen:


From: support@example.com
To: domreg@routing.net
Subject: REG: name.de

#internal: 999999/******

domain: name.de
owner-c: TEST1-HTTP
admin-c: TEST2-HTTP
tech-c: TEST3-HTTP
zone-c: TEST4-HTTP
nserver: ns.routing.net
nserver: ns8.routing.net

dnszone: name.de
primary: ns.routing.net
mailbox: dnsmaster@example.com
namesrv: ns.routing.net 213.160.64.64
namesrv: ns8.routing.net 213.160.65.64
arecord: @ 213.160.69.3
crecord: www @


So, jetzt muss man dem Robot nur noch sagen, dass er zuerst den unteren Teil an seinen Kollegen, den DNS-Robot, weitergeben und dann den ersten Teil selbst verarbeiten soll. Fertig

Also, Spaß beiseite. Folgendes gilt ab sofort:

An das Ende eines Domreg-Templates kann man ein DNS-Template hängen, das mit der Zeile


dnszone: <domain>


(anstelle der domain-Zeile) beginnt. Daraus werden zwei separate Aufträge erzeugt, nämlich ein DNS-Template, das sofort an den den DNS-Robot übergeben wird, und ein Domain-Template, das etwa 2 bis 3 Minuten später an den Domreg-Robot gesendet wird, um sicherzustellen, dass die Zone zuerst eingetragen wird, falls dies für den Domain-Auftrag erforderlich ist.

Bei REG- und KK-Aufträgen an den Domreg-Robot wird ein REG-Auftrag für den DNS-Robot erzeugt, CLOSE- und TRANSIT-Aufträge kann man mit einem DNS-CLOSE verbinden und einem Domain-UPDATE kann man ein DNS-UPDATE anhängen. For Robot-Templates ohne dnszone-Schlüssel ändert sich natürlich nichts.

Einfach mal ausprobieren!

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.

We love to resolve you

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

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.

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.

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