Kategorie: Development

Express-DNS im Domain-Formular

Um die Wartezeit auf das neue Partnerweb zu verkürzen, hat unsere Development-Task-Force sich vorgenommen, im alten Partnerweb noch ein paar Verbesserungen vorzunehmen, bevor es in den verdienten Ruhestand gehen kann. Hierzu zählt die bereits versprochene Einbindung des beliebten Domain-DNS-Kombi-Templates zur gleichzeitigen Domain- und DNS-Verwaltung in das Domain-Bestellformular. Damit kann man nun gleichzeitig konnektieren und registrieren oder die Domain zusammen mit den Nameservern updaten, was bisher nur bei DE-Domains mit NSentries möglich war.

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:

Express-DNS Schritt 1

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)

Express-DNS Schritt 2

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:

Express-DNS Schritt 3

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:

Express-DNS Schritt 4

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:

Express-DNS Schritt 7

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! :-)

Danke für C!

Dennis Ritchie

When I read commentary about suggestions for where C should go, I often think back and give thanks that it wasn’t developed under the advice of a worldwide crowd.

Dennis Ritchie hat sich unsterblich gemacht.

Domain-Robot meets DNS

Die http.net arbeitet ja ständig an der Verbesserung ihrer Schnittstellen. Und immer, wenn das Wetter uns nicht an den Strand lockt (oder die Getränke Supportanfragen ausgegangen sind), dann sitzen wir natürlich im Büro und überlegen, wie wir unseren Partnern ihre Arbeit noch weiter erleichtern können. Ja, so sind wir ;-)

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!

etwas backorder background

Backordern ist eine sportliche Angelegenheit. Es läuft ungefähr so:

Jede Nacht holen wir uns von der Registry die Liste mit den Domains ab, die 5 Tage später freigegeben werden. Das sind jeden Tag so an die 80.000 Namen, von denen 99.99% vollkommen uninteressant sind (adultentertainermedicals.com, …). Ein paar wenige schöne Namen sind aber oft dabei, so etwa verteilt wie die vierblättrigen Kleeblätter auf einer Kuhwiese.

Unser neuer Suchagent (powered by: EM) bietet die Möglichkeit, auf einen bestimmten Namen zu warten oder sich über freiwerdende Namen, die einem gegebenen Muster entsprechen, täglich informieren zu lassen. Jedenfalls, sobald die Domains in unserer Datenbank stehen, können sie bestellt werden.

Am Stichtag um 2 Uhr PM EST fängt die Registry an, die Domains freizugeben. Das zieht sich so 2 Stunden hin und es kommt darauf an, derjenige zu sein, der in genau der Millisekunde einen Auftrag für die Domain sendet, in der sie frei wird. In diesem weltweiten Bonbonregen treten jeden Tag Hunderte von Registraren an, Grabber und Snapper, die Giganten der Branche und neuerdings auch ein ambitionierter Berliner Provider.

Also, hier sind schon Ellenbogen gefragt. Unser Client läuft momentan in 4 Instanzen auf 2 Servern mit jeweils 5 bis 10 Threads, je nach Auftragsmenge. Jeder Thread öffnet in dem relevanten Zeitfenster eine persistente TCP-Session und sendet für die bestellten Domains 3 bis 4 REG-Aufträge pro Sekunde ab, bis entweder die Domain registriert oder die Zeit um ist. In der Praxis ist damit insgesamt ein durchschnittliches Intervall von ca. 20-30 Aufträgen pro Sekunde zu erreichen. Die Aufgabe ist nicht völlig trivial, da die Registry mehrere Pools unterschiedlicher Priorität mit jeweils einer begrenzten Anzahl paralleler Connections zur Verfügung stellt, von denen ein Teil für den Normalbetrieb garantiert sein muss.

Meistens klappt’s auch, aber leider nicht immer. Testläufe haben etwa eine Erfolgsquote von gefühlt 80% bei einigermaßen interessanten Namen ergeben. Statistische Aussagen dieser Art sind jedoch so schwierig wie die Frage nach dem Wert eines Domainnamens. Das ist also ein schönes Hobby, und den Programmierern kann endlich nicht mehr nachgesagt werden, zu wenig Sport zu treiben… ;)

Wir kennen das sicherlich alle:

Es gibt da eine SOAP-Schnittstelle, mit der man unbedingt etwas klären muss.
Menschen haben es da etwas schwerer als Rechner.

Also dann, man nehme sich kurzerhand einen solchen (Computer) und entscheide, welche Sprache man heute sprechen möchte. Heute, was bei mir eigentlich gestern war, fiel die Wahl auf Python.

Zum Schreiben eines SOAP-Clients bietet sich nach kurzer Befragung des Internet der Inhaber eines äußerst themengerechten, netten Logos an: SUDS

Alles ist etwas simpler, als es am Anfang scheint, nicht umsonst ist der erste Satz auf der offiziellen Seite dieses Frameworks, ich zitiere:

„Suds is a lightweight SOAP python client for consuming Web Services.“

Nicht wesentlich unterhalb dieses Satzes gelangt man auf eine nette “Getting Started”-Doku, die eigentlich alles enthält, was man sich für solch einen Einstieg erwünscht.
Erst einmal importiert man das Framework, oder, in diesem Fall, noch etwas weniger.

from suds.client import Client

Anschließend bastelt man sich einen solchen Client und gibt ihm auch gleich die Adresse des Servers.

client = Client('https://test/foo.bar/service.asmx?WSDL')

Solch ein Server hat sehr genaue Vorstellungen von Gesprächen, daher wird er uns genau sagen, was er in welcher Form gesagt bekommen möchte. Möchte man sich das anschauen, bietet es sich an mit

print client

einen Blick auf diese Anforderungen zu werfen.

Gehen wir nun davon aus, dass wir eine Methode benutzen wollen, die neben einem ganz normalen String auch noch einen komplexen Typ verlangt, eine Authentifizierung. Diese validiert die Berechtigung des Fragestellers mittels zweier Strings, dem Benutzernamen und dem Passwort. Da unser Client den Typ schon kennt, suchen auch wir uns dessen vordefinierten Namen. (Wichtig: Es geht explizit um die Anforderung des Servers, nicht um Typen die Teil von SUDS oder Python wären!)

Nehmen wir an, sein Name ist „AuthData“ und er beinhaltet die beiden Strings „username“ und „password“

auth = client.factory.create('AuthData')

bewirkt, dass eine Variable des Types AuthData nach den Spezifikationen des Servers erstellt wird.

Mit auth.username = 'admin' und auth.password = 'geheim'
(Beispiel für unsichere Zugangsdaten)

werden die Werte gefüllt.

Die Antwort des Servers wird erst zwischengespeichert

result = client.service.HalloServer(auth, 'Hallo')

und dann zum Beispiel mit einem

print result

ausgegeben. Fertig liest sich das dann:

from suds.client import Client
client = Client('https://test/foo.bar/service.asmx?WSDL')
auth = client.factory.create('AuthData')
auth.username = 'admin'
auth.password = 'geheim'
result = client.service.HalloServer(auth, 'Guten Morgen')
print result

Wer wissen möchte, wie so etwas realistisch in Bezug auf die http.net API aussehen würde, kann das Beispiel demnächst auch als Python-Sampleclient auf der API Dokuseite wiederfinden.