BIND ist ein Open-Source-Programmpaket für die Namensauflösung im Domain Name System. Sein Name geht zurück auf den Berkeley Internet Name Domain Server, kurz BIND Server. Neben dem Server umfasst das Programmpaket einen Client und Testprogramme. Der Server ist mit großem Abstand der am weitesten verbreitete seiner Art im Internet. 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 1980er Jahre wurde 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 der Non-Profit-Organisation 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. Dessen erste Version BIND 9.0.0 erschien am 16. September 2000. BIND 9 gilt seit 2007 als Standard und bildet zusammen mit der noch verbreiteten Version 8 das Rückgrat des weltweiten Domain Name Systems.
Ab August 2007 wurde die Version 8 nicht mehr gepflegt (Deprecated) und ISC legte allen Nutzern nahe, auf Version 9 zu wechseln.
Am 1. April 2009 begann die Entwicklung von Bind 10, am 21. Februar 2013 wurde die Version BIND 10: 1.0.0 veröffentlichtBIND10 1.0.0 is now available.
Am 23. April 2014 erklärte das ISC überraschend, die weitere Entwicklung von BIND10 einzustellen. Man wolle sich künftig auf die Weiterentwicklung von BIND9 konzentrieren.
Sicherheit Version 4 galt bereits 2007 als veraltet und der Weiterbetrieb von BIND-4-Servern als Sicherheitsrisiko; auch die Weiterentwicklung von BIND 8 wurde 2007 eingestellt. Das ISC empfahl daher allen DNS-Administratoren die schnellstmögliche Migration zu BIND 9, auf der ISC-Website wurden hierzu umfangreiche Informationen bereitgestellt. Wegen der gegebenen weitestgehenden Interoperabilität zwischen den Versionen gab es keinen technischen Zwang zur Migration, weshalb die Entwickler häufig Überzeugungsarbeit hierzu leisten mussten, z. B. auf der Mailing-Liste [email protected].
Im Februar 2008 entdeckte Dan Kaminsky eine neuartige Angriffsmethode, die DNS-Cache-Poisoning mit geringem Zeitaufwand ermöglicht, um den Nutzer durch gefälschte DNS-Antworten auf andere Server umzuleiten. Es handelt sich dabei um eine Lücke im Design des Domain Name Systems, von der neben BIND auch mehrere andere Nameserver betroffen waren. In Zusammenarbeit mit Nameserver-Entwicklern und -Betreibern, unter anderem Paul Vixie, wurden Patches entwickelt, um die Wahrscheinlichkeit eines erfolgreichen Angriffs zu senken. Im Juli 2008 veröffentlichte Kaminsky Details zu der Sicherheitslücke und schätzte, dass noch 41 % der DNS-Server angreifbar seien.
Konfiguration Das Verhalten von BINDs zentraler Programmkomponente, dem Daemon „named“, wird durch Konfigurations- und Zonendateien bestimmt, die manuell vom Administrator oder automatisch über Skripte, aber auch mit Hilfe von Frontends erstellt oder verändert werden können. Für den grundlegenden Betrieb sind mindestens zwei Dateien notwendig, einmal die Konfigurationsdatei, oft „named.conf“ genannt, und pro Zone eine Zonendatei, deren Name gewöhnlich aus dem Zonennamen und der Dateiendung „.db“ gebildet wird. Anstelle von Plain-text-Dateien können auch Datenbanken, zum Beispiel BDB, als Quelle genutzt werden, dazu muss ein geeignetes Treibermodul mit einkompiliert werden.
Die offizielle BIND-Dokumentation ist das BIND 9 Administrator Reference Manual, kurz ARM genannt. Dort erhält man einen umfassenden, trotzdem gut verständlichen Überblick über alle Konfigurationsdirektiven sowie den Aufbau der Zonendateien.
Zonendateien Der Begriff der Zone wurde im Kontrast zur Domain geprägt, weil sie zwar miteinander verwandt, aber nicht notwendigerweise kongruent sind: eine Zone kann durchaus eine Teilmenge einer Domain darstellen und zum anderen nicht auf Host-Deklarationen innerhalb einer Domain beschränkt sein, sondern Verweise auf Hosts in „Fremd“-Domains enthalten.
Die Master-Zonendateien enthalten mindestens einen SOA Resource Record und einen oder mehrere für die Zone aussagefähige Nameserver (NS Resource Records), weiterhin eine beliebige Anzahl weiterer Resource 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 wird. Die RRs stellen also Wertepaare dar, getrennt durch die Typzuweisung – A, NS, SOA usw. – und optionale zusätzliche Attribute, nämlich eines Time-to-live-Wertes sowie einer Klassenbezeichnung, („IN“ für Internet, welches bei Fehlen der Klassenangabe als Default angenommen wird, sowie „CH“ für CHAOSnet und „HS“ für Hesiod, zwei Bezeichnungen für historische Vorstufen der Internet-Entwicklung, mittlerweile irrelevant). LinkeSeite kann auch leer sein (als White Space, d. h. Leer- oder Tabulator-Zeichen), dann gilt jeweils der LinkeSeite-Wert des vorangehenden RRs.
Mithin werden links immer die möglichen abfragbaren Informationen und rechts die zugehörigen Antwortwerte notiert. So liefert ein A-RR die einem Hostnamen zugeordnete IP-Adresse zurück („localhost IN A 127.0.0.1“); PTR-RRs dagegen dienen dem Umkehrfall, der Zuordnung von bestimmten Hostnamen zu abgefragten IP-Adressen (reverse DNS, „127.0.0.1 IN PTR localhost.“).
Zonendateien für Vorwärts- und Rückwärtsauflösung müssen konsistent formuliert werden; wie auch grundsätzlich gilt, dass für jede einzelne abfragbare Information ein RR in der betreffenden Zonendatei vorhanden sein muss: es gibt keine automatische, deduktive Ableitung irgendwelcher DNS-Informationen, wie es etwa für die Bereitstellung der reverse-DNS-Auflösung denkbar wäre (indem man z. B. PTR-Anfragen durch „inverse“ Auflösung vorhandener A-RRs – RechteSeite: Frage, LinkeSeite: Antwort – beantworten würde).
Allerdings sind sog. „Wildcard“-RRs möglich, bei denen ein Stern („*“) auf der linken Seite für beliebige Hostnamen steht. Diese gelten jedoch grundsätzlich als problematisch, weil sie ein weiteres Szenario für Angriffe auf die Integrität eines Netzes oder Dienstes eröffnen: es wird beliebigen Rechnern erleichtert, eine falsche Identität anzunehmen.
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 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 autoritativen (wird weiter unten erläutert), also verbindlich aussagekräftigen, Nameserver registriert (mithin ein NS-RR), diesen ergänzt man oft noch durch einen A-Record mit der IP-Adresse des betreffenden Subdomain-Nameservers, den sog. Glue-Record (der Begriff „Glue“ – engl. für Leim – symbolisiert, dass auf diese Art und Weise die hierarchische Anbindung zwischen Domain und Subdomain hergestellt wird).
Letzterer kann (bzw. muss sogar) entfallen, wenn der Subdomain-Nameserver selbst weder in der Sub- noch der übergeordneten Domain verankert ist (mithin in einer „Dritt“-Domain liegt, für die der gerade abgefragte Nameserver nicht autoritativ ist; BIND 9 weist solche A-RRs als „out-of-zone data“ zurück und verweigert das Laden der betreffenden Zone und damit ggf. den Programmstart). Während eine solche Konstellation ansonsten problemlos realisierbar ist, wird man jedoch in den meisten Fällen – organisatorisch betrachtet – es vorziehen, das Hosting der Subdomain-Zone entweder an einen Nameserver in dieser Subdomain zu delegieren oder aber „selbst zu erledigen“, mit anderen Worten: auf dem Nameserver der übergeordneten Domain vorzuhalten.
Ist ein Glue-Record vorhanden, befähigt das den Nameserver zu sogenannten 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-Adresse für sub.example.com kenne ich nicht. Aber ns.sub.example.com kann weiterhelfen, Du findest ihn unter der IP-Adresse 192.168.50.1.“ Ohne Glue-Record würde der letzte Teilsatz entfallen, bzw. müsste lauten: „Finde die IP-Adresse 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. An dieser Stelle liegt es, sowohl bei vorhandenem als auch fehlendem Glue-Record, ohnehin immer in der Verantwortung des Resolvers, sich zum gewünschten Subdomain-Nameserver „durchzuhangeln“ (wobei er sich jedoch der – weiter unten betrachteten – Fähigkeit eines Nameservers zur Rekursion bedienen kann, sofern nur dies dem betreffenden Client erlaubt ist).
Beispiel einer Zonendatei Das Beispiel gilt für eine Domain „example.com“ mit zugehörigem SOA- und NS-RR („ns.example.com“) einem Host „www.example.com“ einer Subdomain „sub.example.com“
Die „example.com“-Domain wird als Zonendatei „example.com.db“ 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 rela- ; tiv zur ff. Domain (anders ausgedrueckt: werden implizit durch $ORIGIN ergaenzt): $ORIGIN example.com. ; sofern hier nicht angegeben, ist der Wert von $ORIGIN implizit durch den in der zugehoe- ; rigen zone-Direktive (in named.conf) deklarierten Domainnamen bestimmt, ggf. kann letz- ; terer aber auch durch $ORIGIN ueberschrieben werden, daher ist auf Konsistenz zu achten
; Start of Authority und zustaendiger Nameserver sind obligatorisch für eine ; Zonendefinition ("@" ist ein Joker-Symbol für den Wert von $ORIGIN): @ SOA ns.example.com. hostmaster.example.com. 42 3600 1800 604800 1800 NS ns.example.com.
; weist dem Domainnamen example.com eine IP-Adresse zu (was ihn somit auch zu ; einem Hostnamen macht): A 192.168.0.100 AAAA 2001:db8::100
; macht der Welt die IP-Adresse des oben im SOA eingefuehrten ns.example.com bekannt: ns A 192.168.0.1 ns AAAA 2001:db8::1