© frannyanne, 123RF

Die Verwaltung von DNS-Einträgen funktioniert für Clouds fundamental anders als in klassischen Setups. Open Stack Designate zeigt, wie eine sinnvolle und gut funktionierende Umsetzung aussehen kann.

DNS gehört zu jenen Diensten im Rechenzentrum, die so selbstverständlich sind, dass ihre Existenz bei Admins wie Nutzern oft in Vergessenheit gerät. Dass DNS elementar ist, fällt vielen oft erst dann auf, wenn er aus irgendwelchen Gründen nicht funktioniert. Etwa dann, wenn sich eine Website nicht aufrufen lässt, weil der zuständige DNS-Server abgestürzt ist.

Meist gehört DNS zu den ersten Diensten im Rechenzentrum beim Aufbau einer neuen Infrastruktur: Wer ein neues Setup plant, installiert DNS oft zuerst, weil sich die anderen Rechner sonst kaum nutzen lassen. Kurzum: DNS ist eine elementare Voraussetzung für praktisch alle anderen Dienste in IT-Setups.

Das Thema DNS hat dabei mehrere Dimensionen: Einerseits müssen Rechner in der Lage sein, Hostnamen aufzulösen, um mit anderen Rechnern innerhalb sowie außerhalb des Setups zu kommunizieren.

Andererseits erfolgt die Verwaltung der eigenen DNS-Einträge in den dafür zuständigen autoritativen DNS-Servern: Eine nur per IP-Adresse erreichbare Website ist nur selten erwünscht. Stattdessen soll unter einer Adresse – etwa »www.beispiel.de« – eine Website mit den erwarteten Inhalten erscheinen.

Dafür muss einerseits für die Domain »beispiel.de« ein entsprechender A-Eintrag (oder für IPv6 ein AAAA-Eintrag) hinterlegt sein. Andererseits muss in der DNS-Datei für den jeweiligen IP-Adressraum ein korrespondierender PTR-Eintrag angelegt sein, der auf den A-Eintrag verweist.

Für HTTP- und HTTPS-Einträge ist es zwar von untergeordneter Bedeutung, wenn der PTR-Eintrag fehlt. Doch wer von seinen Systemen aus E-Mails versenden will, stolpert über einen falschen oder fehlenden PTR-Eintrag schnell: Viele Mailserver nehmen E-Mails gar nicht erst an, wenn der versendende Server keinen PTR-Eintrag hat, fast immer gilt dies als sicheres Anzeichen für Spam.

Konventionell ist einfach

In konventionellen Setups ist das Thema DNS leicht abzuhandeln. Denn hier lassen sich sowohl die für DNS notwendige Infrastruktur als auch die konkreten Einträge für einzelne Hosts und IPs in die Planung einbeziehen. Klassische Setups sind meist von Anfang an durchgeplant: Es ist also klar, welche Server Teil des Setups sind und unter welchen Adressen sie erreichbar sein sollen.

Hinzu kommt, dass sich typische Setups im Laufe ihres Lebens meist nicht mehr fundamental verändern. Zwar kommt der eine oder andere Rechner hinzu, doch das lässt sich mit wenigen neuen DNS-Einträgen problemlos bewältigen. Auch für virtualisierte Setups stellt die DNS-Konfiguration keine Hürde dar, denn hier ist der einzige Unterschied meist nur, dass Dienste in VMs laufen und nicht auf echtem Blech – im Voraus planen lässt das Setup sich dennoch, und das gilt dann auch für DNS.

In der Cloud ist alles anders

Virtuelle Umgebungen in Clouds unterscheiden sich durch zwei Faktoren von ihren konventionellen Kollegen. Einerseits setzen Clouds verstärkt auf das Thema Automatisierung: Ein richtiges Cloudsetup lässt sich meist über die Orchestrierungskomponente der genutzten Cloud automatisch ausrollen. In einer Template-Datei legt der Admin fest, dass es eine bestimmte Anzahl von Applikationsservern, Datenbanken, Load Balancern oder Monitoring-Servern geben soll, und die Cloud baut die Umgebung entsprechend zusammen.

Andererseits setzen Clouds verstärkt auf den On-Demand-Faktor: Der Admin muss sich also nicht bereits bei der Installation des Setups überlegen, wie viele Server es letztlich haben soll. Denn jede Art von Dienst lässt sich zu einem späteren Zeitpunkt problemlos erweitern. Auch die andere Richtung stellt kein Problem dar: Sind in Zeiten niedriger Last weniger virtuelle Instanzen für die einzelnen Servertypen nötig, lässt sich das laufende Setup auch verkleinern.

Zwei Welten

Schnell wird klar: Klassische, starre DNS-Verwaltung und Clouds passen nicht zusammen. Wer in einer typischen Cloud eine virtuelle Maschine startet, bekommt zunächst eine Konfiguration ganz ohne DNS-Einträge – es sind also weder A-Einträge für eine spezifische Domain vorhanden noch PTR-Einträge für die jeweiligen IP-Adressen. Das Problem der A-Einträge wäre zwar zu Fuß noch irgendwie zu lösen: Schließlich könnte man nach dem Start des virtuellen Setups in die DNS-Konfiguration einer Domain A-Einträge für die öffentlichen IP-Adressen eintragen.

Das ist aber ein langwieriger Vorgang – und wenn sich die ganze virtuelle Umgebung in ein paar Minuten aus dem Boden stampfen lässt, ist es nicht sinnvoll, danach viel Zeit aufzuwenden, um die DNS-Einträge für das Setup zu erstellen. Gar nicht funktioniert das Prinzip für die PTR-Einträge von Domains: Öffentliche IPs vergeben Public Clouds schließlich dynamisch aus einem vordefinierten Pool und die Autorität über die Domains liegt beim Anbieter. Der wird seinen Kunden aber kaum den direkten Zugriff auf seine DNS-Server erlauben. Schlimmstenfalls ist der Kunde in solchen Fällen gezwungen, ein Supportticket mit den gewollten DNS-Einträgen zu eröffnen. Mit Automatisierung und dynamischer Nutzung hat das aber nichts mehr zu tun – deshalb scheidet diese Option aus.

Stattdessen muss die DNS-Verwaltung für VMs in Clouds tief in die Cloud selbst integriert sein. Die genutzte Software soll bereits beim Anlegen virtueller Instanzen passende DNS-Einträge sowohl für A-/AAAA- als auch für PTR-Einträge erstellen. Am konkreten Beispiel von Open Stack lässt sich das gut zeigen: Designate heißt die Open-Stack-Komponente, die sich um die Verwaltung von DNS-Einträgen kümmert. Dieser Artikel erklärt, wie die Designate-Architektur aussieht und an welchen Stellen Designate in Setups eingreift, um funktionierende DNS-Einträge für virtuelle Cloudinstanzen zu erreichen. Das Ziel ist DNS as a Service – oder abgekürzt auch: DNSaaS.

Bewegte Geschichte

Designate ist noch nicht sonderlich alt und hat trotzdem bereits eine für Open-Stack-Verhältnisse bewegte Geschichte hinter sich. Vor mehreren Jahren erblickte der Dienst unter dem Namen Moniker das Licht der Welt. Doch das Interesse der Community an der Lösung schlief bald wieder ein. Kein Wunder: Weit wichtigere Themen mit Blick auf Stabilität und Zuverlässigkeit von Open Stack standen im Fokus der Entwickler. Dass Moniker es nie zur Core-Komponente gebracht hat, sorgte für ein weiteres Abflauen des Interesses an dieser Lösung.

Mit zunehmender Stabilität von Open Stack rückten später andere Themen aber erneut stärker in den Fokus. Darunter auch das besagte Moniker, das dessen Entwickler bald in Designate umbenannten. Im Rahmen der Big-Tent-Initiative begann dann bald die kontinuierliche Feature-Entwicklung. Mittlerweile folgt Designate dem Releasezyklus von Open Stack selbst; die zusammen mit Open Stack Newton veröffentlichte Designate-Version ist 3.0.0.

Und tatsächlich lässt sich mit Designate mittlerweile sinnvoll Arbeiten: Die Komponente spricht im Backend auf Wunsch mit DNS-Servern verschiedenen Typs, darunter als Platzhirsch Bind sowie Power DNS. Über ein API lassen sich zudem automatisch oder händisch Domains und einzelne DNS-Einträge verwalten. Wie funktioniert das im Detail?

Modularer Aufbau

Wie praktisch jede Open-Stack-Komponente beruht auch Designate auf einem modularen Design (Abbildung 1). Der wichtigste Bestandteil ist Designate-Central, er verwaltet die Metadaten von Designate, zu denen auch die Datenbank aller vorhandenen und von Designate anzulegenden DNS-Einträge gehört. Direkt mit Designate-Central verbunden ist das Designate-API: Wie jede Open-Stack-Komponente basiert auch das API auf dem REST-Prinzip und nimmt von außen Befehle entgegen, die der Nutzer per CLI oder über das Open-Stack-Dashboard eingibt.

Abbildung 1: Designate besteht in Open Stack aus mehreren Komponenten, die sich für den Nutzer um komfortable DNS-Verwaltung kümmern.

Anders als andere Open-Stack-Komponenten gibt es bei Designate aber noch eine weitere Möglichkeit, Konfigurationsänderungen vorzunehmen: Der auf den Namen Designate-Sink getaufte Teil der Lösung dockt direkt an der Message-Queue der Cloud an. Diese nutzt jede Open-Stack-Umgebung, um Befehle zwischen den einzelnen Open-Stack-Komponenten auszutauschen.

Legt etwa Nova, also der für die Verwaltung von VMs zuständige Dienst, eine neue virtuelle Maschine an, geschieht das per Nachricht über die Message-Queue, die eine der verschiedenen Nova-Compute-Instanzen dann ausliest und verarbeitet. Meist kommt bei Open Stack Rabbit MQ zum Einsatz.

Designate-Sink greift insbesondere die Notifications ab, die Nova beim Anlegen und beim Löschen von VMs wie eine Bestätigung versendet. Diese nutzt der Dienst nämlich als Trigger, um nach dem Start einer VM automatisch DNS-Einträge für sie anzulegen. Das Prinzip ist elegant: Weil Nova die Notifications sowieso anlegt und Designate diese aus Rabbit MQ lesen kann, ist keine weitere Arbeit auf der Nova-Seite nötig, um Nova und Designate miteinander reden zu lassen.

Die Kommunikation mit Nameservern

Apropos Dienste, die miteinander reden – im Backend muss Designate gleich für mehrere Aufgaben mit DNS-Servern reden. Die Verantwortung dafür tragen zwei Komponenten: Designate-Poolmanager und Designate-MDNS. Es ist sinnvoll, sich mehrere fiktive DNS-Server zu denken, die für Kundenanfragen bereitstehen, nur so erschließt sich das Zusammenspiel der Dienste.

Designate-Poolmanager ist zuständig für den Überblick über die DNS-Server, die ein Designate-Setup hat. Per Poolmanager lassen sich die DNS-Server in Pools sortieren, also in Gruppen ordnen. Auf der Pool-Ebene legt der Nutzer anschließend pro Domain fest, welcher Nameserver verantwortlich für eben jene Domain ist. So ist es möglich, eingehende Anfragen für Domains auf viele Backends zu verteilen.

Obendrein ist der Poolmanager auch verantwortlich dafür, die Konfiguration aus den Konfigurationsdaten in der Datenbank mit der Konfiguration aller DNS-Server abzugleichen. Zu diesem Zweck unterstützt der Poolmanager die so genannten Backends – eine Art Treiber, die die Kommunikation zwischen dem Poolmanager und dem Nameserver ermöglichen. Designate unterstützt ab Werk eine Vielzahl von Backends: Bind 9, MS-DNS, Power DNS, Knot DNS 2 sowie Djbdns sind nur ein paar der verfügbaren Beispiele (Abbildung 2).

Abbildung 2: Die Backends von Designate reden mit verschiedenen DNS-Servern im Hintergrund.

In Form von Designate-MDNS (Designate Mini DNS) hat Designate aber auch einen eigenen Nameserver: Der sendet DNS-Notify-Anfragen und beantwortet AXFR-Requests von den echten Nameservern im Setup. Auf den ersten Blick wirkt das Konstrukt redundant: Wenn die DNS-Server im Setup ohnehin durch Designate-Poolmanager direkt bearbeitet werden können – warum erhalten sie ihre Daten stattdessen per AXFR und DNS-Zonentransfer von Designate-MDNS?

Die Antwort auf diese Frage ist im Blueprint für Designate-MDNS [1] verewigt: Danach wäre in den Backends sehr viel Intelligenz notwendig, wenn diese sich darum kümmern müssten, dass die Ziel-DNS-Server auf dem aktuellen Stand sind. Das Update von DNS-Einträgen auf mehreren DNS-Servern gleichzeitig ist keine triviale Aufgabe – die dennoch bereits gelöst ist: Update-Nachrichten und AXFR-Requests sind schließlich feste Bestandteile des DNS-Standards.

Es hätte also bedeutet, das Rad neu zu erfinden, hätte man die DNS-Updates per Designate-Poolmanager und dessen Backends umsetzen wollen, statt dafür vorhandene Mechanismen zu benutzen. Bewusst haben die Entwickler des Open-Stack-Projekts sich dagegen entschieden. Was eingedenk diverser anderer Entscheidungen des Projekts in der Vergangenheit – soviel Häme sei erlaubt – durchaus bemerkenswert ist.

Der Hausmeister

Nicht unerwähnt bleiben soll schließlich der Zonemanager: Das ist quasi Designates eingebauter Cron-Daemon, der in regelmäßigen Abständen diverse Hausmeister-Tätigkeiten für den DNS-Dienst ausführt. So meldet der Zone-Dienst etwa in regelmäßigen Abständen an Ceilometer, dass bestimmte Zonen in Designate noch existieren. Zur Erinnerung: Ceilometer sammelt in Open Stack Metrikdaten und bildet so die Grundlage für die Verrechnung von Diensten. Obendrein kümmert sich Designate-Zonemanager darum, dass regelmäßig AXFR-Anfragen für die Domains starten, für die der Nutzer in Designate angegeben hat, dass nicht Designate selbst der primäre DNS-Dienst für jene Domain ist, sondern ein externer Server.

Insgesamt wird klar: Das Designate-Design ist mittlerweile ausgereift und empfiehlt sich für den Einsatz in produktiven Umgebungen. Wie aber fühlt es sich an, im Alltag tatsächlich mit Designate zu arbeiten? Wie genau sieht ein auf Designate basierendes Setup aus? Das folgende Beispiel ist einer tatsächlichen Installation entnommen und zeigt, wie Designate in Open Stack DNS sinnvoll agieren kann.

Die Server

Grundlage für das Setup ist eine Open-Stack-Installation, die aus vielen Computingknoten und insgesamt fünf Con-trollerknoten besteht. Während auf den Computingknoten die Open-Stack-VMs laufen, beherbergen die Controller die Infrastrukturkomponenten der Open-Stack-Cloud, also jene Dienste, die das eigentliche Open Stack ausmachen.

Wobei nicht alle Open-Stack-Dienste auf allen Controllern laufen: Zwei der fünf Knoten sind für die Nameserver reserviert, die später für Anfragen von außen zur Verfügung stehen. Darüber hinaus sind die Designate-Komponenten samt und sonders auf den drei Knoten untergebracht, die übrig bleiben.

Die Designate-Konfiguration ist verglichen mit anderen Open-Stack-Diensten ziemlich aufwändig und die Konfigurationsdatei »/etc/designate/designate. conf« wird recht schnell unübersichtlich. Was daran liegt, dass sich alle Komponenten von Designate diese Datei teilen müssen: Für alle zuvor beschriebenen Dienste steht hier also die Konfiguration. Dazu gehören die Angabe, welche Datenbank Designate für seine Metadaten nutzen soll, genauso wie die Adressen der Rabbit-MQ-Server, in die sich Designate-Sink einklinkt.

Weil ein Designate-Poolmanager mit DNS-Servern reden muss, ist die Einstellung für die zum Poolmanager gehörenden Backends ebenfalls in »designate.conf « zu finden. Außerdem gesellen sich die Handler hinzu: Das sind Einträge in »designate.conf«, die Designate verraten, welche Domains Designate für neue VMs nutzen soll – denn nur so erhält eine neue VM auf jeden Fall neben ihrer IP auch zumindest einen DNS-Eintrag.

Standard-Einträge für neue VMs

Das Thema “Standard-Einträge für neue VMs” rechtfertigt einen kleinen Exkurs. Cloudanbieter, wenn sie Designate einsetzen, haben in der Regel ein zentrales Interesse: Für jede virtuelle Maschine soll ein DNS-Eintrag vorgenommen werden, ganz gleich, ob der Nutzer das angibt oder nicht. Weist der Nutzer einer VM etwa eine öffentliche Floating-IP zu, legt dafür aber keinen DNS-Eintrag fest, greifen die Provider-Defaults und Einträge für jene VM entstehen automatisch in der Default-Domain des Anbieters.

Der Begriff Domain bezieht sich dabei auf Designate-Interna: Jede Zone, die Designate verwaltet, bezeichnet der Dienst als Domain. Darunter fallen auch die Reverse-Zonen für PTR-Einträge bei IP-Adressen. Designate lässt dem Nutzer die Wahl zwischen der Provider-Zone und zuvor eigens angelegten, Nutzer-spezifischen Domains.

Mitarbeit des Nutzers

Sobald der Anbieter die Designate-Infrastruktur auf Seiten der Cloud wie beschrieben bereitstellt, ist die Mitarbeit des Nutzers gefragt. So viel ist klar: Damit Designate für eine Domain funktionieren kann, muss diese bei der zuständigen Registrierungsstelle so konfiguriert sein, dass ihre NS-Einträge tatsächlich auf die Designate-Nameserver zeigen. Designate übernimmt also in einem solchen Szenario die Kontrolle über die Domain. Wer das vermeiden will, kann freilich auch mit Subdelegationen arbeiten: Dann könnte etwa DNS für die Subdomain »cloud.example.com« an Designate delegiert sein, während sich um den Rest der Domain die normalen Nameserver kümmern.

Das Setup von Domains durch Nutzer gestaltet sich mit dem eigens für diesen Zweck vorgesehenen Designate-Kommandozeilen-Clients simpel: Per »designate domain-create –name example.com. –email email@example.com« legt der Nutzer eine Domain an (Abbildung 3). Die Ausgabe des Werkzeugs zeigt danach eine ID an, die wichtig ist. Diese Domain-ID braucht der Nutzer nämlich, um für VMs DNS-Einträge anzulegen.

Abbildung 3: Sobald Designate funktioniert, lassen sich mit dem Designate-CLI Domains anlegen.

Etwa so: »designate record-create 5849251B -832E-4521-94ED-92EB3D191DC4 –name www.example.com. –type A –data 192.0.2.1«. Dieses Beispiel führt dazu, dass der Domainname »www.example.com« einen A-Eintrag für die Adresse »192.168.2.1« bekommt (Abbildung 3). Um den PTR-Record für eine Floating-IP der Cloud zu setzen, ist auch eine ID notwendig – nämlich jene der Floating-IP. Diese zeigt wahlweise das Dashboard oder die Kommandozeile an. Der Befehl lautet im Anschluss: »openstack ptr record set IDPTR-Eintrag« – »ID« sowie »PTR-Eintrag« sind durch die tatsächlichen Werte zu ersetzen.

Um den Vorgang zu automatisieren, passt der Benutzer bei Bedarf das Netz an: Bereits bei dessen Anlegen lässt sich per Paremter für »neutron« nämlich festlegen, mit welcher DNS-Domain das Netz verbunden sein soll.

Entdecke die Möglichkeiten

Designates Funktionsumfang geht deutlich über das Anlegen von DNS- und PTR-Einträgen hinaus. Ein Beispiel ist das Steuern von Zonentransfers: Wer für eine bestimmte Domain einen AXFR-Transfer auslösen möchte, erledigt das per »designate zone axfr« auf die jeweilige Zone. Interessant sind zudem die Zonen-Blacklists: Hier legt der Admin per regulärem Ausdruck Strings fest, die in Domainnamen nicht vorkommen dürfen.

Wer etwa verhindern möchte, dass die eigene Cloud Websites mit obszönen Begriffen im DNS-Namen hostet, trägt jene in die Designate-Blacklist ein. Der Versuch, eine Domain anzulegen, die auf ein Pattern der Blacklist passt, scheitert mit einem HTTP-400-Fehler und der entsprechenden Fehlermeldung. Blacklist-Domains dürfen nur Admins anlegen oder verwalten.

Ein GUI für Designate

Der Artikel hat gezeigt, wie sich mit dem Designate-API per CLI Einträge sowohl für Hostnamen als auch für IP-Adressen anlegen lassen. Nicht erwähnt hat er bisher das Plugin, das Designate ins Open-Stack-Dashboard alias Horizon integrieren soll. Leider ist die Designate-Integration ins zentrale Open-Stack-GUI keine rühmliche Geschichte: Erste Arbeiten fanden bereits 2014 statt, und ein verwaister Merge-Request im Review-System des Open-Stack-Projekts [2] kündet davon, dass Horizon Designate seit über zwei Jahren kennen sollte.

Doch aufgrund diveser Fehler blockte man den Merge-Request ab – und der ursprüngliche Autor hat zwischenzeitlich wohl keine Muße gefunden, einen erneuten Anlauf zu unternehmen. Die gute Nachricht ist, dass am Designate-Dashboard weiterhin gearbeitet wird. Aktuell existiert es als Out-of-Tree-Entwicklung ausschließlich auf Github [3].

Die dort auch zu findende Installationsanleitung erwähnt aber die Installation des Plugins mit »python.py«-Skript. In produktiven Umgebungen ist das ein Level an Bastelei, für das kein Mensch die Verantwortung übernehmen will. Wer Ubuntu nutzt, hat allerdings kaum eine Wahl: Canonical paketiert für Ubuntu nur jene Open-Stack-Teile, die Teil des offiziellen Open Stack sind.

Dem genervten Admin bleibt letztlich nur übrig, sich selbst ein Paket zu bauen – mit ein bisschen Übung ist das immerhin ein leistbarer Aufwand. Trotzdem sollten die Entwickler zusehen, dass das Designate-Plugin bald Bestandteil von Horizon wird, damit diese Bastelei wegfällt (Abbildung 4).

Abbildung 4: Leider nein: Zwar existiert ein Horizon-Plugin für Designate, doch das hat es bis heute nicht in Horizon geschafft. Handarbeit ist angesagt.

Designate und Heat

Open Stacks Orchestrierungsdienst Heat ist in gewisser Weise ein Strohmann zwischen den eigentlichen Open-Stack-Diensten und dem Nutzer: Er nimmt vom Nutzer ein Template entgegen, wertet es aus und legt die beschriebenen Dienste dann über die zuständigen Open-Stack-Komponenten an. DNS-Einträge für VMs oder IP-Adressen sind in diesem Kontext letztlich auch nur Ressourcen, die Heat verwalten kann.

Bereits Mitte 2015 haben die Designate-Entwickler Heat um eine ganze Reihe von Designate-Funktionen erweitert, mit denen sich Domains automatisch anlegen oder löschen lassen – auch die Zuordnung von DNS-Einträgen zu IPs oder Hosts ist per Heat-Anweisung möglich. Im Gegensatz zur Dashboard-Integration ist die Heat-Integration also umfassend.

Fazit

DNS as a Service (DNSaaS) ist eine der ersten Funktionen, die Kunden sich in einer Cloud wünschen. Zu Recht: Händische Verwaltung von DNS-Einträgen für Cloud-VMs ist nur teilweise möglich und dann ausgesprochen mühsam. Gerade weil Clouds verstärkt auf Automatisierung setzen, muss diese bei DNS-Angelegenheiten gegeben sein.

Designate füllt die DNSaaS-Lücke für Open Stack gut: Nach einer ereignisreichen Geschichte ist der Dienst nunmehr produktiv einsetzbar und hält im Wesentlichen, was die Entwickler versprechen. A- und AAAA-Einträge lassen sich mit Designate erreichen, PTR-Einträge sind auch kein Problem.

Wenn die Entwickler nun noch die offizielle Einbindung in das Dashboard hinbekommen, gehört der Dienst zum Kreis der gelungenen Open-Stack-Komponenten. Wobei vielen Nutzern die Dashboard-Anbindung vermutlich egal ist: Wer Heat zur Orchestrierung in Open Stack nutzt, interessiert sich für GUIs wenig.

Wer Designate nutzen will, sollte diese Arbeit aber mit einem DNS-erfahrenen Admin erledigen, falls er nicht selber einer ist. Denn ein passendes Design für Designate mit den Vorgaben der eigenen Cloud ist kein Selbstläufer.