DNS/bind9 auf virtualisiertem Server im LAN

[tsk]

Hallo zusammen,

vielleicht gehört meine Frage eher in die Rubrik „Virtualisierung“, aber die ist mir zu abgelegen und zu sehr von Werbung durchseucht. Auch „DNS“ tät passen, aber letztendlich ist es ein vServer Problem für mich.

Ich bemühe mich gerade darum, eine lokale PHP Entwicklungsumgebung aufzusetzen, die in ihrer Art meinen realen angemieteten vServern entspricht, und in der nur exakt das geladen wird, was ich auch tatsächlich benötige. Meine realen Server administriere ich noch mittels Plesk, möchte meine Entwicklungsumgebung jedoch händisch aufziehen, um mich weiter zu entwickeln und Plesk später in Realeinsatz vermeiden zu können.

Dazu habe ich auf einem leistungsfähigen PC Ubuntu 10.04 LTS 64 Desktop installiert, sowie auf diesem und über KVM, einen virtualisierten Server unter Ubuntu 10.04 LTS 64 Server. Der LAN Adapter der Workstation (192.168.2.10) ist gebridged, und der erste virtuelle Server hat die 192.168.2.11. Beide statisch vergeben, was auch so bleiben soll. 2 weitere (WIN) PC's im LAN sowie die Ubuntu WS erreichen den Default (Apache) Host über http://192.168.2.11 (it works), dito über https. Auch PHP läuft unter fcgid/suexec einwandfrei. Um möglichst dich am realen Leben zu sein läuft sogar der ssh Zugriff auf den virtualisierten Server über priv/pub-key.

Da es mir um die Virtualisierung eines realen vServers geht (hat 1 IP, ggf. eine 2. für ssl, etc) muss ich unterschiedliche Domains über Apache vhosts abbilden, was auch wunderbar klappt. Doch jetzt nähere ich mich meinem Problem, der Namensauflösung. Würde ich einen Webserver direkt auf der Workstation betreiben, so würde die /etc/hosts genügen, um eine Namensauflösung zu bieten. Aber der Apache läuft nicht lokal, sondern auf dem Server.

Meine Netzwerk Struktur:

UBUNTU-WS: 192.168.2.10
UBUNTU-Server-1 (virtualisiert auf UBUNTU-WS): 192.168.2.11
WIN-PC-1: 192.168.2.30
WIN-PC-2: 192.168.2.40
DSL/Router/Gateway/Nameserver: 192.168.2.254
(nichts von alledem muss von außen erreichbar sein)

Auf meinen realen vServern läuft ein vortrefflich von Plesk konfiguriertes bind9, welches mit gutem Gewissen alles „Unbekannte“ an die bevorzugten Nameserver meines Hosters weiterleiten kann. Erscheint mir von der Konfiguration her einfach.

Dies sieht in meinem LAN jedoch anders aus. Die LAN Clients brauchen auch einen Name Server, wenn mein virtualisierter Server mal nicht läuft. Dafür ist entsprechend der DSL Router eingetragen. Dieser kennt jedoch meine Domains auf dem virtualisierten Server nicht. Ich brauche also einen Nameserver auf dem virtualisierten Server, der ausschließlich die auf ihm abgelegten vhosts sowie sich selbst, als localhost, abbildet, und der mit dem Router/Nameserver koexistieren kann. Ein erster, zaghafter Versuch einer bind9 Konfigurationen endete in einem Nachmittag ohne jedwede Konnektivität. Erst als ich bind9 komplett in den Ausgangszustand versetzt hatte, klappte es wieder. Vom Gefühl her kann ich es nur mit einem eigenen Nameserver erschlagen, installiert auf dem virtualisieren Server.

Habt Ihr eine Idee, wie ich das angehen könnte? Im Moment stehe ich mächtig auf dem Schlauch. Bin für jeden Tipp dankbar.

Grüße,

Thomas

 

[Whistler]

Wie clever ist Dein DSL-Router? Bessere (ich denke z.B. an Lancom) können nicht nur DNS-Requests forwarden, sondern auch lokal Zonen verwalten bzw. selektiv an andere Nameserver weiterleiten und auch cachen.

Wenn Du den primären DNS für Deinen Ubuntu-Server dort belassen willst (weil es z.B. Plesk so braucht), solltest Du unbedingt einen davon unabhängigen sekundären einrichten - der auch dann antwortet, wenn die VM aus ist. Ansonsten kommt es in diesem Fall zu lästigen Timeouts.

Im Einfachsten Fall setzt Du auf der Ubuntu-WS einen zweiten BIND auf, der Deine lokale Zone von der VM bezieht und selbst puffert, ansonsten aber per Default ins Internet forwardet. Falls Dein Router das kann, ist es sogar noch besser, weil er vermutlich immer läuft - für viele Router gibt es übrigens auch alternative linux-basierte Firmwaren aus dem DD-WRT-Projekt, die soewas auch können.

 

[tsk]

Hallo Whistler.

Danke für Deine schnelle Antwort. Ich denke, von meinem Router kann ich nicht viel erwarten, denn er ist hochgradig vorparametriert und verrammelt von der KPN (der niederländischen Telekom). Im Setup bietet er nur die üblichen Dinge wie NAT und Firewall, jedoch keinerlei Möglichkeit, auf DNS oder Zonenverwaltung.

Wenn ich Dich richtig verstanden habe, so rätst Du mir zu einem Nameserver auf dem KVM Host (der WS) sowie einem auf dem Server (dem KVM Gast). Wobei der erstere primär dem Zweck dient, bei ausgeschaltetem Server dennoch brauchbare Antworten zu liefern.

Unter https://help.ubuntu.com/community/KVM/Networking#DNS_and_DHCP_Guests finde ich etwas, was leider nicht exakt auf meine Problematik passt (denn ich nutze statische IP Adressen, kein DHCP). Sollte aber eigentlich davon unabhängig sein. Demnach soll es genügen, den Nameserver vom Gast als ersten Nameserver auf der WS einzutragen, den Router als zweiten. Also etwas wie:

search example.com
nameserver 192.168.2.11 (Nameserver auf virt. Server)
nameserver 192.168.2.254 (Router/Gateway)

Bei meinem gestrigen ersten Versuch mit bind9 habe ich mir das gesamte LAN lahm gelegt, inkl. ssh Zugriffen. Möglicherweise lag dies daran, dass ich in der /etc/bind/named.conf.options ein Forwarding auf meinen Router gesetzt habe. Ich bekam danach von allen Clients die Meldung „No Route to Host“. Kann es sein, dass dieses Forwarding das ausgelöst hat – und das es ohne dieses funktioniert hätte?

Ich habe jetzt zwei ganze Tage das Web nach DNS Tutorials, die zu meiner Problematik passen, abgesucht – ohne Erfolg. Ist vielleicht mein Ansatz, über KVM zu virtualisieren, bereits falsch? Ich habe mich für KVM entschieden, weil dies wohl der zukünftig offizielle Weg für Ubuntu/Debian sein soll. Im Vergleich zu anderen, etablierten Virtualisierungslösungen ist die Doku zu KVM eine Katastrophe (oder ich bin unfähig, brauchbare Doku zu finden). Ich befürchte, ich werde tiefer in die DNS Problematik eindringen müssen, als ursprünglich geplant.

Irgendwie wollte ich komplett weg von meiner Windows Entwicklungsumgebung (die aufzusetzen weniger als 4 Stunden dauerte). An Linux arbeite ich jetzt 3 Wochen, und stoße bei DNS erstmals auf so kryptische Probleme, dass ich ein Scheitern meiner Migrationsversuche nicht mehr ausschließe.

Grüße,

Thomas

 

[tsk]

Sodelle...bin einen entscheidenden Schritt weiter gekommen, und somit automatisch entfrustet. Mein erster Versuch folgte einem Tutorial, welches - wie ich heute weiß, für die ersten Schritte zu weit ging. Und dann fehlten auch noch diverse Punkte (.) in den Zonendefinitionen, deren Auslassen üble Konsequenzen zu haben scheint.

Ich habe jetzt alles noch mal neu gemacht, in Minimalkonfiguration. Habe bind9 derzeit auf dem virtuellen Server ausschließlich als Caching DNS Server eingerichtet, mit einem forward bei unbekannten Domains auf den DNS-Server via Router. Diesmal habe ich jedoch ausschließlich 127.0.0.1 in /etc/resolv.conf hinterlegt. Da stand bei meinem ersten Versuch die Router-IP - und hat somit möglicherweise Endlos-Schleifen ausgelöst.

Auf den Windows Clients und dem KVM Host (WS), habe ich an erster Stelle meinen neuen Nameserver eingetragen (192.168.2.11) und an zweiter Position den DSL-Router (192.168.2.254). Dann habe ich den virtuellen Server runtergefahren und den KVM-Host (WS) neu gestartet.

Nach dem Reboot der WS braucht der erste WAN Zugriff länger (ich denke, bis zum Timeout durch den ja noch nicht wieder gestarteten Server und Nameserver), klappt aber dann doch (einmalig etwa 2 Sekunden längere Wartezeit, danach normale Geschwindigkeit).

Dann habe ich den virtuellen Server (und mit ihm den Nameserver) gestartet und auf der Konsole ein "dig vw.de" ausgeführt.
Der erste Zugriff dauerte 42 ms, jeder folgende darauf 0 - also scheint der Cache zu klappen.

Dann das gleiche auf der WS. Direkt das erste dig brachte 2 ms, also kam die Namensauflösung ziemlich eindeutig vom eigenen Nameserver, der zum Bootzeitpunkt noch nicht vorhanden war. Auch die angezeigte IP unter SERVER stimmte.

Dies bedeutet, das KVM/Qemu tatsächlich schlau genug ist, den auf den Clients an erster Stelle aufgeführten Nameserver nur zu nutzen, wenn es ihn denn tatsächlich (schon) gibt. Ansonsten nimmt er den zweiten, den Router. Startet zwischenzeitig der eigene Nameserver, so wird er auch sofort genutzt.

Vielleicht ja hilfreich für alle, die einen virtualisierten Server nicht nur nutzen, sondern selbst aufbauen wollen.

 

[tsk]

Stop - alles auf Anfang. So, wie ich es beschrieben habe, geht es definitv nicht. Wenn nach einem weiteren Reboot der virtuelle Server mit Nameserver nicht hoch gefahren wird, geht plötzlich im LAN nichts mehr. Der DSL Router hat sich Dinge gemerkt, die plötzlich nicht mehr gelten. Also wichtig: Nicht nachmachen!

Ich denke mittlerweile, dass der Betrieb eines Nameservers auf einem virtuellen Server zum Zwecke der exakten Nachbildung eines realen vServers über's Ziel hinaus geht. Die kleine, aber funktionierende Lösung ist, die hosts Datei zu nutzen. Dies nimmt einen nicht existente Domain nicht übel und reicht die Anfrage einfach an den routerbasierenden Nameserver weiter, der dann auch nichts findet. Startet man den vHost, so wird er auch umgehend gefunden.

Bin jedoch weiterhin an komfortableren Lösungen interessiert.

 

[Whistler]

Die Lösung mit den zwei Nameservern in der resolv.conf ist nicht optimal, da es hier vom Zufall abhängig ist, welcher für die Namensauflösung hergenommen wird. Das kann insbesondere dann zu überraschenden Ergebnissen führen, wenn beide unterschiedliche Antworten liefern.

Die Hosts-Datei ist bei diesem überschaubaren Setup mit 4 Rechnern sicherlich die einfachste und ausreichende Lösung.

Falls Du trotzdem an einer "größeren" Lösung mit DNS interessiert bist:

Lege als erstes einen Rechner als Haupt-Rechner fest, der vorteilhafterweise immer an sein sollte.
Wenn ich Dich richtig verstanden habe, soll die Ubuntu-WS (192.168.2.10) diesen Part übernehmen.

Richte dort BIND ein.

Lege eine Zone fest, die Dein Heimnetz repräsentieren soll. Die kann z.B. tsk.local heißen, ich nehme jetzt zum Beispiel mal tsk.nl.

Lege eine Subzone fest, sie für die virtuelle Maschine gelten soll, z.B. vm.tsk.nl.

Nun konfigurierst Du den Bind auf Deinem Hauptrechner so, daß er
- für tsk.nl primär authoritativ
- für vm.tsk.nl sekundär, aber auch authoritativ
- und für den Rest der Welt als Forwarder auf Dein DSL-Modem arbeitet.

Alle Rechner (auch die Windows-Stationen) bekommen jetzt nicht mehr den DSL-Router (192.168.2.254), sondern den Hauptrechner (192.168.2.10) als Nameserver eingetragen.

Innerhalb der VM (also dem Ubuntu-Server) richtest Du einen BIND so ein, wie es Deinem realen Server nahekommt, lasse also z.B. Plesk die Zonendateien generieren und für vm.tsk.nl authoritativ sein. Hier mußt Du lediglich Deinen Hauptrechner (192.168.2.10) als sekundär definieren, damit er sich die Zonendateien ziehen darf und über eventuelle Änderungen per Notify benachrichtigt wird.

Damit ergeben sich folgende Pfade:
- Du rufst (z.B. von einem der Windows Rechner) eine unbeteiligte Domain (z.B. serversupportforum.de ) auf:
Der Windows-Rechner fragt die Ubuntu-WS, diese erkennt, daß sie selbst nicht zuständig ist, fragt das DSL-Modem, dieses den DNS des Providers und jener schußendlich INWX, von wo er die richtige Antwort (188.138.94.37) bekommt.
Viele Stationen in dieser Kette cachen die Antwort, so daß die nächsten paar Stunden nur noch Deine Ubuntu-WS antwortet, ohne noch einmal fragen zu müssen.

- Du rufst (z.B. von einem der Windows Rechner) eine lokale Domain (z.B. windows-pc1.tsk.nl auf) auf:
Die Ubuntu-WS kennt die richtige Antwort (192.168.2.30) und antwortet sofort.

- Du rufst (z.B. von einem der Windows Rechner) eine virtuelle Domain (z.B. ubuntu-server.vm.tsk.nl) auf:
Auch hier kennt die Ubuntu-WS die richtige Antwort (192.168.2.11) und antwortet sofort.

- Wenn Du jedoch an Deinem Ubuntu-Server etwas umkonfigurierst (ihm zum Beispiel die IP 192.168.2.12 gibst), dann wird der Ubuntu-Server das so in seinen lokalen BIND eintragen. Gleichzeitig sendet er eine Notification an alle Slaves (eben die Ubuntu-WS), die damit aufgefordert wird, ihren lokalen Datenbestand zu aktualisieren. Das tut sie per Zonentransfer (IXFR oder AXFR) und kann ab diesem Zeitpunkt auch über 192.168.2.12 aktuelle Auskunft geben.

Das tut sie insbesondere auch, wenn der Ubuntu-Server aus ist und nicht direkt auf Anfragen antworten kann.
Wie lange die Kopie vorgehalten wird, legt man im Expiry-Wert des SOA-Records fest, Werte von 1 bis 4 Wochen sind hier durchaus gebräuchlich.

Du merkst schon, dieses Setup ist aufwendig, dafür skaliert es aber sehr gut, wenn Du mal viele VMs, Rechner oder auch Domains hast.

Die Lösung mit der Hosts-Datei würde dagegen erfordern, in so einem Fall (Einrichtung von 192.168.2.12) alle Hosts-Dateien auf allen Rechnern anzufassen. - das wird mit zunehmender Zahl irgendwann lästig.

 

[tsk]

Hallo Whistler,

ich weiß gar nicht, was ich sagen soll wegen der großen Mühe, die Du dir gemacht hast. 1000 Dank dafür. Das tollste ist, ich habe es beim ersten Lesen verstanden. Es ist so gut geschrieben, dass man es eigentlich in den Rubriken DNS und Virtualisierung anpinnen sollte.

Ich habe vorerst, da es nur um 3 vhosts auf dem vServer geht, den Weg über die hosts gewählt. Klappte natürlich auf Anhieb. Nächste Woche habe ich Besuch aus UK, werde mich aber direkt danach daran machen, Deine Lösung umzusetzen.

Hinsichtlich Plesk habe ich mich wahrscheinlich falsch ausgedrückt. Plesk ist derzeit nur auf meinen (live) vServern im Web existent. Meine lokale Nachbildung der Struktur soll später dazu dienen, reale Server selbst, also ohne Plesk, zu administrieren. Deshalb baue ich alles so lebensecht wie möglich auf. Plesk hat es mir seinerzeit erlaubt, ohne wirklich tiefgehendes Verständnis meine TYPO3 Server aufzuziehen und zu administrieren. Dies jedoch mit vielen Kompromissen. Ich habe zwar php auf fcgid/suexec umstellen können, benötigte aber weiterhin mod_php für Horde/Webmail. Viele Dinge, die man auf einem "normalen" server einfach machen kann, führen bei Plesk ins Chaos.

Ich danke Dir nochmals herzlich für Deine Unterstützung,

Grüße,

Thomas