Aus dem Rechenzentrum

Hin und wieder haben wir Gelegenheit, einige Domains von anderen Providern zu übernehmen, und wenn jene kooperativ sind, bekommen wir die bestehenden DNS-Zonendateien bereitgestellt. Umgekehrt tun wir das genauso; das ist einfach ein Zeichen guten Stils. Wenn eine Domain wegziehen soll, dann ist die Entscheidung ja schon gefallen; da muss man dem Kunden und dem neuen Provider ja nicht absichtlich Knüppel zwischen die Beine werfen, in dem man ihm die Übernahme der DNS-Daten künstlich erschwert.

Bei den meisten Domainübernahmen zu uns bekommen wir BIND-Zonendateien. Wie vielleicht schon bekannt ist, setzen wir jedoch tinydns als DNS-Server ein. Besteht die Möglichkeit, Zonen per AXFR zu übernehmen, so bevorzugen wir dies, aber gängiger ist, dass wir ein Bündel BIND-Zonen einfach zugemailt bekommen.

Gut, dass Dan Erat das Tool bind-to-tinydns geschrieben hat, das BIND-Zonen interpretieren und ins tinydns-data-Format übertragen kann. Es erwartet seine Eingabe auf STDIN und schreibt das Ergebnis in eine Datei. Dabei werden entsprechend ein SOA-Record („Z“) und mehrere NS-Records („&“) angelegt, was nun entsprechend noch geändert werden muss: Wir bevorzugen, die NS-Records mit „.“-Syntax anzulegen, wobei tinydns dann automatisch einen SOA konstruiert. Und so machen wir’s:

for FILE in hosts.* ; do
  ZONE=`echo $FILE | sed 's/^hosts\.//'` ;
  cat $FILE | bind-to-tinydns $ZONE $ZONE.pre $ZONE.tmp ;
  rm -f tinydns/$ZONE ;
  for NS in 1 2 3 ;
    do echo ".$ZONE::ns$NS.jonaspasche.com" >> tinydns/$ZONE ;
  done ;
  grep -v -E "^(Z|&)$ZONE\.?:" $ZONE.pre >> tinydns/$ZONE ;
done

Sprich: Da die Dateien alle im Format hosts.domain.tld benannt sind, ziehen wir uns den Namen der Zone aus dem Dateinamen. Wir konvertieren die Zone mit bind-to-tinydns in eine $ZONE.pre (die noch die ursprünglichen SOA-/NS-Angaben trägt); anschließend legen wir in einer Schleife die drei neuen NS-Records an und fügen schließlich den Inhalt der konvertierten Zone ein, wobei wir den SOA und die bisherigen NS-Delegationen weglassen. Dabei achten wir darauf, nur die NS-Records der Zone selbst wegzulassen – andere „&“-Einträge, die sich auf Subdomains beziehen (die damit auf andere Nameserver delegiert werden), bleiben natürlich bestehen.

Schließlich haben wir im Verzeichnis tinydns fertige Zonendateien liegen, angepasst auf unsere DNS-Server. Das war’s auch schon!

Direkt vorab: Unsere Bitte um Entschuldigung gibt’s weiter unten. Für die technisch Interessierten aber erstmal die Hintergrundgeschichte.

Ein durchaus angenehmes Feature von tinydns, den von uns eingesetzten DNS-Server, ist die Möglichkeit, Wildcard-Records im DNS zu definieren. So legen wir für die meisten Hosts standardmäßig an:

+domain.tld:1.2.3.4
+*.domain.tld:1.2.3.4

Mit letzteren sind dann alle Varianten von www.domain.tld über ftp.domain.tld bis zu admin.domain.tld automatisch abgedeckt. Sollen einzelne Subdomains davon abweichen, definitiert man sie einfach separat:

+admin.domain.tld:1.2.3.5

So löst admin.domain.tld korrekt auf 1.2.3.5 auf; irgendwas.domain.tld aber weiterhin per Wildcard auf 1.2.3.4. So weit, so gut. Die Dokumentation von tinydns-data formuliert dies so:

Information for *.fqdn is provided for every name ending with .fqdn, except names that have their own records

Nun, ich hätte wohl auch das zweite darunterliegende Beispiel lesen sollen, und zwar sehr genau. Es verrät nämlich im Vorbeigehen eine wichtige Falle, über die wir heute gestolpert sind. Unser bisheriges Verständnis ließe sich etwa so formulieren:

Gibt es für den Hostnamen H einen Record vom Typ T, so übergeht dieser alle Wildcard-Records, die ansonsten auf den Hostnamen H und den Typ T gepasst hätten.

Leider ist das ein Irrtum. Die korrekte Formulierung muss nämlich heißen:

Gibt es für den Hostnamen H einen Record irgendeines Typs, so übergeht dieser alle Wildcard-Records, die ansonsten auf den Hostnamen H und irgendeinen Typ gepasst hätten.

Nicht sofort verstanden? Kein Problem. Konkretes Beispiel. Wir hatten in unserer data-Datei Folgendes stehen:

+*.jonaspasche.com:82.98.82.13

Hinter der IP 82.98.82.13 steht einer unserer Server namens wally, der mit vollständigem Namen also wally.jonaspasche.com heißt. Über obigen Wildcard-Record wurde er immer schon korrekt aufgelöst.

Nun hat mein Kollege Christopher heute SSHFP-Records angelegt, so dass nun folgendes in der data-Datei stand:

+*.jonaspasche.com:82.98.82.13
:wally.jonaspasche.com:44:[...]

Und nun die Falle: Fragt man den DNS-Server nun nach dem A-Record von wally.jonaspasche.com, liefert er nichts mehr zurück. Die dahinterstehende Logik ist laut (nun endlich richtig verstandener) Dokumentation: Da es irgendeinen Record gibt, der spezifisch für den Hostnamen wally.jonaspasche.com gilt (nämlich den SSHFP-Record), werden alle ansonsten auf eine Anfrage im Prinzip passenden Wildcard-Records ignoriert, und zwar unabhängig davon, ob sie auch zum gewünschten Typ des angefragten DNS-Records passen oder nicht.

Das finde ich persönlich absolut nicht intuitiv, und ich bin noch nicht ganz mit mir übereingekommen, ob ich es zumindest jetzt, wo ich es verstanden habe, zumindest sinnvoll finde. Ich tendiere zu nein. Aber ich muss zähneknirschend zugeben, dass es eben kein Bug ist, sondern dokumentiert ist – nur wenngleich eben so, dass die entsprechende Stelle missverständlich ist und man schon das Beispiel mit dem Nachsatz sehr genau interpretieren muss.

Da war ich doch fast schon der Meinung, in Sachen tinydns nun wirklich schon seit Jahren ein alter Hase zu sein, dem man so schnell nix mehr vormacht. Denkste. Aber es ist sicherlich nicht das Schlechteste, das eigene Wissen durchaus auch nach Jahren ruhig nochmal hinterfragen zu lassen.

Es tut uns leid.

Wir bitten alle Kunden um Entschuldigung, die aufgrund dieses Vorfalls vorübergehend Probleme mit dem Abruf und Versand von E-Mails hatten. Ärgerlicherweise waren hierbei primär jene Kunden betroffen, die für ihre Mail-Verbindungen SSL-Verschlüsselung benutzen und daher dann auch wally.jonaspasche.com als Hostname – weil das SSL-Zertifikat auf diesen Namen ausgestellt ist. Wer als Mailserver seine eigene Domain angegeben hat, was (an sich „leider“, im konkreten Fall aber „zum Glück“) die überwiegende Mehrheit ist, dürfte keine Probleme festgestellt haben.

Nachdem wir nun den entsprechenden Erkenntnisgewinn hatten, können wir beschämt sagen: Kommt nicht wieder vor. Das nicht. Wir bitten darum, den Vorfall als positives Zeichen dafür anzusehen, dass auch wir nur Menschen und keine Götter sind. Herzlichen Dank.