BIND
ist ein Server zur Auflösung von DNS-Namen.
Wie funktioniert das DNS? #
Das DNS (Domain Name System) dient dazu, Namen von Internet-Servern auf IP-Adressen abzubilden. Es erfüllt also eine Funktion ähnlich einem Telefonbuch. Jeder Rechner, der an das Internet angeschlossen ist, hat eine eindeutige IP-Adresse. Diese sind allerdings einerseits nicht so leicht zu merken und andererseits hängt diese Adresse von der Topologie des Netzes und nicht vom Einsatzzweck des Servers ab. Das bedeutet, wenn ein Rechner im Rechenzentrum von z.B. Domainfactory steht, hat er immer eine Adresse aus deren IP-Adressraum. Damit mein Rechner jetzt unter z.B. thomasbayen.de zu erreichen ist, brauchen wir ein "Telefonbuch", das diesen Namen entgegennimmt und mir die entsprechende IP-Adresse zurückgibt. Diese Funktion erfüllt das DNS.
Prinzipiell ist das DNS hierarchisch aufgeteilt. Das bedeutet, das ein Nameserver, der Teil des DNS ist, immer nur für die Unterdomains eines einzelnen Domainnamens zuständig ist. Diesen Bereich nennt man eine Zone (es kann Unterschiede zwsichen Domain und Zone geben, aber das würde hier zu weit führen). Damit die Hierarchie einen ordentlichen Anfang hat, spricht man auf der obersten Ebene von der sog. Root-Zone. Hierfür wurde eine Anzahl von IP-Adressen festgelegt (14 Stück, die sogenannten Server A-M) und diese als Root-Nameserver definiert. Dadurch das einige dieser Adressen (sog. Anycast-Adressen) je nach geographischem Ort auf unterschiedliche physikalische Server umgeleitet werden, gibt es in Wahrheit noch einige Root-Server mehr. Die Root-Server enthalten eine Liste der Top-Level-Domains (TDL) wie .de, .com, .org, etc... Für jede dieser Zonen gibt es einen oder mehrere (praktisch natürlich immer mehrere) Nameserver-Einträge von Nameservern, die für diese Zone zuständig sind.
So betreibt z.B. die DENIC e.G., die der oberste Verwalter der de-Zone ist, Nameserver, die eine Datenbank mit allen deutschen Domains beinhalten. Die Root-Server A bis M geben daher Anfragen an eine Domain, die auf ".de" endet, an diese Server der DENIC weiter. Wenn ich jetzt z.B. eine Domain "lug-kr.de" habe, weiss die DENIC, von welchem Internet-Provider diese zur Verfügung gestellt wird. Die DENIC-Nameserver geben dazu den Nameserver dieses Providers an. Lautete die ursprüngliche Anfrage z.B. "www.lug-kr.de", so weiss der Nameserver des Providers nun, welcher Rechner genau "www" in dieser Domain ist.
Die meisten Nameserver können nicht nur eigene Domains auflösen, sondern auch andere Server des DNS-Systems abfragen. Hierzu benutzen sie entweder Forwarding (einfach einen anderen fragen) oder Rekursion (eigene Domains tiefer auflösen). Teilweise gibt es aber auch eine Aufteilung in Server, die authoritative Antworten geben (d.h. die für eine eigene Zone Antworten aus Ihrer eigenen Zonendatei geben) und die nur Anfragen an andere Server weiterleiten und dann ggf. cachen. Erstere geben manchmal sogar gar keine endgültige Antwort heraus (das dient dazu, das z.B. nicht alle Welt nur die Rootserver mit jedem Kleinkram bombardiert). Zweitere dienen dazu, das Endbenutzer Anfragen stellen können. Sie werden zumeist von Internet-Providern betrieben, die diesen Dienst für Ihre Kunden bereitstellen. Es gibt aber auch öffentliche wie z.B. den Server mit der schönen Nummer 8.8.8.8 von Google.
VHOSTs #
Um die Erklärung abzurunden, sei noch erwähnt, das die Zuordnung von Namen und IP-Adressen immer nur in eine Richtung eindeutig sein muss. Es können also viele Namen auf die gleiche Adresse abgebildet werden. Arbeitet dort ein Webserver, so kann dieser dann so konfiguriert werden, das er anhand des HTTP-Headers der Browser-Anfrage erkennt, welche Domain der Browser wirklcih haben will. Er kann dann die Webseite z.B. in unterschiedlichen Verzeichnissen suchen (sogenannte VHOST-Konfiguration des Webservers). Für Dienste, die keine Domain in der übermittelten Anfrage angeben, geht das aber nicht. Z.B. für ssh-Zugriffe gilt, das der Server nicht wissen kann, welchen Domainnamen ein Anwender angegeben hat und somit auch den Zugriff nicht anhand des Namens unterscheiden kann. Diese Unterscheidung kann dann z.B. bei ssh anhand des Benutzernamens erfolgen - bei anderen Diensten ggf. aber auch gar nicht.
Was macht Bind? #
Bind ist das Programm, das auf ca. 70% der Nameserver des Internets eingesetzt wird. Daher sind auch viele Anleitungen und Beispiele im Internet hierfür zu bekommen und beziehen sich oftmals auf das Format der Zonendatei, das Bind benutzt.
Bind speichert seine Daten in sogenannten Zonendateien. Eine solche Datei enthält im einfachsten Fall alle Einträge für eine einzelne Sub-Domain. Außerdem enthält sie Daten wie den für eine Domain zuständigen Nameserver, und auch das TTL-Feld. Dieses gibt an, wie lange ein Eintrag gültig ist. Das ist gerade für eigene Spielereien wichtig. Hat man nämlich etwas verändert, so muss sich diese Änderung ja auch in allen anderen Servern des DNS-Systems rumsprechen. Da der Sinn der meisten Server aber gerade ist, solche Anfragen zu cachen, dauert es, bis diese Ihre Information erneuern. Um diese Zeit zu beeinflussen, dient die TTL-Einstellung. Für Basteleien kann man diese auf z.B. 5 Minuten (300 Sekunden) setzen.
Beispiel: Nameserver für Third-Level-Domain #
Um einen eigenen Nameserver aufzusetzen, mit dem man herumspielen kann, muss man sich irgendwo in das globale DNS-System einhängen. Dazu benötigt man ersten einen (selbst aufgesetzten) Nameserver mit einer festen IP-Adresse und zweitens einen Nameserver-Eintrag in einer bereits vorhandenen Domain (also bei einem Provider).
Je nach Provider und Problemstellung kann es gewünscht (oder einfacher) sein, eine Second- oder eine Third-Level-Domain selbst zu verwalten. Im Prinzip ist das aber vollkommen egal und wird identisch eingerichtet. Der Domainname enthält lediglich einen Punkt mehr. Bei DF war es einfacher, das so zu machen und es erfordert für meine Tests nicht, eine kostenpflichtige zusätzliche SLD zu beantragen.
Nameserver BIND einrichten #
Server bereitstellen #
Wer einen normalen Internet-Zugang (mit dynamisch zugewiesener IP-Adresse hat), kommt nicht umhin, hierfür einen (zumindest virtuellen) Server bei einem Provider zu mieten. (Ich selber habe gute Erfahrung mit der sog. Jiffybox von Domainfactory, weil die recht günstig ist und dynamisch erzeugt, schlafen gelegt und und ohne lange Vertragslaufzeit wieder gelöscht werden kann - deshalb nehme ich die hier als Beispiel).
Nameserver Bind installieren #
Auf der Jiffybox habe ich das Bind-Paket installiert:
aptitude install bind9
Bind einrichten: Zonendatei einbinden #
Die Konfiguration beginnt mit der Datei /etc/bind/named.conf. In der Debian Basis-Konfiguration ist allerdings in dieser Datei gar nicht einzustellen. Sie enthält einen Verweis auf andere Dateien mit verschiedenen Einstellungen. Die lokalen Zonendateien sollten nach diesem Schema in /etc/bind/named.conf.local eingetragen werden. Dort füge ich folgendes an:
zone "dns.thomasbayen.de" {
type master;
file "/etc/bind/db.dns.thomasbayen.de";
allow-query { any; };
};
Hier habe ich einen Verweis auf meine eigene Zonendatei /etc/bind/db.dns.thomasbayen.de eingetragen. Diese sieht dann z.B. so aus:
$TTL 300
; Zonefile fuer
; dns.thomasbayen.de
;
; ttl 300 sind 5 Minuten
dns.thomasbayen.de. IN SOA ns1.dns.thomasbayen.de. tbayen.bayen.de. (
1 ; serial no
1800 ; refresh 30 Minuten
600 ; retry 10 Minuten
604800 ; expire 1 Woche
300 ; minimum ttl
)
; name servers
ns1 IN A 46.252.125.14
@ IN NS ns1
; server entries
www IN A 192.168.1.1 ;
ftp IN A 192.168.1.2 ;
google IN CNAME www.google.de.
; domainname ohne server
dns.thomasbayen.de. IN A 192.168.1.3
Kommentare zum Inhalt der Zonendatei #
Zu dieser Zonendatei gibt es jetzt ein paar Anmerkungen zu machen:
- Der Eintrag $TTL gibt die Time-To-Live Zeit an, die verwendet wird, wenn im eigentlichen ResourceRecord der Zone keine angegeben wird. In meinem Fall habe ich 5 Minuten (300 Sekunden) angegeben. Das ist für eine oft benutzte Domain sehr kurz und belastet die auflösenden Server dann unnötig. Für meine eigenen Spielereien und solange ich eigentlich der einzige bin, der diese Namen benutzt, ist das aber ok. Außerdem bietet es die Möglichkeit, zum Test Änderungen vorzunehmen und wenige Minuten später das Ergebnis über eine ganz normale "offizielle" DNS-Anfrage zu sehen.
- Der Name "dns.thomasbayen.de." endet mit einem Punkt. Das bedeutet, das es sich um einen absoluten Namen handelt und dieser nicht relativ zur verwalteten Domain ist. Der (etwas tiefer stehende) Eintrag "www" bedeutet also, das die Adresse "www.dns.thomasbayen.de" gemeint ist.
- Der Eintrag ab "dns.thomasbayen.de." bis zur schließenden Klammer ist der sogenannte SOA ResourceRecord. Hier werden Angaben zur gesamten Zone gemacht. Hier wird z.B. (also erstes) der Name eines Nameservers angegeben. (Dieser Name wird dann weiter unten definiert, weil er in unserer eigenen Zone liegt.)
- Dahinter kommt eine Mailadresse, in der jedoch das @ durch einen Punkt ersetzt ist und auch ein Punkt am Ende steht. Das muss man als Format einfach so hinnehmen...
- Die Serial No ist eine Zahl, anhand derer Bind neue Versionen der Zonendatei erkennen kann. Das wird (soweit ich verstanden habe) nur für sogenannte Zonentransfers genutzt. Dabei lädt ein anderer Server (ein secondary nameserver) die gesamte Zonendatei von dem Hauptserver (primary nameserver) neu herunter, wenn sich die Seriennummer geändert hat.
- Die refresh, retry und expire-Werte betreffen ebenfalls die Funktion eines secondary nameservers. Das soll hier zuerst einmal nicht weiter ausgeführt werden.
- Das ttl-Feld hatten wir ja weiter oben schon beschrieben
- In der Zonendatei kann überall "@" als Abkürzung benutzt werden für die aktuelle Domain (also im Beispiel für "dns.thomasbayen.de.").
- A-ResourceRecords beschreiben die Zuordnung eines Namens zu einber IP-Adresse und sind somit die wixhtigsten Zeilen
- NS-ResourceRecords beschreiben einen Nameserver für die angegebene Domain. Sie müssen immer auf einen Namen zeigen und nicht auf eine IP-Adresse. Da aber ein Nameserver natürlich immer eine feste IP-Adresse braucht, muss man also gleichzeitig noch einen A-Record haben, der aus dem Namen eine IP-ADresse macht. (Man kann natürlich auch einen bereits vorhandenen Namen eines Nameservers ausserhalb der eigenen Domain benutzen, aber das wollten wir hier im Beispiel ja genau nicht machen).
- Der letzte Eintrag zeigt, wie man mit dem Sternchen "*" auch den Domainnamen selber erreichbar macht, wenn kein Subname für einen Host angegeben ist.
- Übrigens kann man den TTL-Wert für jeden Record einzeln ändern, wenn man das möchte. Dazu gibt man eine Zeit vor dem Schlüsselwort "IN" an. Siehe http://www.zytrax.com/books/dns/apa/ttl.html (In meinem Beispiel habe ich das nicht genutzt)
Test der Konfiguration #
Mit einem Befehl wie diesem kann man den Nameserver direkt abfragen:
dig @46.252.125.14 www.dns.thomasbayen.de
Nameserver in das DNS-System einbinden #
Damit nun auch die Nameserver meines Internet-Providers meine neuen Adressen auflösen können, muss ich ihnen sagen, das mein Nameserver da ist. Hierzu brauche ich Zugriff auf eine vorhandene und offizielle Zonendatei. In meinem Beispiel ist die Domain thomasbayen.de über meinen Provider (Domainfactory, kurz DF) registriert. Nun ist DF dafür verantwortlich, für die Domain "dns.thomasbayen.de" meinen eigenen Nameserver einzubinden. Ich weiss natürlich nicht, wie und ob das bei anderen Providern geht. Bei DF gibt es für sogenannte Reseller-Tarife eine schöne Weboberfläche hierzu.
Ich brauchte zwei Einträge: Zuerst einen A-Eintrag, der meinem Nameserver einen Namen zuordnet. Dieser Name darf natürlich nicht in der vom Nameserver selber verwalteten Zone liegen. Er kann aber eine Third-Level-Domain unter derselben Hauptdomain wie meine eigene Zone sein. Falls der Nameserver bereits einen DNS-Namen hat, kann man natürlich auch diesen benutzen. Das kann einerseits sein, wenn man den gleichen Server bereits für was anderes benutzt, andererseits stellt vielleicht der Hosting-Provider einen zur Verfügung (Die Jiffybox-Server z.B. haben Namen der Art "j97577.servers.jiffybox.net"). Als zweiten Eintrag erzeuge ich dann einen NS-Eintrag, der den soeben eingerichteten Namen als Nameserver angibt.
In Zonenfile-Notation sieht das dann so aus:
ns.thomasbayen.de. IN A 46.252.125.14 dns.thomasbayen.de IN NS ns.thomasbayen.de.
Falls die Zone thomasbayen.de vorher von irgendwoher benutzt wurde, kann es gut sein, das die alte Einstellung noch irgendwo gecachet ist. Deshalb kann es bis zu 48 Stunden dauern, bis alle Nameserver die neue Einstellung übernommen haben und der folgende Befehl weltweit funktioniert:
dig www.dns.thomasbayen.de
Wer das vorher schonmal ausprobieren möchte, kann evtl. schneller (bei DF nach wenigen Minuten) probieren, den Nameserver des Providers direkt anzurufen. Das geht bei DF dann so:
dig @ns.namespace4you.de www.dns.thomasbayen.de
Dabei ist zu beachten, das man bei DF nicht die TTL dieser Einträge anpassen kann. Das heisst, das die Tatsache, das mein eigener Nameserver für die Subdomains verantwortlich ist, nicht so schnell geändert werden kann. Die hosts innerhalb dieser Domain kann ich allerdings auf meinem eigenen Nameserver konfigurieren und dort die TTL auch kürzer setzen.
Alternative zu Zonendateien #
Für Bind gibt es eine Erweiterung, die sich DLZ nennt. Diese erlaubt, Zonen-Informationen aus einer (z.B. SQL-) Datenbank zu holen anstatt aus den Zonen-Dateien. Für grosse und vor allem dynamische Einrichtungen kann das ein Weg sein. Leider ist das für SQL-Datenbanksysteme im Debian-Paket von BIND nicht einkompiliert (siehe Debian-Bug 273440) und daher nicht out-of-the-box benutzbar. Man muss also ggf. BIND neu kompilieren, um das zu nutzen.
Natürlich kann man auch verschiedene andere Nameserver anstelle von Bind einsetzen. z.B. DnsMasq holt seine Informationen aus der /etc/hosts-Datei. Obwohl ihm viele Funktionen von Bind fehlen, ist er eine gute Alternative, um im lokalen Netz mal eben ein paar Rechner einzurichten.
Mögliche Spielereien #
Nun bleibt natürlich die Frage, was man mit so einem eigenen öffentlichen Nameserver machen kann. Wer als Mitglied der LUG Krefeld keinen Zugang zu einem Provider hat, der die Einstellung der DNS-Record erlaubt, kann mich übrigens gerne um Hilfe bitten (ThomasBayen).
Hier ein paar Beispiele:
lokale Namen für ein VPN #
Wer mehrere Rechner hat, die sich per VPN in das Unternehmensnetzwerk einfinden, hat u.U. ein Problem: Wer interne Rechner mit dem Laptop per VPN auffinden möchte, muss deren Namen auflösen. Sind diese Namen nur intern bekannt, muss hierzu ein interner Nameserver benutzt werden. Das bedeutet, das man den ganzen Laptop auf diesen Nameserver umstellen muss (normalerweise kann das beim VPN-Verbindungsaufbau automatisch konfiguriert werden). Allerdings werden dann alle DNS-Abfragen durch den VPN-Tunnel geschickt, der je nach Verbindung eine recht hohe Latenz hat. Wer bei bestehen einer VPN-Verbindung dennoch oft normale Webseiten aufruft, wird sehen, das hierdurch der Internet-Zugriff deutlich langsamer wird.
Hier bietet es sich an, interne Namen öffentlich zu definieren. Es ist kein Problem, im öffentlichen Webserver private IP-Adressen (z.B. der Form 192.168.x.x) anzugeben. Diese können dann natürlich nur sinnvoll von Rechnern benutzt werden, die im LAN stecken (oder per VPN ans LAN angeschlossen sind).
dynamisches DNS #
Wie auf der Seite DynamischesDNS bereits geschrieben, kann man für Wählverbindungen (also für normale Internet-Anschlüsse), die immer wechselnde IP-Adressen bekommen können, bei jedem Verbindungsaufbau den entsprechenden Namens-Eintrag selber ändern. Hierdurch kann man eine Art eigener DDNS-Provider werden. Dies kann insbesondere interessant sein, weil einige der bekannten DDNS-Provider (wie DynDNS) inzwischen nicht mehr kostenlos benutzt werden können. Ehrlich gesagt gibt es immer noch eine Menge kostenloser Dienste, aber das ist nbatürlich lange nicht so cool wie selber machen.
Es gibt verschiedene Lösungen, die per CGI-Skript auf dem Webserver (z.B. in Perl oder PHP) die Zonendatei ändern (z.B. hier). Das hat den Vorteil, das die API per http recht einfach und ggf. sogar kompatibel zu Lösungen wie DynDNS ist.
Es gibt aber auch die Möglichkeit, per nsupdate direkt Änderungen in den laufenden Bind zu schieben. Eine schöne (deutsche) Anleitung zur einer nsupdate-Lösung gibt es hier
IP over DNS #
Eine ausgefallene Anwendung ist iodine. Dabei handelt es sich um eine Implemetierung des IP-Protokolls, die ausschließlich über DNS funktioniert. Eine Anwendung wäre, das man einen Tunnel erzeugen kann, der IP-Daten überträgt, wo diese eigentlich gesperrt sind, aber DNS-Daten durchkommen. Das ist z.B. bei vielen öffentlichen und unverschlüsselten aber durch ein kostenpflichtiges Passwort geschützten Access Points der Fall (z.B. in Hotels oder an öffentlichen Plätzen).
Der eigentliche Grund, sowas zu machen, dürfte aber sein, das es einfach ein cooler Hack ist. ;-)
Iodine ist als einfaches Debian-Paket zu erhalten. Dabei ist darauf zu achten, das Server und Client die gleiche Version installiert haben (0.6.x in meinem Beispiel). Dann kann man folgendes in /etc/default/iodine konfigurieren:
START_IODINED="true" IODINED_ARGS="192.168.202.1 dns.thomasbayen.de" IODINED_PASSWORD="geheimespasswort"
Den Client startet man nun mit
iodine -P geheimespasswort dns.thomasbayen.de
Sofort öffnet sich ein tun-Device, das man benutzen kann, um eine Verbindung zu seinem Server aufzubauen.
iodine und bind kombinieren #
Da iodine als eigenständiger Nameserver agiert, ersetzt er sozusagen einen Bind. Wer mit beidem gleichzeitig herumspielen will, muss entweder zwei Server dafür benutzen oder die Weiterleitung von iodine benutzen. Dazu fügt man in der Datei /etc/bind/named.conf.options diese Zeile ein (innerhalb des "options"-Blocks):
listen-on port 10053 { any; };
Dann kann man die Definition von IODINED_ARGS in /etc/default/iodine folgendermassen ändern:
IODINED_ARGS="-b 10053 192.168.99.1 dns2.thomasbayen.de"
Hierbei ist zu beachten, das man nun zwei Domains einrichten muss, da ja jeder der beiden Nameserver eine davon verwalten soll. Also müssen auch beide Domains (dns... und dns2...) beim Provider einen entsprechenden NS-Eintrag erhalten.
weitere Möglichkeiten #
Weitere Tricks wie Routing durch den iosine-Server etc. habe ich noch nicht ausprobiert. Auch mit dem Android-Client für iodine würde ich bei Gelegenheit gerne nochmal herumspielen.