BIND – Wikipedia

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.^[5] 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.

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^[6].

Am 1. April 2009 begann die Entwicklung von Bind 10^[7], am 21. Februar 2013 wurde die Version BIND 10: 1.0.0 veröffentlicht^[8][9].

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^[10].

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.^[11] 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 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.^[12]

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^[13]. Dort erhält man einen umfassenden, trotzdem gut verständlichen Überblick über alle Konfigurationsdirektiven sowie den Aufbau der 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 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 authoritativen, 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 authoritativ 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).

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  ; 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-Adresse 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 autoritativ ist (auf diesen Begriff wird gleich noch näher eingegangen).

Unterhalb der Second-Level-Domain-Hierarchiestufe 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 eine 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). Dabei kann der Administrator durch „notify“- und „allow-notify“-Direktiven genau festlegen, welcher Slave durch welchen Master zu benachrichtigen ist. Im „named.conf“-Beispiel weiter unten findet sich je ein Muster für eine Master- („zone "example.com" ...“) und eine Slave-Zonendefinition („zone "example.net" ...“).

Man bezeichnet Nameserver bzw. ihre Antworten als autoritativ, 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 autoritative Antworten generieren (auch wenn ein Slave „nur“ Kopien der Master-Zonen vorhält).

Neben dem Zugriff auf die in ihren Zonendateien verankerten Hostnamen beherrschen Nameserver auch das rekursive Auflösen „unbekannter“ Host- bzw. Domainnamen, dabei werden diese, von rechts beginnend, zerlegt und an die für die jeweiligen Top-Level- und Subdomains zuständigen Nameserver gerichtet. Die Abfrage beginnt dabei bei den Root-Nameservern, deren IP-Adressen jedem Nameserver vorab bekannt sein müssen und die ihrerseits Verweise auf die Nameserver der Top-Level-Domains zurückgeben.

Verantwortungsbewusste DNS-Administratoren konfigurieren ihren Server nun allerdings so, dass zunächst ein oder mehrere (netz-)topologisch „benachbarte“ (bzw. „übergeordnete“) Nameserver befragt werden (das sog. Forwarding), ehe eine vollständige Rekursion über die Root-Server veranlasst wird (um letztere zu entlasten). Dabei spekuliert man darauf, dass bei den Forwardern die Wahrscheinlichkeit höher ist, dass die benötigte Information (oder Teile davon, etwa die Auflösung der abgefragten Top-Level-Domain) schon in ihrem Cache vorliegt.

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.0/16; };“), da dies sonst als Einfallstor für Denial-of-Service- und Cache-Poisoning-Attacken aus dem Internet ausgenutzt werden kann.

Die Informationen sind in verschiedenen Bereichen untergebracht. Die wichtigsten sind:

Globaler Bereich

genau eine „options {...};“-Direktive

Server-Liste

beliebig viele „server {...};“-Direktiven

Zonen-Liste

beliebig viele „zone {...};“-Direktiven

controls-Bereich

eine „controls {...};“-Direktive

logging-Bereich

eine „logging {...};“-Direktive

Im Globalen Bereich werden Zugriffsberechtigungen, Krypto-Keys und Optionen definiert (siehe Abschnitt BIND-Options^[14] in der Online-Dokumentation). In der (optionalen) Serverliste sind Informationen über Partner-Server enthalten (z. B. ob ein Server inkrementellen Zonentransfer unterstützt). In der Zonen-Liste ist für jede bereitzustellende Zone ein Eintrag enthalten, der den Namen der Zone, den Namen des zugeordneten Zonenfiles, den Zonen-Typ (Master oder Slave), Zugriffsberechtigungen sowie Options enthält. Mit letzteren können auch global schon definierte Options wieder überschrieben werden (und sind 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-Adresse 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 sind trivial und 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 nr, a tribute to Douglas Adams         1h   ; refresh         5m   ; retry         7d   ; expire         1d ) ; minimum TTL     IN  NS  @     IN  A   127.0.0.1     IN  AAAA ::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. 

; File "localhost-rev6.db": $ORIGIN 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa. $TTL 1d @   IN  SOA localhost. hostmaster.localhost. (             42   ; serial             4h   ; refresh             30m  ; retry             7d   ; expire             1d ) ; minimum TTL  NS  localhost. 1 PTR localhost. 

Die „root“- bzw. „hint“-Zone (Direktive „zone "." IN {type hint; ...};“ im „named.conf“-Beispiel) kann ggf. weggelassen werden, da eine entsprechende Liste der Root-Server schon im Programmcode verankert ist. Durch Download einer aktuellen „named.root“-Datei und Einbinden wie gezeigt kann jedoch leicht, d. h. ohne Quelltext-Modifikation und Neuübersetzung, auf Änderungen reagiert werden (die Liste der Root-Server wird zwar nur selten geändert, zuletzt aber am 12. Dezember 2008).

Das Format der „named.root“-Datei entspricht dem einer normalen Zonendatei mit NS- und A-RRs, jedoch ohne vorangestellten SOA-RR. Sie kann – neben dem Download bei der IANA – z. B. durch den Befehl

    $> dig NS . @a.root-servers.net >named.root 

beschafft werden, sofern die aktuelle Adresse des A-Root-Nameservers bekannt ist.

Der controls-Bereich definiert einen Control-Port als Schnittstelle für das rndc-Steuerprogramm und im logging-Bereich werden verschiedene Typen von Logdateien 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 ;   forward first;   forwarders { 172.27.157.16; }; };  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 "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa" IN {   type master;   file "localhost-rev6.db";   notify no; };   zone "." IN {   type hint;   file "named.root"; };  zone "example.com" {   type master ;   file "example.com.db" ;   notify explicit;   also-notify { 172.27.157.16; }; };  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; }; }; 

Nach dem Einlesen der Konfigurationsdateien nimmt BIND alle Pakete entgegen, die per UDP oder TCP am Port 53 der konfigurierten Schnittstellen oder IP-Adressen eintreffen. Bei diesen Paketen kann es sich um DNS-Abfragen, dynamische Updates oder Zonentransfers handeln. Normalerweise verwenden DNS-Anfragen UDP (einzelne IP-Pakete), nur wenn insbesondere bei Zonentransfers die Server-Antworten die maximale IP-Paketgröße überschreiten, wird auf TCP umgeschaltet.

Liegt eine DNS-Abfrage vor, so versucht BIND, sie anhand der Einträge in den Zonendateien aufzulösen. Bei unbekannten Domainnamen (Anfragen für nicht-authoritative Hostnamen) wird in der Regel zunächst der eigene, dann der Cache der Forwarder überprüft und zuletzt eine rekursive Auflösung über die Root-Server versucht.

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.

Bei UNIX- oder Linux-Systemen ist BIND manchmal im Lieferumfang enthalten. Neue Versionen können aus dem Internet entweder als Binärpaket (für Windows) oder als Sourcecode 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 ein Hilfsprogramm enthält, welches die Einrichtung von named als Systemdienst unterstützt.

Bei Änderungen in Zonenfiles darf nicht vergessen werden, deren 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) beziehungsweise rndc (BIND 9). Ohne diese Signalisierung muss erst die in der Zone eingetragene Time-to-live-Frist verstreichen, ehe named die Zone erneut lädt.

Der Dienstprogramm-Name ndc bzw. rndc bedeutet (remote) name daemon controller. Neben Befehlen zum Starten und Stoppen des Daemons sowie zum Neuladen der Konfiguration und von Zone-Files stehen eine Reihe von Logging- und Statistik-Funktionen zur Verfügung, mit denen die Arbeit der Software überprüft werden kann. Insbesondere, wenn BIND unter Betriebssystemen läuft, die Threads unterstützen, oder wenn dynamische Zone-Updates unterstützt werden, sollte unbedingt immer der Befehl rndc stop zum Beenden des Dienstes verwendet werden. Bevor der Nameserver mit rndc zusammenarbeitet, müssen die dazu autorisierten Hosts in „named.conf“ eingetragen sein; der Datenaustausch zwischen Daemon und rndc wird kryptografisch über einen Schlüssel abgesichert, der in „named.conf“ und „rndc.conf“ eingetragen sein muss. Standardmäßig arbeitet rndc über Port 953 (in Anlehnung an den für DNS reservierten Port 53); gegebenenfalls müssen Firewall-Regeln dafür eingerichtet werden.

• graph your dnscache, tinydns, BIND 8 & 9 DNS queries/sec (Memento vom 16. August 2007 im Internet Archive) (englisch)
• dnstop und DNS statistics collector (englisch) (dsc)
• DNS server survey (englisch): 70 % aller Domains verwenden Bind als Nameserver
• Secure BIND Template (englisch). Informationen zur Absicherung eines BIND-Servers.