Einmal kostenfreies DNS und zurück!

Im Zuge einer fälligen Konsolidierung meiner virtuellen Server wollte ich einige Dienste und Websites umziehen. Bei den Web-Sites kein Problem – ein anderer virtueller Server steht schon bereit. Jedoch lief auch noch ein Secondary DNS Server auf der bald zu löschenden VM, und zwar noch klassisch als Server-Dienste ohne Containerisierung mit Docker oder ähnliches. Nun muss man nicht alle Dienste selbst betreiben – wirklich nicht!

Vor allem, wenn es in der weiten Internet-Welt Anbieter gibt, die einem kostenfreie DNS-Dienstleistungen zur Verfügung stellen. Da die Websites auch nicht viel Traffic verursachen, gilt dasselbe für die DNS-Abfragen, wichtig war mir jedoch eine gewisse Redundanz. Denn wenn ich schon auf einen externen Anbieter zurück greife, dürfen es gerne mehr DNS-Server sein als das geforderte Minimum von zwei Servern. Bei meiner Auswahl habe ich mich insofern auf diejenigen beschränkt, die etwas mehr bieten als wenn ich selbst auf einer weiteren VM einen neuen DNS-Server betreiben würde. Ebenfalls sollte ein Unternehmen dahinter stecken, was eine gewisse Nachhaltigkeit bietet und nicht ganz neu auf dem Markt ist, denn wenn ich den DNS von einem nebenberuflichen Einzelkämpfer hosten lasse, hätte ich es auch selbst weiter betreiben können.

Anbieter kostenloser DNS-Dienste

Dankenswerterweise gibt es etliche Listen mit DNS-Anbietern, z.B. die „10 Beste Free DNS Hosting Providers“ oder „Free secondary (slave) DNS„.  Diese Hinweise waren bereits sehr wertvoll für eine erste Entscheidungshilfe. Denn manche Dienste waren weniger „free“ als auf den ersten Blick ersichtlich.

Ein Kriterium für die Auswahl war zudem, dass ich den primären DNS-Server weiterhin selbst betreiben wollte und dass wie im DNS-Protokoll vorgesehen zwischen primary und secondary Server bei Änderung eine Aktualisierung stattfinden sollte. Im besten Fall wollte ich einmalig in einer Web-UI den Domainnamen und den primary DNS eintragen müssen. Bei Änderungen müsste ich dann nur den primären Server aktualisieren, um den Rest kümmert sich das System. Daher konnte ich Anbieter wie Namecheap beispielsweise ausschließen, sie bieten zwar kostenlose DNS-Server, aber keine Möglichkeit, nur einen secondary Server zu konfigurieren. Hier hätte es „alles oder nichts“ bedeutet, d.h. ich hätte entweder komplett auf die Nameserver des Providers umstellen müssen, oder ich hätte jede Änderung im primären Server manuell in die Web-UI von Namecheap einpflegen müssen – und genau das wollte ich nicht.

Die folgende Auswahl ist völlig subjektiv und soll auch keinen umfassenden Vergleich darstellen.

BuddyNS

Zunächst einmal fiel mir BuddyNS auf. Sie bieten ausschließlich Secondary DNS Dienste an, was genau zu meinen Anforderungen gepasst hätte. Die maximale Anzahl von Anfragen pro Monat ist jedoch auf 0,3 Mio. beschränkt. Zwar dürfte dies für die meisten Anwender ausreichen, aber andere Anbieter bieten durchaus mehr bzw. keine derartige Beschränkung. Immerhin sind die Preise für „Advanced User“ transparent mittels Preisrechner ermittelbar, d.h. sofern das Limit überschritten wird, besteht die Möglichkeit, weitere Leistungen zu buchen. Zwar sind die Kosten tatsächlich nicht hoch, liegen jedoch bei mindestens drei Dollar pro Monat, was sich für mich wiederum nicht gelohnt hätte – zum Vergleich, die kleinste VM, die für den Betrieb eines DNS-Servers locker ausreichen würde, liegt bei Anbietern wie Hetzner oder Netcup liegt bei unter drei Euro pro Monat. Insofern habe ich von einer Anmeldung bei BuddyNS abgesehen.

NS1

Der nächste Anbieter, den ich in der Auswahl hatte, war NS1 („nsone“). Der „Free Plan“ umfasst immerhin 0,5 Mio. Requests, darüber hinaus gibt es eine Monitoring-UI, insgesamt wirkt die Website modern und aufgeräumt. Leider werden keine Preise genannt, falls man diese Grenze überschreitet – für ein höheres Kontingent muss der Support kontaktiert werden. Des Weiteren sind die Kontingente für primären und sekundären DNS identisch, dazu gleich mehr. Die Anmeldung war schnell durchgeführt, daraufhin konnte ich einen Secondary Nameserver einrichten. Die IP, von der die Zone-Transfers durchgeführt werden, hatte ich zuvor bei meinem DNS-Server freigeschaltet. Die angemeldete Domain wurde daraufhin mit dem Status „pending“ aufgeführt. Das Problem war – es passierte nichts. Nach einigen Minuten war der Status unverändert, ebenso nach einer Stunde. Insofern schien der Zone-Transfer schlicht und einfach nicht funktioniert zu haben. Dies bezieht sich auf das User-Interface in Version 2 – anscheinend hatte NS1 vor einer gewissen Zeitspanne eine neue Benutzerschnittstelle eingeführt. Da ich mich aber neu angemeldet hatte, sah ich zunächst keinen Bedarf, auf das vorherige UI – genannt Version 1 – zurück zu gehen. Nach einiger Zeit war ich des Wartens überdrüssig und habe die Domain wieder entfernt.

Nach weiteren Experimenten bzw. einem Problem mit den org-Domains bei einem anderen Anbieter (siehe unten) wollte ich NS1 erneut testen, und zwar mit dem Secondary DNS für eine org-Domain. Anfangs änderte sich der Status erneut nicht, d.h. es blieb bei „pending“ stehen. Spaßeshalber und ohne Erwartungen habe ich daraufhin auf das vermeintlich alte User-Interface „v1“ gewechselt. Bemerkenswerterweise wurde dort ein erfolgreicher Zone-Transfer angezeigt. Die daraufhin gestarteten DNS-Abfragen bestätigten dies. Dennoch ein seltsames Verhalten, was NS1 sich da erlaubte. Der Grund, weshalb ich dennoch NS1 nicht weiter verwende, ist die extrem niedrige Anzahl an Records im kostenlosen Kontingent. Von den maximal 50 Records waren mit einer Domain bereits neun belegt (NS-, A-, CNAME-, MX-, TXT-Records). Insofern hätte ich ca. fünf Domains anmelden können und wäre bereits an die Grenzen gestoßen. Somit war NS1 leider unbrauchbar für meinen Einsatzzweck.

CloudNS

Der nächste Anbieter CloudNS verspricht zwar drei Domains in der kostenlosen Fassung namens „Free DNS“, jedoch scheint dies nur für den vollständigen DNS-Betrieb zu gelten. Denn für den reinen Secondary DNS Betrieb gibt es zwar 30-Tage-Testversionen, aber die kleinste Fassung mit 40 DNS Zones, d.h. Domains, kosten bereits zwei Dollar pro Monat. Das ist zwar absolut betrachtet kein hoher Betrag, aber da ich den Secondary DNS Server bislang quasi nebenbei auf einer VM mit laufen ließ, war mir dies immer noch zu viel.

Cloudflare

Mit Cloudflare habe ich mich zugegebenermaßen nicht näher beschäftigt. Insgesamt wirken die Angebote recht undurchsichtig, mir wurde z.B. nicht klar, ob man dort reine DNS-Dienste bzw. nur einen Secondary DNS buchen kann, oder ob damit weitere Dienstleistungen einher gehen. Zwar verspricht Cloudflare einige DNS-Features, aber die Anmeldung bezieht sich auf eine „Website“?

FreeDNS

FreeDNS (auch freedns.afraid.org) gehört zu den Anbietern, die bereits sehr lange auf dem Markt sind. Genau das sieht man dem User-Interface auch an. Die Leistungen sind jedoch vielfältig und versprechen einiges, auch Dynamic DNS ist bei FreeDNS möglich. Jedoch soll es bei FreeDNS nur einen Nameserver geben, was meinen ursprünglichen Anforderungen an gehostete Lösungen widerspricht. Daher habe ich auch hier von einer Anmeldung abgesehen.

Hurrican Electric

Hurrican Electric gehört zu den Anbietern, mit denen man als Endanwender eher wenig in Kontakt kommt. Zumindest falls man keinen IP-Transit eines globalen Internet Backbone oder Colocation von Serverschränken benötigt. Dennoch bieten sie DNS-Leistungen, und zwar Primary sowie Secondary. Die Website versprüht den Charme der frühen 1990er Jahre, aber in diesem Fall hat mich dies nicht von einer Anmeldung abgehalten. Das Vorgehen war analog zu anderen – IP-Adresse im primären DNS-Server für den Zone-Transfer freischalten, dann die gewünschte Zone, d.h. Domain eintragen, für die der Dienstleister die Secondary DNS-Server bereit stellen soll. Nachdem ich die Domain eingetragen hatte, passierte jedoch – nichts. Zwar habe ich inzwischen herausgefunden, dass vor einer Übertragung der Zone bereits die Hurrican Electric Nameserver eingetragen werden müssen, aber bis dato war dies nicht unbedingt klar. Falls der Transfer funktioniert hätte, hätte ich die Nameserver entsprechend updated, aber da ich zuvor keine falschen Einträge in meinem Primary DNS haben wollte, hatte ich mich zunächst gegen dieses Vorgehen entschieden. Davon abgesehen ist Hurrican Electric sicherlich ein sehr guter Anbieter, aber für mich war an dieser Stelle erstmal Schluss.

1984 Hosting Company

Danach habe ich es mit 1984 Hosting Company probiert. Eigentlich dachte ich, damit den perfekten Anbieter gefunden zu haben – ein sympathischer erste Eindruck, ein isländisches Unternehmen (laut eigener Aussage das größte Hosting-Unternehmen in Island), und das scheinbar blökende Schaf auf der Website spricht für sich. Mit FreeDNS bietet 1984 Hosting umfassende DNS-Leistungen, sowohl primärer als auch sekundärer DNS und auf den ersten Blick keinerlei Beschränkungen unterlegen. Daher habe ich mich flugs angemeldet, und einen ersten Secondary DNS eingerichtet. Das Vorgehen ist analog zu den anderen Sites, die UI wirkt jedoch modern – Bootstrap CSS Framework lässt grüßen und bietet gute Hinweise zur Einrichtung. Der Zone-Transfer war diesmal erfolgreich, nach kurzer Zeit wurde der Status geändert, die jeweiligen DNS-Server zeigten „grün“, darüber hinaus ließen sich die übertragenen DNS-Daten zwecks Test anzeigen. Nachdem ich im Primary DNS ebenfalls die Nameserver von 1984 Hosting eingetragen hatte, wurden die Änderungen schnell übernommen, auch das ließ sich innerhalb der sehr benutzerfreundlichen UI leicht erkennen. Das Unternehmen bietet fünf DNS-Server an, insofern dürfte genug Redundanz vorhanden sein.

Daraufhin habe ich damit begonnen, meine Domains entsprechend einzurichten und für den Secondary DNS bei 1984 Hosting zu konfigurieren. Bei den meisten Domains funktionierte dies so problemlos wie beschrieben. Leider gab es jedoch Probleme bei der Aktualisierung der org-Domains. Aus welchen Gründen auch immer, aber die Nameserver von 1984 Hosting wurden als „unknown“ abgelehnt. Zwar konnte ich bei meinem Domainprovider Nameserver zuordnen, aber natürlich nur für eigene Domains, d.h. falls ich unter einer eigenen Domain DNS-Dienste anbieten, müssen die Nameserver zuvor registriert werden. Eine Support-Anfrage bei 1984 Hosting blieb leider unbeantwortet, und da ich nicht mehrere Anbieter für DNS-Dienste nutzen wollte, habe ich mich letztlich auch gegen 1984 Hosting entschieden.

Testweise habe ich zunächst erneut NS1 getestet – hier ließ sich die org-Domain ohne Probleme einrichten, aufgrund  der Beschränkungen habe ich jedoch von der weiteren Nutzung abgesehen.

Rolle rückwärts

Aufgrund der geschilderten Erfahrungen kam somit keiner der Anbieter kostenfreier DNS-Dienste zum Einsatz. Doch was nun? Eigentlich wollte ich ja den Secondary DNS nicht mehr selbst hosten. Schließlich hatte ich vor, die Anzahl der VMs zu verringern und nicht eine weitere Instanz nur für den DNS-Server zu erstellen.

Den primären DNS betrieb ich jedoch seit einiger Zeit völlig problemlos in einem Docker-Container, dazu verwende ich ein Docker-Image, in dem sowohl der DNS-Server bind, als auch ein dazu passender, fertig konfigurierter Webmin-Dienst vorhanden ist. Insgesamt ist dies eine recht einfache Lösung – per Webmin lassen sich sämtliche bind-Parameter konfigurieren, Domains anlegen, Records administrieren usw., und das mit einer GUI, die zwar nicht ganz anspruchslos ist, d.h. man sollte schon wissen, was die jeweiligen Einstellungen bedeuten, aber wer bind bereits per Kommandozeile eingerichtet hat, wird damit wiederum keine Probleme haben. Letztlich bietet Webmin eine Schnittstelle für die bind-Konfigurationsdateien.

Docker (mal wieder)

Zwar ist diese Docker-Lösung nun nicht explizit skalierbar, läuft normal als Docker-Container ohne Docker-Swarm-Anbindung und so weiter, aber andererseits hat rennt dieser Container als Primary DNS Server – von Aktualisierungen zwischendurch abgesehen – nun seit über zwei Jahren völlig stabil und unauffällig. Und da ich noch eine VM fertig konfiguriert mit Docker nahezu ungenutzt übrig hatte, lag es letztlich nahe, den Secondary DNS ebenfalls mit dem Bind-Container zu bestücken. Natürlich sollten primärer und sekundärer DNS nicht auf derselben Maschine bzw. VM laufen bzw. sich in unterschiedlichen Netzen befinden. Da dies der Fall war, stand dem Einsatz nichts mehr im Wege.

Letztlich wird für den Start des Docker-Containers nur ein Kommando benötigt:

docker run --name bind -d --restart=always \
--env ROOT_PASSWORD=GUTESPASSWORT \
--publish 123.123.123.123:53:53/udp \
--publish 123.123.123.123:53:53/tcp \
--publish 123.123.123.123:10000:10000 \
--volume /srv/docker/bind:/data \
sameersbn/bind

Dass diese IP-Adresse ein Beispiel ist, dürfte klar sein, und das Root-Passwort sollte entsprechend gut gewählt sein. Nach dem Start lässt sich die Webmin-Oberfläche über den Port 10000 des betreffenden Servers erreichen, dem Browser muss ggf. beigebracht werden, mit dem ungültigen SSL-Zertifikat zurecht zu kommen.

Beim ersten Versuch habe ich die freizugebenden Ports 53 noch ohne explizite Nennung der IP-Adresse angegeben, d.h. „--publish 53:53„, so dass der externe Port 53 auf den Port 53 des Docker-Containers gemappt wurde. Damit zeigte jedoch Docker eine Fehlermeldung an, und zwar sei der Port 53 an Adresse 0.0.0.0 bereits in Benutzung. Ich vermute, dass dies daher rührt, dass ein Docker-Daemon, der auch im swarm-mode konfiguriert ist, bereits für interne Zwecke einen Nameserver an Port 53 betreibt. Daher erfolgt im Start-Kommando die Angabe der externen IP-Adresse.

Tatsächlich war es das bereits! Nachdem die IP-Adresse für den Zone-Transfer erlaubt war, konnte ich mittels Webmin jeweils den Slave-Server anlegen, woraufhin die Datenübertragung erfolgreich durchgeführt wurde. Bei Updates im Primary wird ebenfalls ein Update im Secondary ausgeführt. Genau so, wie es sein soll.

Da für den reinen DNS-Betrieb Webmin nicht notwendig ist bzw. ein mögliches Einfallstor für böse Hacker darstellt, kann der Container zusätzlich mit dem Parameter ‚--env WEBMIN_ENABLED=false‚ gestartet werden. Sollte man Domains hinzufügen oder sonstige Einstellungen ändern wollen, könnte der Container kurz gestoppt und mit Webmin-Integration neu gestartet werden.

Fazit

Der Aufwand war letztlich minimal – einzig hätte ich mir die Änderung der DNS-Daten für den Versuch mit 1984 Hosting Company sparen können, denn nun hieß es wieder – Rolle rückwärts, anstatt der Managed Lösung zwei eigene DNS betreiben, nur mit einem anderen Secondary. Wenn die Lösung – wovon momentan auszugehen ist – genauso stabil läuft wie der bisherige Container für den Primary DNS, hat sich die Umstellung trotz der Umwege durchaus gelohnt. Immerhin bleiben so sämtliche Dienste in der eigenen Verantwortung, und nicht zuletzt ist man wieder um manch eine Erfahrung reicher.