BIND
BIND (Berkeley Internet Name Domain, vormals auch -Daemon) ist ein Betriebssystemen (z.B. UNIX, NetBSD, FreeBSD, OpenBSD, Linux, Mac OS X, Windows_NT, z/OS) ein Domain-Name-System-Server implementiert werden kann. BIND kann kostenlos bezogen werden, der Source-Code ist veröffentlicht. Aufgrund seiner weiten Verbreitung und der zeitnahen Umsetzung der aktuellen DNS-RFCs gilt BIND seit Jahren als DNS-Referenzsoftware.
Geschichte
Bevor es DNS gab, wurde die Auflösung von Namen in IP-Adressen über Listen (/etc/hosts.txt, vgl. /etc/hosts auf heutigen Unix-Systemen) vorgenommen, die auf jedem Rechner im Internet vorhanden sein mussten. Änderungen wurden zunächst manuell auf einem Masterserver durchgeführt und dann per Datei-Download an die einzelnen Rechner verteilt. Mit steigender Anzahl von IP-Teilnehmern wurde dieses Verfahren zunehmend unhandlicher.
1983 wurde von Paul Mockapetris das Domain Name System (DNS) spezifiziert. Im gleichen Jahr wurde die erste DNS-Software ? JEEVES ? auf einem DEC-Rechner implementiert. Wenig später gingen die ersten drei Internet-Root-Server in Betrieb.
Anfang der 80er Jahre wurden an der Universität Berkeley an der Weiterentwicklung von UNIX gearbeitet. Einige Studenten begannen, für UNIX eine DNS-Software zu schreiben, die sie BIND (Berkeley Internet Name Domain) tauften. BIND wurde ständig weiterentwickelt, und die Version 4 wurde zum weltweiten Standard. Nachdem die Berkeley Universität die Weiterentwicklung der Software eingestellt hatte, wurde die Verantwortung für kurze Zeit von der Firma DEC und anschließend von Vixie Enterprises übernommen. Paul Vixie war zu dieser Zeit treibende Kraft hinter dem Projekt.
Ab der Version 4.9.3 ging BIND in die Verantwortung des herstellerunabhängigen ISC (Internet Software Consortium ? ab 2004: Internet Systems Consortium) über. Die Version 8 wurde 1997 fertiggestellt. 1999 beauftragte ISC die Firma Nominum Inc., die Version 9 zu entwickeln. BIND 9 ist heute (Anfang 2007) Standard und bildet zusammen mit der noch verbreiteten Version 8 das Rückgrat des weltweiten Domain Name Systems; Version 4 gilt als veraltet.
Konfiguration
Bei BIND handelt es sich letztlich um ein normales Computerprogramm: Es wird gestartet, es tut etwas und es wird beendet (oder beendet sich selbst), letzteres allerdings gemäß der Rolle eines Daemons eher selten bzw. nur im Fehlerfall. Das Verhalten des Programms wird von manuell zu erstellenden Konfigurationsdateien bestimmt, die bei Programmstart eingelesen werden. Es existiert eine globale Datei ? meist mit dem Namen named.conf ? und pro Zone eine Zonendatei, deren Name gewöhnlich aus dem Zonennamen und der Extension .db gebildet wird (es sind auch beliebige andere Namen zulässig; außerdem können anstelle von einfachen Textdateien auch Datenbanken, z. B. vom Typ BDB, als Quelle für Zoneninformationen dienen, dazu ist das Eincompilieren eines geeigneten Datenbank-Treibers in das named-Binary notwendig).
:Beispiel: Angenommen, der Nameserver soll Master für die Zonen example.com und sub.example.com sein. Dann müssen folgende Dateien vorhanden sein: named.conf, example.com.db und sub.example.com.db. Der Begriff der Zone wurde im Kontrast zur Domain geprägt, weil eine Zone zum einen eine Teilmenge einer Domain darstellen kann, und zum anderen nicht auf Host-Deklarationen innerhalb einer Domain beschränkt ist, sondern durchaus auch Verweise auf Hosts in ?Fremd?-Domains enthalten kann.
Die Master-Zonendateien enthalten mindestens einen SOA Resource Record, einen oder mehrere für die Zone aussagefähige Nameserver (NS Resource Records) und eine beliebige Anzahl weiterer Ressource Records (RRs) wie zum Beispiel A Resource Records oder PTR Resource Records. Allgemein notiert man RRs so:
LinkeSeite [optional:Time-to-live-Wert] [optional:Class-Name] Typ RechteSeite
LinkeSeite und RechteSeite sind grundsätzlich Zeichenketten, deren Format vom Typ bestimmt werden.
Die RRs stellen also Wertepaare (getrennt durch die Typzuweisung - A, NS, SOA usw. - und optionale zusätzliche Attribute, nämlich eines Time-to-live-Wertes sowie einer Klasse, bei deren Wahlmöglichkeiten historisch begründet nur noch ?IN? für Internet relevant ist) dar, deren rechte Seiten jeweils die Antwort auf die auf der linken Seite formulierten möglichen (abfragbaren) Werte darstellen. So liefert ein A-RR die einem Hostnamen zugeordnete IP-Nummer zurück; PTR-RRs dagegen dienen dem Umkehrfall, der Zuordnung von bestimmten Hostnamen zu abgefragten IP-Nummern (reverse DNS). Eine automatische Ableitung der Rückwärts-Auflösung aus vorhandenen A-RRs ist im Domain Name System nicht vorgesehen, die Zonendateien für Vorwärts- und Rückwärtsauflösung müssen daher konsistent formuliert werden; wie auch grundsätzlich gilt, dass für jede einzelne abfragbare Information ein RR vorhanden sein muss.
Die Zonendateien definieren damit den Inhalt einer Zone, im wesentlichen - aber nicht ausschließlich - sind das die Hostnamen innerhalb einer Domain (also A-RRs, welche naturgemäß am häufigsten durch DNS-Clients abgefragt werden). Ebenso definiert man den für eine Domain zuständigen Mailserver (MX Resource Record, Mail Exchanger), Alias-Namen zu vorhandenen Hostnamen (CNAME-RRs, Canonical Names) oder Meta-Informationen (TXT-RRs).
Subdomains definiert man durch sog. Zone Delegation: in der Zonendatei der übergeordneten Domain wird dazu der gewünschte Subdomain-Name als Verweis auf den für die Subdomain aussagekräftigen (authoritativen) Nameserver registriert (also ein NS-RR), diesen ergänzt man i. d. R. noch durch einen A-Record mit der IP-Nummer des Subdomain-Nameservers, den sog. Glue-Record; letzterer kann entfallen, wenn dieser Nameserver selbst weder in der Sub- noch der übergeordneten Domain verankert ist (mithin in einer ?Fremd?-Domain liegt, für die der gerade in Betracht gezogene Nameserver nicht authoritativ ist). Der Begriff ?Glue? (engl. für Leim) symbolisiert, dass auf diese Art und Weise die hierarchische Anbindung zwischen Domain und Subdomain hergestellt wird.
Ist ein Glue-Record vorhanden, befähigt das den Nameserver zu sog. Smart-Answers: wird im folgenden Beispiel ns.example.com nach dem Hostnamen sub.example.com gefragt (ein Client unterscheidet i. d. R. nicht weiter zwischen Host- und Domainnamen), lautet die Antwort sinngemäß: ?Eine IP-Nr. für sub.example.com kenne ich nicht. Aber ns.sub.example.com kann weiterhelfen, Du findest ihn unter der IP-Nr. 192.168.50.1.? Ohne Glue-Record würde der letzte Teilsatz entfallen, bzw. müsste lauten: ?Finde die IP-Nr. von ns.sub.example.com doch selbst heraus!? Dem Client, der hier auf seine eigentliche Anfrage eine Negativantwort erhalten hat, ist es (bei entsprechend ?smarter? Programmierung seiner Resolver-Bibliothek) freigestellt, stattdessen die zusätzlich übermittelten Informationen auszuwerten und somit einen DNS-Request zur Auflösung von ns.sub.example.com einzusparen.Beispiel einer Zonendatei (für Domain example.com mit enthaltener Subdomain sub.example.com; diese Zone wird auf ns.example.com gehostet):
; die Time-to-live-Direktive ist seit BIND v8 am Beginn einer Zonen-
; datei vorgeschrieben; sie gilt für alle RRs ohne explizites TTL-Feld:
$TTL 1d
; optionale Direktive; alle Hostnamen OHNE nachgestellten "." in dieser Zone sind re-
; lativ zur ff. Domain (anders ausgedrueckt: werden implizit durch $ORIGIN ergaenzt):
$ORIGIN example.com.
; Start of Authority und zustaendiger Nameserver sind obligatorisch für eine
; Zonendefinition ("@" ist ein Joker-Symbol für den $ORIGIN):
@ SOA ns.example.com. hostmaster.example.com. 42 3600 1800 604800 1800
NS ns.example.com.
; weist dem Domainnamen example.com eine IP-Nr. zu (was ihn somit auch zu
; einem Hostnamen macht):
A 192.168.0.100
; macht der Welt die IP-Nr. des oben eingefuehrten ns.example.com bekannt:
ns A 192.168.0.1
; definiert den Host www.example.com als Alias von example.com:
www CNAME @
; definiert die Domain sub.example.com mit dem
; zustaendigen Nameserver ns.sub.example.com:
sub NS ns.sub
; Glue: Anfragen nach der IP-Nummer dieses Nameservers
; können direkt von ns.example.com beantwortet werden:
ns.sub A 192.168.50.1
Auf 192.168.50.1 muss dann ein weiterer Nameserver für die Zone sub.example.com residieren. Jedoch könnte man diese genauso gut von ns.example.com verwalten lassen - dazu ändert sich der vorletzte RR des Beispiels in sub NS ns, weiterhin kann der Glue-Record entfallen, da BIND hier selbständig erkennt, dass man für die Subdomain authoritativ ist (der Begriff ?authoritativ? wird weiter unten erklärt).
Unterhalb der Second-Level-Domain-Hierarchie kann jeder Betreiber eines Nameservers nach Belieben Subdomains definieren, in derselben ist das den Domain-Registraren vorbehalten, die ihrerseits Zugriff auf die Nameserver der Top-Level-Domains haben.
Da gemäß der DNS-Spezifikation Nameserver redundant vorgehalten werden sollen, aber das Pflegen identischer Zonefiles auf zwei oder mehreren unabhängigen Computern sehr umständlich und fehlerträchtig ist, unterscheidet man Master- und Slave-Server. Letztere holen ihre Zonendatei per Zonentransfer von einem zugewiesenen Master-Server. Dabei wird die im SOA-Record der Zone definierte Seriennummer auf Veränderung geprüft, nur nach Inkrementierung derselben erfolgt ein Slave-seitiges Übernehmen der Zonendaten; seit BIND v8 existiert auch ein Notify-Verfahren, bei dem der Master-Server Slaves über die Veränderung von Zone-Files benachrichtigt (um die Latenz der Zonen-Updates zu minimieren). Je ein Muster für eine Master- und eine Slave-Zonendefinition findet sich im ?named.conf?-Beispiel weiter unten.
Neben dem Zugriff auf die Zonendateien beherrschen Nameserver auch das rekursive Auflösen ?unbekannter? Domainnamen, dabei werden diese, von rechts beginnend, zerlegt und an die für die jeweiligen Toplevel- und Subdomains zuständigen Nameserver gerichtet. Die Abfrage beginnt dabei bei den sog. Root-Nameservern (deren IP-Adressen - es gibt derzeit weltweit [ftp://rs.internic.net/domain/named.root 13] - jedem Nameserver vorab bekannt sein müssen), welche ihrerseits Verweise auf die Nameserver der Toplevel-Domains liefern. Verantwortungsbewusste DNS-Administratoren konfigurieren ihren Server allerdings so, dass zunächst ein oder mehrere (netz-)topologisch ?benachbarte? Nameserver befragt werden (sog. Forwarding), ehe eine Rekursion veranlasst wird.
Aus der traffic-minimierenden Vermaschung interagierender Nameserver sowie dem Zwischenspeichern (Caching) der gewonnenen Informationen mit wohldefinierten Minimal- und Maximal-?Haltbarkeitsfristen? ergibt sich die optimierte, kooperative Arbeitsweise des internetweiten Domain Name Systems.
Während Forwarding bei einer ?fabrikneuen? BIND-Distribution standardmäßig aktiviert ist (Option ?Forward first;?), ist beim Aktivieren von Rekursion Vorsicht angesagt. Bei einem Nameserver, der sowohl aus dem Intra- wie auch aus dem Internet erreichbar ist, sollte man Rekursion nur für Benutzer aus dem Intranet erlauben (z. B. durch eine Option wie ?allow-recursion { 192.168.0/24; };? ), da dies sonst als Einfallstor für Denial-of-Service- und Cache-Poisoning-Attacken aus dem Internet ausgenutzt werden kann.
Man bezeichnet Nameserver bzw. ihre Antworten als authoritativ, wenn die DNS-Anfragen unmittelbar aus einer vorliegenden Zonendatei beantwortet werden können, im Gegensatz zu durch Rekursion bzw. Forwarding gewonnenen DNS-Daten, die im Cache des Servers vorgehalten werden. Master- wie Slave-Nameserver können einander gleichwertig authoritative Antworten generieren.named.conf
Die Informationen sind in verschiedenen Bereichen untergebracht. Die wichtigsten sind:
* Globaler Bereich
* Server-Liste
* Zonen-Liste
* controls-Bereich
* logging-Bereich
Im Globalen Bereich werden Zugriffssberechtigungen, Krypto-Keys und Optionen definiert (siehe [http://www.isc.org/sw/bind//arm93/Bv9ARM.ch06.html BIND-Options]). In der Serverliste sind Informationen über Partner-Server enthalten (z.B. ob ein Server inkrementellen Zonentransfer unterstützt).
In der Zonen-Liste ist für jede Zone ein Eintrag enthalten, der den Namen der Zone, den Namen des Zonenfiles, den Zonen-Typ (Master oder Slave), Zugriffsberechtigungen sowie Options enthält. Mit letzteren können auch global schon definierte Options überschrieben werden (dann nur im Kontext der jeweiligen Zone gültig). In einer Minimal-Konfiguration eines Nameservers sind je eine Zonendatei für die Auflösung des Hostnamens ?localhost? in die IP-Nummer 127.0.0.1 sowie die diesbezügliche Reverse-Zone enthalten. Im ?named.conf?-Beispiel weiter unten sind das die ersten beiden ?zone?-Direktiven. Die zugehörigen Zonendateien haben z. B. das folgende Aussehen (eine mögliche Zonendatei für die Domain ?example.com? wurde bereits weiter oben dargestellt):
; File "localhost.db":
$ORIGIN localhost.
$TTL 1d
@ IN SOA @ root (
42 ; serial
1h ; refresh
5m ; retry
7d ; expire
1d ) ; minimum TTL
IN NS @
IN A 127.0.0.1
; File "localhost-rev.db":
$ORIGIN 0.0.127.in-addr.arpa.
$TTL 1d
@ IN SOA localhost. hostmaster.localhost. (
42 ; serial
4h ; refresh
30m ; retry
7d ; expire
1d) ; minimum TTL
NS localhost.
1 PTR localhost.
Der controls-Bereich definiert einen Control-Port als Schnittstelle für das rndc-Steuerprogramm und im logging-Bereich werden verschiedene Typen von Logfiles und deren Zuordnung von Programm-Ereignissen (Abfragen, Fehler etc.) eingestellt.
Beispiel einer named.conf:
options {
allow-transfer {
localhost ;
172.27.157.16 ;
};
host-statistics YES ;
notify YES ;
};
server 172.27.157.16 {
bogus no ;
support-ixfr yes ;
};
zone "localhost" IN {
type master;
file "localhost.db";
notify no;
};
zone "0.0.127.in-addr.arpa" IN {
type master;
file "localhost-rev.db";
notify no;
};
zone "example.com" {
type master ;
file "example.com.db" ;
notify YES ;
};
zone "example.net" {
type slave ;
masters "ns.example.net" ;
file "slave/example.net.db" ;
allow-notify "ns.example.net" ;
};
controls {
inet * port 953 allow { localhost; }
keys { "rndc-key" };
};
key "rndc-key" {
algorithmus hmac-md5;
secret "password";
};
logging {
channel default-log { file "logs/named.log"; severity debug; print-severity yes; };
category default { default-log; };
channel queries-log { file "logs/queries.log"; severity info; };
category queries { queries-log; };
};
Funktionsweise
Nach dem Einlesen der Konfigurationsdateien nimmt BIND alle Pakete entgegen, die am UDP-Port 53 und TCP-Port 53 der konfigurierten Interfaces oder IP-Adressen eintreffen. Bei diesen Paketen kann es sich um DNS-Abfragen, dynamische Updates oder Zonentransfers handeln. Liegt eine DNS-Abfrage vor, so versucht BIND sie anhand der Einträge in den Zonendateien aufzulösen. Bei unbekannten Domainnamen wird zunächst der Cache überprüft und dann eine rekursive Auflösung versucht, wenn diese aktiviert ist. Bei dynamischen_DNS-Updates wird die betreffende Zonendatei zur Laufzeit des named-Daemons aktualisiert (RRs werden hinzugefügt bzw. auch wieder entfernt), sofern der auslösende Client dazu berechtigt und verifiziert ist. Dynamische DNS-Updates werden insbesondere eingesetzt, um in einem Intranet, in welchem die TCP/IP-Protokollstacks neu hinzukommender Rechner automatisch konfiguriert werden, diese unter ihrem aktuellen, nicht von einer statisch konfigurierten Zone vorgegebenen Hostnamen erreichbar zu machen.
Installation und Betrieb
Bei UNIX- oder Linux-Systemen ist BIND oft im Lieferumfang enthalten. Neue Versionen können aus dem Internet entweder als Binärpaket (für Windows) oder als Sourcecode [http://www.isc.org/index.pl?/sw/bind/ heruntergeladen] werden. Mittlere UNIX-Kenntnisse sind ausreichend zur Installation und Betrieb eines BIND-Servers. Bei Windows-NT/2000 wird eine komprimierte Binärdatei heruntergeladen. Die Installation ist einfach.
Bei Änderungen in Zonenfiles darf nicht vergessen werden, die Seriennummer zu inkrementieren und diese Änderung BIND bekannt zu machen, sei es durch einen kompletten Neustart des Servers, ein SIGHUP (UNIX) oder über die Management-Tools ndc (BIND 8) bzw. rndc (BIND 9). Es stehen eine Reihe von Logging- und Statistik-Funktionen zur Verfügung, mit denen die Arbeit der Software überprüft werden kann. Bevor der Nameserver auf rndc hört, müssen die dazu autorisierten Hosts in named.conf eingetragen sein; der Zugriff selbst wird über einen Schlüssel abgesichert, der in named.conf und rndc.conf eingetragen sein muss. Standardmäßig arbeitet rndc über Port 953; ggf. müssen Firewall-Regeln dafür eingerichtet werden.
Weblinks
* http://www.isc.org/index.pl?/sw/bind/ - offizielle Homepage
* http://www.campin.net/DNS/graph.html - graph your dnscache, tinydns, BIND 8 & 9 DNS queries/sec
* http://dns.measurement-factory.com/tools/ - dnstop und DNS statistics collector (dsc)
* http://mydns.bboy.net/survey/ - DNS server survey: 70% aller Domains verwenden Bind als Nameserver
