Lately, while snooping around within old coding stuff, I rediscovered
an ancient treasure: the PostScript programming language.
It's older than dirt and situated deep down under the bottom of Adobe's PDF
technology. Intended to be an efficient and highly flexible printer
instruction language, it's actually a Turing-complete programming language,
based on a very clear and suprisingly simple stack-oriented concept,
outputting geometric results to suitable devices.
These are 6 chinese characters from the
CJK Unified Ideographs Extension A
block.
I've never seen before that Punycode results in any meaningful word and I think this is
an extremely rare case. So I couldn't help myself to register both
xn--bullshit.com
and
xn--bullshit.net
immediately.
Starting 10 December 2009, companies and private persons based in the European
Union will be able to register
.eu Internationalised Domain Names.
The list of supported characters
is divided into several parts, called IDN scripts,
such as "Latin-1 supplement", "Greek extended", "Cyrillic" and the like.
Indeed, I may consider to get
Unfortunately, one cannot mix several scripts, thus β-blog.eu won’t be a valid name,
since ASCII-letters belong to the Latin script while β is Greek. (Well, so, I think
I’ll give up that idea )
To get serious, as an EURID registrar, it’s time for us to check out several
issues that may apply to IDN requests built up with all that strange letters
Europeans may use.
For instance, note that
a1.eu
and
а1.eu
are completely different domain names. But this is just an optical
trick, since the first one starts with an ordinary ASCII "a" while the second
starts with U+0430, wich is the unicode notation of the cyrillic small letter "a".
Indeed, when you hit the second one into your browser, it will calculate
the according ACE-string xn—1-7sb.eu using the punycode algorithm first and will
make up the DNS request with it.
Things are getting more complicated when you notice that
aŀt.eu
on the one hand, and
al·t.eu
on the other hand indeed are the same domain name.
Applying the punycode algorithm to both of them, you will get
xn--at-rqa.eu
for the first one and
xn--alt-mga.eu
for the second one, because both byte streams differ.
Now, something goes wrong here, since when you plan to ask a nameserver for the
IP address to access the domain, you will have to decide for wich one you ask.
Unlikely a nameserver will answer to both of them.
Well, according to the IDNA standard as defined in rfc3490, applications
not only have to do a punycode for IDNs, but also have to apply the
nameprep algorithm first, wich in turn consists of several normalization mappings
such as lower case conversion and, more interesting, also the
Unicode Normalization Form KC
(see http://unicode.org/reports/tr15/).
The latter is the decomposing of characters by unicode compatibility equivalence.
Thus, the character U+0140, the Latin small letter "l" with middle dot,
decomposes into two unicode characters:
U+0140 => U+006C + U+00B7
That is, the middle dot will be aparted from the letter "l". Therefore, xn—at-rqa.eu
is an application of punycode, but not a conversion in the sense of IDNA standard.
Indeed, you will get different results from different so-called IDN converter libraries
with that domain, depending on whether they ara just doing punycode or applying a proper nameprep
first. A reliable reference is the Verisign conversion tool
(http://mct.verisign-grs.com/index.shtml)
and the according SDK for example (although I wasn’t able to get the Win32 version working).
After all, the challenge for the registrar is to maintain the request database properly,
accepting IDN requests in both the normalized and any equivalent form. And moreover,
one has to check a requested name against the given character list wich contains
non-normalized letters, even if the requested name is normalized already.
Since normalization isn’t a reversible mapping this may be complicated
in general, but should be solvable in this case.
Chronologie eines außergewöhnlichen Programmierwettbewerbs
Donnerstag, 15.10.2009, 16:14 Uhr
Ein unspektakulärer Arbeitstag neigt sich dem Ende zu. Im Posteingang erscheint
eine Verlautbarung der DENIC-Mitgliederliste.
Von einem BGH-Urteil ist die Rede, von neuen Domainrichtlinien. Da per Gerichtsbeschluss
die Registrierung der Domain vw.de angeordnet worden sei, sollen auch vergleichbare Domainnamen freigegeben
werden, die bisher nicht zugelassen waren: ein- und zweistellige Domains, Zifferndomains,
sowie existierende Toplevel-Domains und deutsche Autokennzeichen.
Das bedeutet: keine Beschränkungen mehr, abgesehen von der Maximallänge und dem
zugelassenen Zeichensatz, sowie der international üblichen Regel, dass Domainnamen
nicht mit einem Minus beginnen oder enden dürfen.
Es ist klar, dass unter diesen Namen nicht wenige sind, die man mit fünf- bis
sechsstelligen Beträgen handeln werden wird.
Im dritten Absatz offenbart sich dann die eigentliche Brisanz dieser Nachricht.
Man muss zweimal hinschauen: Die Registrierung der neuen Domains ist ab
"25.10.2009 9:00 Uhr (MESZ)" freigegeben. First come – first served.
Prompte Nachfrage eines Mitgliedes:
Der 25.10. sei ein Sonntag und außerdem der Tag, an dem um 3:00 Uhr von MESZ auf MEZ
umgechaltet wird, ob das bekannt sei? Und ob wirklich MESZ gemein sei?
Donnerstag, 15.10.2009, 16:43 Uhr
Achja, es wird offiziell korrigiert:
Starttermin ist Freitag, der 23.10.2009, 9:00 MESZ. Das ist in einer Woche.
Währenddessen: der Geschäftsführer erscheint zur spontanen Krisensitzung im Entwickler-Büro.
Wir müssen sehr schnell zwei Dinge gleichzeitig tun:
Einen Landrush für unsere Kunden vorbereiten, damit sie ihre Bestellungen vormerken können.
Unsere Teilnahme an der Vergabe am 23.10. vorbereiten.
Schon während des Gesprächs wird ein Webformular für die Kunden aufgesetzt, zum Vormerken
der gewünschten Domainnamen. Auch hier gilt: First come – first served.
Wir einigen uns auf Freischaltung zum Dienstag, 20.10.2009, 12:00 Uhr MESZ. Ein
Eil-Newsletter ist zu formulieren. Alle anderen Projekte sind zurückzustellen.
Freitag, 16.10.2009, 14:43 Uhr
Eine erste interne Testversion für das Vormerk-Formular und die zugehörige
Datenbankstruktur ist fertig. Es soll ab Montag für die Kunden sichtbar sein.
Währenddessen erfolgen erste Entwicklungsschritte für die Teilnahme am DENIC-Landrush.
Die Registrierung soll per SMTP via PGP-signierter E-Mails im MRIv2-Format erfolgen. Wir
benutzen schon lange nicht mehr die SMTP-Schnittstelle der DENIC, sondern
die Echtzeitschnittstelle RRI (XML per dediziertes TCP-Protokoll).
Es gilt also zunächst, MRIv2 zu lernen. Die technische Dokumentation wird studiert:
Wie müssen die Antrags-Mails genau aussehen?
Freitag, 16.10.2009, ca. 16:00 Uhr
Die ersten MRIv2-Mails werden erfolgreich abgesetzt und verarbeitet, zunächst einfach
Updates für bestehende Test-Domains. Unser PGP-Key funktioniert, man muss aber bei IDN-Domains mit dem Encoding aufpassen.
Wir werden alle Vormerkungen mit festen Kontakt-Handles und einer festen Delegation auf
DENIC-Nameserver absetzen um überflüssige Probleme zu vermeiden. Erfolgreiche
Registrierungen können später auf die gewünschten Eintragungen geändert werden.
Also ist wenigstens schon mal klar, wie die Anträge genau auszusehen haben.
Währenddessen ist eine heiße Diskussion auf der Mitgliederliste entbrannt.
Wieso, das BGH-Urteil sei doch schon 29.09.2009 gefällt worden? Achso, es war dem
BGH-Anwalt der DENIC am 15.10.2009 offiziell mitgeteilt worden.
Die technische Dokumentation zum geplanten Landrush wird nun beinahe beinahe stündlich
geändert. Allseits herrscht Verwirrung. Wo soll man hinsenden? Was ist mit einer
Test-Umgebung? Wie ist die zu erreichen und ab wann? Und wie genau ist die Policy
für das Einliefern der Mails nun überhaupt zu verstehen? Eine dedizierte IP-Adresse
pro Mitglied und dann maximal 4 Mails pro Minute. Aber was heißt das genau?
Montag, 19.10.2009, 10:00 Uhr
Unsere dedizierte IP-Adresse für die Teilnahme am Landrush wird angemeldet.
Damit können wir am Testbetrieb teilnehmen.
Auf der Mailingliste toben mittlerweile erbitterte Auseinandersetzungen und
verwirrte Nachfragen. Gleichzeitig werden allenthalben juristische Schritte
angedroht, befürchtete Übervorteilungen angeprangert und Details des SMTP-Protokolls
diskutiert.
Montag, 19.10.2009, ab 16:00 Uhr
In der Dokumentation wird verwirrenderweise explizit auf die Möglichkeit
des SMTP-Pipelinings hingewiesen, obwohl das doch allenfalls dazu dienen
kann, die selbe Mail an verschiedene Empfänger in einem Bulk abzusenden? Das
ist hier sinnlos, denn man müsste stattdessen verschiedene Mails möglichst schnell
an den selben Empfänger absenden. Tatsächlich ergeben erste Tests, dass man
scheinbar nichteinmal mehrere Mails innerhalb der selben TCP-Connection absetzen kann:
"421 too many messages in this connection"
Insgesamt ist unklar, wie genau die ACL funktioniert. Teilweise kann man mehr
als 4 Mails pro Minute absetzen, dann auch wieder weniger, möglicherweise je
nachdem wie viele Versuche man unternimmt.
Eine diesbezüglich Anfrage an den DENIC-Support wartet vergebens auf Antwort.
Dienstag, 20.10.2009, 10:00 Uhr
Unser Vormerk-Formular wird einem firmeninternen Landrush-Test unterzogen. Keine
technischen Probleme.
Dienstag, 20.10.2009, 12:00 Uhr
Unser Vormerk-Formular wird für die Kunden freigeschaltet. Innerhalb weniger Sekunden gehen
ca. 25.000 Anfragen ein, während wir ängstlich beobachten, wie die CPU des Webservers
an der Decke klebt. Nach einigen Minuten beruhigt sich die Lage. Wir haben zunächst
ungeprüft alles angenommen, um nur ja nicht berechtigte Anfragen fälschlicherweise abzulehnen.
Das wäre im Nachhinein nicht mehr gut zu machen, da die Reihenfolge dann nicht mehr klar wäre.
Nach Bereinigung von Dopplern und ungültigen Domainnamen bleiben ca. 2500 Vormerkungen
übrig.
Dienstag, 20.10.2009, 13:39 Uhr
Offenbar ist sich DENIC selbst noch nicht völlig im Klaren darüber, was genau mit 4 Mails
pro Minute gemeint sein soll:
"[...] Derzeit arbeiten wir an der Optimierung der Mail-ACL.
Bitte beachtet, dass es dadurch zu Anpassungen kommen kann, die Ihr zeitnah
berücksichtigen müsst. [...]"
Unabhängig von der ACL ist jedenfalls klar, dass es im zu implementierenden
Algorithmus für unser Landrush-Tool vor allem auf zwei Dinge ankommt:
Möglichst exakte Startzeit (welcher Zeitpunkt innerhalb des SMTP-Dialogs zählt?)
Während des Laufs möglichst wenig Domains zu beantragen, deren Nichtverfügbarkeit
bereits ermittelt werden kann.
Wir lassen also zwei Threads parallel laufen, einen der versucht, die Mails aus der Queue
(nach welcher Strategie auch immer) abzusenden, und einen, der parallel durch vorausschauendes
Prüfen der Verfügbarkeit erfolglose Anträge markiert.
Dienstag, 20.10.2009, 19:42 Uhr
DENIC gibt erstmals exakte Informationen über die Realisierung der ACL bekannt. Insbesondere
wurde der Algorithmus vom bisher verwedeten
"Sliding-window Verfahren",
das auf in undurchsichtiger Weise aufgrund extrapolierter Sendegeschwindigkeit berechneten Zeitfenstern beruhte,
umgestellt auf das sog. "Rate-limiting Verfahren nach dem Token-bucket Algorithmus".
Demnach sollen tatsächlich immer maximal 4 Mails pro echter Zeitminute angenommen werden, unabhängig
von der Anzahl der Sendeversuche.
Mittwoch, 21.10.2009, 08:00 Uhr
Eigentlich wollten wir heute zum technischen Meeting der DENIC nach Frankfurt fliegen.
Zwei Flüge waren lange gebucht und werden nun verfallen. Keine Zeit für Meetings.
Mittwoch, 21.10.2009, 08:55 Uhr
Wir nehmen erstmals an einem Massentest teil. Wie im geplanten Livebetrieb wird der
Mailserver bereits um 08:55 gestartet, und Mails vor 09:00 Uhr werden zunächst
angenommen und dann mit einer entsprechenden Fehlermeldung beantwortet.
Diese Vorgehensweise ist für den Landrush-Programmierer angenehmer als die sonst häufig
angewandte Methode, erst ab Startzeit Connections zu akzeptieren, da man hierbei leicht
in einen Timeout zur Startzeit schlittern kann und sich dieses Verhalten
außerdem nur schwer simulieren lässt. Überhaupt hat dieser Landrush mehr etwas von einem
raffinierten Strategie-Spiel als die sonst üblichen Massensprints, wo es gilt, parallel
mit maximal vielen Connections auf den Server einzuprügeln.
Mittwoch, 21.10.2009, 09:00 Uhr
Überraschend am Massentest gegenüber dem üblichen Testbetrieb ist zunächst, dass der Mailserver
offenbar vor dem Ansturm von weniger als 300 Mitgliedern mit je einer Connection
ziemlich in die Knie geht. Die 4-Mails/Minute-Policy stellt sich als Farce heraus, da
sich die SMTP-Dialoge dermaßen schleppend hinziehen, dass einzelne Mails schon 20-30
Sekunden brauchen.
Auffallend ist außerdem, dass wiederholt Connections abgelehnt werden:
"421 Too many concurrent SMTP connections from this IP address",
Obwohl die vorherige Connection durchaus geschlossen und auch die Schließung durch
den Server bestätigt worden war.
Mittwoch, 21.10.2009, 10:08 Uhr
Die ersten Antwortmails des Registrierungssystems treffen nach knapp einer Stunde ein.
Mitglieder berichten von unerwarteten Antworten wie etwa
"ERROR: 56000000013 Technical error"
und anderen sonderbaren Phänomenen. Die Datenbank scheint auch vor dem Test nicht oder
nur teilweise zurückgesetzt worden zu sein. Irgendwas scheint da gehörig gegen die
Wand zu laufen.
Mittwoch, 21.10.2009, 10:08 Uhr
DENIC kündigt einen weitereren Massentest für 15:00 Uhr an.
Mittwoch, 21.10.2009, ab 11:00 Uhr
In diesem Test haben wir keine einzige interessante Domain abbekommen. Wir werden die Zeit bis zum
Nachmittag nutzen, um den zweiten Thread zur Prüfung der Verfügbarkeit hinzuzufügen.
Die Verfügbarkeit von Domains ermitteln wir per RRI-Abfrage. Das scheint etwas effizienter
und zuverlässiger als whois zu sein.
Bei noch verfügbaren Domains, die nicht den bisherigen DENIC-Richtlinien entsprechen,
antwortet DENIC mit einem Fehler bzgl. des Domainnamens:
Invalid format of value for keyword "Domain"
Somit interpretieren wir jede Antwort, die nicht besagt, dass die Domain vergeben ist,
als "verfügbar".
Mit Hilfe einer speziellen Test-Tabelle, die zufällig verteilt einerseits die ein- und zweistelligen,
und andererseits garantiert verfügbare Nummerndomains enthält, lässt sich der Parallelbetrieb
von Abfragen und Senden auch außerhalb der Massentests testen, da somit eine gemischte Queue
von vergebenen und freien Domains zur Verfügung steht. Unser Abfrage-Thread sucht vor jedem
Sende-Intervall vier freie Domains aus der Liste, und zwar möglichst knapp vor dem Sendefenster,
um eine möglichst hohe Zuverlässigkeit des Ergebnisses zu gewährleisten. Fraglich bleibt natürlich,
wie aktuell die Antwort überhaupt ist.
Mittwoch, 21.10.2009, 15:00 Uhr
Startschuss Massentest, die Zweite. Wir sind jetzt gut aufgestellt.
Da für den Eingangszeitstempel der Abschluß des DATA-Commands entscheidend ist,
sollte der erste SMTP-Dialog vor der eigentlichen Startzeit begonnen werden.
Unklar ist allerdings, welcher Zeitpunkt zwischen dem Senden des abschließenden "."
am Ende des DATA-Commands und der Antwort des Servers am Ende zählt, zumal diese
Zeitspanne ungewöhnlich groß ausfällt. Hier sind es ganze 6 Sekunden und wir
bekommen das abschließende "250 OK" gut 5 Sekunden nach 15:00 Uhr, das ist
vermutlich viel zu spät, um eine Chance auf die ersten Namen zu haben.
Mittwoch, 21.10.2009, 15:08 Uhr
Umso erstaunlicher, dass die ersten Mails mit "Too early" beantwortet werden,
das heißt, sie sind beim Server vor 15:00 Uhr angekommen?
Dann kommt noch ein "Too early" und noch eins. Entsprechende Proteste auf der
Mailingliste machen schnell klar: Der Test ist serverseitig fehlgeschlagen,
alles wird mit "Too early" beantwortet.
Mittwoch, 21.10.2009, 15:41 Uhr
DENIC entschuldigt sich: Der Startschuss war versehentlich in den November verlegt worden.
Ein erneuter Massentest wird für 16:00 Uhr angekündigt.
Mittwoch, 21.10.2009, 16:00 Uhr
Startschuss Massentest, die Dritte. Diesmal kommen zwar keine "Too early"-Antworten,
dafür werden aber fortwährend Verbindung abgwiesen:
421 Too many concurrent SMTP connections from this IP address; please try again later.
Das ist merkwürdig, da wir definitiv für jede Mail eine eigene Connection öffnen
und schließen. Es dauert dann jeweils bis zu einer Sekunde, bis eine neue Verbindung
hergestellt werden kann. Es scheinen sich serverseitig verschiedene Dienste
zeitweilig uneins über das Bestehen einer Connection zu sein.
Fazit: das Verhalten des Servers ist ausgesprochen indeterministisch und man hat
den Eindruck, dass sich das Registrierungssystem durchaus in einer eher frühen
Entwicklungsphase befindet und die Tests nicht nur der Entwicklung der Clients,
sondern auch des Servers dienen.
Die wichtigste Beobachtung ist aber, dass wir immernoch zu viele Mails vergebens absenden,
da die Verfügbarkeitsprüfung während der Massentests erheblich langsamer voran
kommt als im Normalbetrieb. Unsere Prüfschleife sucht sich aus der Queue stets
die 4 nächsten freien Domains heraus, wofür im Normalbetrieb etwa 4 Sekunden, unter
Massentestbedingungen aber bis zu 20 Sekunden nötig sind.
Mittwoch, 21.10.2009, 19:06 Uhr
DENIC kündigt für den morgigen Tag nun doch noch zwei weitere Masentests an, um
9:00 Uhr und um 13:00 Uhr.
Dieser Abend wird genutzt, um die Strategie der Verfügbarkeitsabfrage zu verbessern.
Wir werden nicht mehr, wie bisher, ab einem bestimmten Zeitpunkt vor Beginn des
nächsten Sendefensters nach 4 freien Domains suchen, sondern den Thread praktisch
pausenlos immer wieder von vorne nach freien Domains suchen lassen. Damit werden
die als nächstes anstehenden Domains zwar immer wieder erneut geprüft, aber das
Prüfintervall bleibt dabei unabhängig von dem praktisch unkalkulierbaren
Sendefenster.
Die zweite Baustelle ist der exakte Startzeitpunkt. Eigentlich müsste man, um den
extrem zeitkritischen Start optimal abzupassen, den SMTP-Dialog direkt programmieren,
so dass man mit der ersten Mail hinreichend früh beginnt und das abschließende "."
am Ende des DATA-Commands bis zur exakten Startzeit hinauszögern kann. Dafür ist aber
die Zeit zu knapp, und die von uns benutzte SMTP-Library unterstützt natürlich
nicht ein so spezielles Timing.
Der Arbeitstag dauert heute bis 23:00 Uhr und wird morgen um 8:00 Uhr beginnen.
Donnerstag, 22.10.2009, 08:00 Uhr
Vorbereitung auf den heutigen ersten Massentest. Auf der Mitgliederliste werden
weiterhin Detailfragen des ACL diskutiert und von einigen eine Verschiebung
des Registrierungstermins gefordert.
Donnerstag, 22.10.2009, ab 09:00 Uhr
Der Massentest startet. Der SMTP-Server scheint nun noch langsamer als gestern
zu reagieren. Außerdem wird ungefähr jede 3. Mail mit "Too many concurrent SMTP connections"
abgelehnt. Beim Beobachten des Logfiles ist man im Grunde froh, überhaupt einige
Mails einliefern zu können.
Donnerstag, 22.10.2009, 09:56 Uhr
DENIC räumt ein, dass das Problem der abgwiesenen Connections reproduzierbar ist:
"[...] Unsere Tests haben ergeben, dass der entsprechende Prozess zum Beenden der
Connection unter Last länger dauert als gewohnt. Nach Aussen wird die Connection
zwar als geschlossen bestätigt - der Mailserver ist aber tatsächlich noch beim
schliessen. [...]" [sic]
Man soll es eben dann immer wieder neu versuchen, bis man wieder eine
Connection bekommt.
Donnerstag, 22.10.2009, 10:10 Uhr
DENIC gibt Messergebnisse zum Massentest bekannt. Es wurden von insgesamt 156
verschiedenen IP-Adressen aus pro Minute bis zu 3422 Versuche zur Mailannahme
registriert. Wenn von jeder IP nur 4 Mails pro Minute eingeliefert würden,
käme man nur auf 624.
Natürlich versucht wohl niemand mehr, nur noch 4 Mails pro Minute abzusetzen,
nachdem man gemerkt hat, dass einerseits außerhalb der Masentests teilweise durchaus
auch mal 5 oder 6 Mails in einer Minute angenommen werden und andererseits
das Einliefern einer einzigen Mail während der Massentests bis zu 20 Sekunden
dauern kann.
In Anbetracht dessen, dass der für 13:00 Uhr angekündigte Test voraussichtlich der
letzte sein wird, lässt die Ankündigung, das Serversystem "weiter zu optimieren"
auf nichts Gutes hoffen. Man wird sich womöglich erneut auf ein verändertes Verhalten
des Servers einstellen müssen, ohne weitere Gelegenheit zum Testen zu haben. Um 15:00 Uhr
soll das Testsystem dann ganz abgeschaltet werden. Aber niemand will Änderungen implementieren,
die man nicht mehr testen kann.
Donnerstag, 22.10.2009, 12:51 Uhr
DENIC lässt ein neues Statement zum 4-Mails/Minute-ACL verlauten:
"[...] hochgezählt wird zu dem Zeitpunkt, wenn der Envelope der
Mail geschrieben wurde."
Leider können ja offenbar mehrere Sekunden zwischen Abschluss
des DATA-Commands und der folgenden Bestätigung "250 OK" vergehen. Wann innerhalb dieser
Zeitspanne nun der Envelope geschrieben wird, ist für den Client nicht feststellbar.
Ein exaktes Timing bzgl. des ACL ist somit schlichtweg unmöglich. Man muss
hintereinander versuchen, Mails loszuwerden, egal ob zwischendurch Connections
abgewiesen werden oder die Einlieferung per ACL abgelehnt wird, anders geht es nicht.
Donnerstag, 22.10.2009, 13:00 Uhr
Der letzte Massentest startet. Wir haben unsere Startzeit diesmal um 2 Sekunden
zurückgesetzt, um den richtigen Startzeitpunkt wenigstens ungefähr auszuloten.
Sollte der erste Antrag mit "Too early" beantwortet werden, so werden wir auf
den vorherigen Wert zurückschwenken.
Es wird sofort klar: Diesmal kommt überhaupt keine Connection zustande. Der
Server meldet kein Banner, offenbar werden alle Connections bereits
firewallseitig abgelehnt.
Donnerstag, 22.10.2009, 13:06 Uhr
Der Abbruch des Massentests wegen Netzwerkproblemen wird bekanntgegeben. Ein
neuer Test wird für 14:00 Uhr anberaumt.
Donnerstag, 22.10.2009, 13:48 Uhr
Der für 14:00 Uhr geplante Massentest wird wegen der noch bestehenden Netzwerkproblematik
abgesagt.
Donnerstag, 22.10.2009, 14:42 Uhr
DENIC meldet, dass ein Versuch, das Problem der abgelehnten Connections
zu umgehen, gescheitert ist. Es wird auf die bei den vorangegangen Tests
benutzte Konfiguration zurückgegriffen.
Nun sollen noch zwei Massentests um 15:30 Uhr und um 16:30 Uhr stattfinden.
Donnerstag, 22.10.2009, 15:26 Uhr
DENIC gibt bekannt, dass der Test um 15:30 Uhr nicht starten kann, weil
zusätzlich Zeit für das Zurückgehen auf die frühere Lösung benötigt wird.
Über den neuen Zeitplan soll zeitnah informiert werden.
Donnerstag, 22.10.2009, 15:55 Uhr
DENIC gibt den weiteren Zeitplan bekannt: Neue Massentests um 16:30 Uhr und um 17:00 Uhr.
Abschaltung der Testumgebung um 17:30 Uhr.
Donnerstag, 22.10.2009, 16:33 Uhr
Der nächste Versuch ist gestartet. Das Einliefern der Mails funktioniert jetzt
wieder, dauert aber teilweise über 30 Sekunden.
Wir brechen nach kurzer Zeit ab, um unsere Testumgebung für den letzten Test um
17:00 Uhr rechtzeitig zurücksetzen zu können.
Donnerstag, 22.10.2009, 17:00 Uhr
Der letzte Test ist gestartet. Wir haben nun den Startzeitpunkt so weit zurückgesetzt,
dass mehrere Anträge mit "Too early" beantwortet werden, woraus sich nun ungefähr der
bestmögliche Startzeitpunkt erraten lassen sollte.
Freitag, 23.10.2009, 08:00 Uhr
Noch eine Stunde bis zum Start. Unser Tool wird auf Livebetrieb umgestellt.
Es kommt jetzt nur noch darauf an, vor Aufregung ja keine Einstellung
zu übersehen. Es muss die richtige Startzeit eingestellt sein,
die richtige Datenbank geladen und der richtige Server angesprochen werden.
Mit Hilfe eines vorbereiteten Tools werden für die anstehenden Aufträge die PGP-signierten
Auftragsmails generiert, die später abgesendet werden müssen.
Freitag, 23.10.2009, 08:30 Uhr
DENIC meldet, dass die Domains e.de, f.de, g.de, x.de, y.de, z.de, br.de, dw.de, hr.de und sr.de
aufgrund kurzfristig zugestellter einstweiliger Verfügungen von der Registrierung
ausgenommen sind.
Gerade noch früh genug, um diese Aufträge in der Datenbank als gesperrt zu markieren.
Freitag, 23.10.2009, 08:38 Uhr
DENIC gibt bekannt, dass nicht nur vw.de, sondern auch o2.de aufgrund von
Gerichtsentscheidungen bereits registriert wurden.
Freitag, 23.10.2009, 08:55 Uhr
Letzte Prüfung der Checkliste. Die Konfiguration ist auf den Livebetrieb umgestellt.
Die automatische Synchronisierung mit fremden Zeitgebern ist angehalten, damit die
Systemzeit ausschließlich durch den NTP-Server der DENIC synchronisiert wird.
Der Domain-Robot, sowie alle Dienste, die gewöhnlich RRI-Connections mit DENIC
aufbauen, sind angehalten, denn nur nur eine einzige RRI-Connection ist zugelassen.
Freitag, 23.10.2009, 08:57 Uhr
Unser Tool wird gestartet. Es lädt sich den Inhalt der Datenbanktabelle in den RAM,
baut die TCP-Connection zum Mailserver auf und wartet von da an auf den Startzeitpunkt.
Das Rauchverbot im Entwicklerbüro wird vorübergehend aufgehoben.
Freitag, 23.10.2009, 08:59 Uhr
Gespannt wird der Beginn des ersten SMTP-Dialogs auf der Konsole mitgelesen. Die
Einleitung des DATA-Blocks erfolgt eine halbe Sekunde vor 9:00 Uhr:
2009-10-23 08:59:59,449 >> RCPT TO:<auto@nd.denic.de>
2009-10-23 08:59:59,459 << 250 Accepted
2009-10-23 08:59:59,479 >> DATA
2009-10-23 08:59:59,520 << 354 Enter message, ending with "." on a line by itself
Freitag, 23.10.2009, 09:00 Uhr
Es dauert 6 Sekunden bis zur Bestätigung des ersten DATA-Blocks. Mit der ersten
Domain werden wir somit wohl kaum durchkommen, aber wären wir früher gestartet, hätten
wir genausogut leicht in das "Too early" laufen können. Ein Glücksspiel, wie
so oft im Leben dann leider doch mal wieder ohne Hauptgewinn.
Alles Weitere ist ein Automatismus. Zäh wird Auftrag um Auftrag abgesetzt, während
30 Sekunden nach 9 Uhr planmäßig der zweite Thread startet, um parallel die
nächsten Domains auf Verfügbarkeit hin zu prüfen.
Die Unwägbarkeiten bei diesem Rennen sind groß. Beispielsweise bleibt unser Antrag
auf die Domain 1.de, den wir um 09:00:42 absetzen, erfolglos, obgleich um 09:00:38
noch die Verfügbarkeit dieser Domain bestätigt wurde. Wieviel Zeit zwischen dem
Entgegennehmen eines Auftrags und der eigentlichen Registrierung einer Domain mitsamt
Anzeige im RRI auf DENIC-Seite vergeht, weiß niemand.
Freitag, 23.10.2009, 09:02 Uhr
Wie man später erfahren wird, sind zu diesem Zeitpunkt bereits 85 Domains registriert,
d.h. das eigentliche Rennen um die wichtigen Namen ist so gut wie gelaufen. Dennoch
werden noch alle Domains als verfügbar angezeigt. Erstmals um 09:02:34 wird eine
Domain mit Status "connect" angegeben.
Das Rennen um die hinteren Plätze wird noch den ganzen Tag über andauern.
Unter dem Strich sind wir zu 8% mit unseren Aufträgen erfolgreich. Das ist keine so
schlechte Quote. Andere Mitglieder waren dadurch erfolgreicher, dass sie sich zu
Pools zusammengeschlossen und ihre Listen untereinander optimiert haben. Davon
abgesehen waren die Bedingungen für alle Mitglieder im Wesentlichen gleich schwierig.
Die Gewinner der ganzen Veranstaltung sind ohnehin Sedo und vor allem die Rechtsanwälte,
die nun in ihr eigenes Rennen einsteigen können. Noch im Laufe des Tages wird z.B.
bekannt, dass in einem kleinen Haus mit vielen Briefkästen irgendwo in Florida
plötzlich erstaunlich viele Firmen mit ein- und zweistelligen Initialen gegründet wurden.
Und andere Geschichten.
Unser Rennen haben wir gewonnen, denn wir haben aus den Gegebenheiten
das Bestmögliche gemacht. Alles Weitere wäre Glück gewesen.
did they change their api or what? did I miss something? 8-{
Today my good old paypal ipn script failed to post back to www.paypal.com/cgi-bin/webscr in order to verify a payment notification as usual. Strange! They said:
HTTP/1.1 301 Moved Permanently
It seems they are expecting the payment parameter as a GET query now,while I sent data by POST until now. It worked fine until yesterday. Urgh, it's about money, so I've to check this out promptly.
Well, my script is too old and too simple to handle 301 automatically, but fortunately it's clever enough to report the error.
)
