Wir fahren in Bezug auf DNS-Caching eine einfache, aber sehr effektive Strategie: Alle von uns verwalteten Hosts bekommen einen lokalen DNS-Resolver. Zwar haben wir in unseren Netzen jeweils ebenfalls DNS-Resolver, die direkt mit einem Eintrag in der /etc/resolv.conf netzintern genutzt werden können, aber das brauchen wir eigentlich nur während der Installation von Systemen, die wir typischerweise via PXE-Boot und dann über das Netz machen, wofür ein fertig bereitstehender Resolver vonnöten ist. Sobald eine Maschine läuft, bekommt sie einen eigenen Resolver.…
BIND-Zonen in tinydns-Zonen konvertieren
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 …
Wildcard-Records mit tinydns
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; …
„Verfassung des Cyberspace“
Soeben bin ich in c’t 2009, Heft 21, über folgendes Zitat gestolpert, das in den aktuellen Debatten um Netzneutralität aktueller scheint denn je:
We reject: kings, presidents and voting.
We believe in: rough consensus and running code.
Es stammt von David D. Clark, Chief Protocol Architect des Internet, und schöner hätte man den Pragmatismus, der oft entsteht, wenn Entwickler unter sich sind, kaum in ein Fazit fassen können. Passend dazu lese ich heute: USA lockern Kontrolle über Internet-Verwaltung. Und …
IDNA::Punycode und die Abwärtskompatibilität
Für selfHOST haben wir vor längerer Zeit Teile des Backends entwickelt, darunter den Export von Zonen aus der Datenbank ins DNS-System. Besondere Beachtung erhielten hierbei Umlautdomains: In der Datenbank werden diese „ganz normal“, also mit Umlauten, abgespeichert; beim Export in die DNS-Daten kommt das Perl-Modul IDNA::Punycode zum Einsatz.
Das Modul stellt eine Funktion „encode_punycode“ bereit, die den Punycode-String eines Strings mit UTF8-Werten zurückliefert. Davor musste dann noch der Präfix „xn--„. Eine entsprechende Zeile Programmcode sah nun so also etwa so …
Warum kann ich keinen CNAME für eine ganze Domain definieren?
Gerade bei selfHOST immer mal wieder eine gern gehörte Frage. Mein liebste Antwort ist die von Dan J. Bernstein:
Remember the wise words of Inigo Montoya: „You keep using CNAME records. I do not think they mean what you think they mean.“ (Quelle)
Leider reagieren die meisten Leute etwas … ähem, verärgert, wenn man sich in seiner Antwort auf dieses Zitat beschränkt. 🙂
Nun gibt es eine ganze Reihe von Gründen, warum man CNAMEs am Besten gar …