Zum Inhalt springen

Berkeley Internet Name Domain: Unterschied zwischen den Versionen

Aus Foxwiki
Versionsgeschichte interaktiv durchsuchen
← Zum vorherigen Versionsunterschied
VisuellWikitext
 
(50 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 1: Zeile 1:
= TMP =
'''Berkeley Internet Name Domain''' - Programmpaket zur Namensauflösung im Domain Name System
== Berkeley Internet Name Domain (BIND) ==
Die meisten modernen Netzwerke, einschließlich dem Internet, erlauben dem Benutzer andere Computer über deren Namen zu bestimmen. Dies befreit den Benutzer davon, die numerische Netzwerk-Adresse behalten zu müssen. Der effektivste Weg ein Netzwerk zu konfigurieren, sodass es namensbasierte Verbindungen zulässt, ist durch das Einrichten eines ''Domain Name Service'' (''DNS'') oder ''Nameserver'', welcher Rechnernamen in numerische Adressen auflöst und umgekehrt.


Dieses Kapitel stellt den in Red Hat Enterprise Linux enthaltenen Nameserver vor, den ''Berkeley Internet Name Domain'' (''BIND'') DNS Server, mit dem Fokus auf die Struktur dessen Konfigurationsdateien und der Art und Weise, wie dieser lokal und auch remote verwaltet werden kann.
 
== Beschreibung ==
; Berkeley Internet Name Domain (BIND)
Die meisten modernen Netzwerke, einschließlich dem Internet, erlauben dem Benutzer andere Computer über deren Namen zu bestimmen.
* Dies befreit den Benutzer davon, die numerische Netzwerk-Adresse behalten zu müssen.
* Der effektivste Weg ein Netzwerk zu konfigurieren, sodass es namensbasierte Verbindungen zulässt, ist durch das Einrichten eines ''Domain Name Service'' (''DNS'') oder ''Nameserver'', welcher Rechnernamen in numerische Adressen auflöst und umgekehrt.


; Warnung
; Warnung
: Wenn Sie das '''Domain Name Service Configuration Tool''' verwenden, sollten Sie die BIND-Konfigurationsdateien nicht manuell bearbeiten, da alle manuell vorgenommenen Änderungen vom '''Domain Name Service Configuration Tool''' beim nächsten mal überschrieben werden, wenn dieses benutzt wird.
: Wenn Sie das '''Domain Name Service Configuration Tool''' verwenden, sollten Sie die BIND-Konfigurationsdateien nicht manuell bearbeiten, da alle manuell vorgenommenen Änderungen vom '''Domain Name Service Configuration Tool''' beim nächsten mal überschrieben werden, wenn dieses benutzt wird.


 
== Einführung ==
=== Einführung ===
Wenn Hosts auf einem Netzwerk zu einem anderen über deren Hostnamen, auch ''fully qualified domain name (FQDN)'' genannt, verbinden, wird DNS verwendet, um die IP-Adressen der Rechner über deren Hostnamen zu bestimmen.
Wenn Hosts auf einem Netzwerk zu einem anderen über deren Hostnamen, auch ''fully qualified domain name (FQDN)'' genannt, verbinden, wird DNS verwendet, um die IP-Adressen der Rechner über deren Hostnamen zu bestimmen.


Die Verwendung von DNS und FQDN sind auch für Systemadministratoren vorteilhaft. Dank dieser Namen verfügen Administratoren über die Flexibilität, IP-Adressen für einzelne Rechner zu ändern, ohne namenbasierte Abfragen der Rechner ausführen zu müssen. Umgekehrt können die Administratoren festlegen, welche Rechner eine namenbasierte Abfrage in einer für die Benutzer transparenten Weise handhaben.
; Die Verwendung von DNS und FQDN sind auch für Systemadministratoren vorteilhaft
* Dank dieser Namen verfügen Administratoren über die Flexibilität, IP-Adressen für einzelne Rechner zu ändern, ohne namenbasierte Abfragen der Rechner ausführen zu müssen.  
* Umgekehrt können die Administratoren festlegen, welche Rechner eine namenbasierte Abfrage in einer für die Benutzer transparenten Weise handhaben.


DNS wird im Allgemeinen mit Hilfe zentralisierter Server implementiert, die für einige Domains authorisiert sind und sich auf andere DNS-Server für andere Domains beziehen.
; DNS wird im Allgemeinen mit Hilfe zentralisierter Server implementiert, die für einige Domains authorisiert sind und sich auf andere DNS-Server für andere Domains beziehen.


Eine Client-Applikation verbindet üblicherweise über den Port 53 mit dem Nameserver und fragt Informationen über diesen ab. Der Nameserver wird versuchen, mit Hilfe einer Resolver-Bibliothek den FQDN zu lösen. Diese Bibliothek kann die vom Host angeforderten Informationen oder Daten über den Namen aus einer früheren Abfrage enthalten. Wenn der Nameserver die Antwort nicht in seiner Resolver-Bibliothek findet, wird er andere Nameserver, die sogenannten ''Root-Nameserver'' verwenden, um festzulegen, welche Nameserver für diesen FQDN autorisiert sind. Mit dieser Information wird anschließend bei den autorisierten Nameservern dieser Name abgefragt, um die IP-Adresse festzustellen. Bei einem Reverse-Lookup wird die gleiche Prozedur durchgeführt, allerdings mit dem Unterschied, dass hier eine unbekannte IP-Adresse und nicht ein Name abgefragt wird.
; Eine Client-Applikation verbindet üblicherweise über den Port 53 mit dem Nameserver und fragt Informationen über diesen ab.  
* Der Nameserver wird versuchen, mit Hilfe einer Resolver-Bibliothek den FQDN zu lösen.  
* Diese Bibliothek kann die vom Host angeforderten Informationen oder Daten über den Namen aus einer früheren Abfrage enthalten.  
* Wenn der Nameserver die Antwort nicht in seiner Resolver-Bibliothek findet, wird er andere Nameserver, die sogenannten ''Root-Nameserver'' verwenden, um festzulegen, welche Nameserver für diesen FQDN autorisiert sind.  
* Mit dieser Information wird anschließend bei den autorisierten Nameservern dieser Name abgefragt, um die IP-Adresse festzustellen.  
* Bei einem Reverse-Lookup wird die gleiche Prozedur durchgeführt, allerdings mit dem Unterschied, dass hier eine unbekannte IP-Adresse und nicht ein Name abgefragt wird.


==== Nameserver Zonen ====
=== Nameserver Zonen ===
Im Internet kann ein FQDN eines Hosts in verschiedene Bereiche eingeteilt werden. Diese Bereiche werden in einer Hierarchie (ähnlich einem Baum) mit Hauptstamm, primären Abzweigungen, sekundären Abzweigungen usw. angeordnet. Betrachten Sie den folgenden FQDN:
; Im Internet kann ein FQDN eines Hosts in verschiedene Bereiche eingeteilt werden
* Diese Bereiche werden in einer Hierarchie (ähnlich einem Baum) mit Hauptstamm, primären Abzweigungen, sekundären Abzweigungen und weitere angeordnet.  


Betrachten Sie den folgenden FQDN:
  bob.sales.example.com
  bob.sales.example.com


Wenn Sie sehen möchten, wie ein FQDN aufgelöst wurde, um eine IP-Adresse für ein bestimmtes System zu finden, müssen Sie den Namen von rechts nach links lesen. Jede Ebene der Hierarchie ist durch Punkte (<tt>.</tt>) voneinander getrennt. In diesem Beispiel bestimmt <tt>com</tt> die ''Top-Level-Domain'' für diesen FQDN. Der <tt>domain</tt>-Name ist eine Subdomain von <tt>com</tt> mit <tt>sales</tt> als Subdomain von <tt>example</tt>. Ganz links im FQDN befindet sich der Hostname, <tt>bob</tt>, der einen bestimmten Computer identifiziert.
; Wenn Sie sehen möchten, wie ein FQDN aufgelöst wurde, um eine IP-Adresse für ein bestimmtes System zu finden, müssen Sie den Namen von rechts nach links lesen.  
 
* Jede Ebene der Hierarchie ist durch Punkte (<tt>.</tt>) voneinander getrennt.  
Mit Ausnahme des Hostnamens wird jeder Bereich als ''Zone'' bezeichnet, die einen bestimmten ''Namespace'' (Namensbereich) festlegt. Ein Namespace kontrolliert die Bezeichnung der Subdomains auf der linken Seite. In diesem Beispiel sind zwar nur zwei Subdomains angegeben, ein FQDN muss aber mindestens eine und kann viel mehr Subdomains enthalten, je nach der Organisation des Namespace.
* In diesem Beispiel bestimmt <tt>com</tt> die ''Top-Level-Domain'' für diesen FQDN.  
 
* Der <tt>domain</tt>-Name ist eine Subdomain von <tt>com</tt> mit <tt>sales</tt> als Subdomain von <tt>example</tt>.  
Die Zonen werden mit Hilfe von ''Zone-Dateien'' in authorisierten Nameservern festgelegt. Die Zone-Dateien beschreiben den Namenspace der Zone, den für eine bestimmte Domain oder Subdomain zu verwendenden Mail-Server, uvm. Die Zone-Dateien sind auf ''primären Nameservern'' (auch ''Master-Nameserver'' genannt) gespeichert, die für Änderungen an Dateien maßgeblich sind, sowie auf ''sekundären Nameservern ''(auch ''Slave-Nameserver'' genannt), die ihre Zone-Dateien von den primären Nameservern erhalten. Jeder Nameserver kann gleichzeitig für unterschiedliche Zonen sowohl primärer als auch sekundärer Nameserver sein. Zugleich können sie auch für mehrere Zonen maßgeblich sein. Dies hängt alles von der Konfiguration des Nameservers ab.
* Ganz links im FQDN befindet sich der Hostname, <tt>bob</tt>, der einen bestimmten Computer identifiziert.
 
==== Nameserver Arten ====
Primäre Nameserver können auf vier verschiedene Arten konfiguriert sein:
* ''Master'' — Speichert die ursprünglichen und maßgeblichen Zonen für einen bestimmten Namespace, und beantwortet Fragen von anderen Nameservern, die nach Antworten für diesen Namespace suchen.
* ''Slave'' — Beantwortet ebenfalls die Anfragen anderer Nameserver bezüglich des Namespace, für den dieser die Autorität darstellt. Die Slave-Nameserver erhalten ihre Informationen über ein Namespace jedoch von Master-Nameservern.
* ''Caching-Only'' — Bietet Dienste für IP-Auflösungen, hat aber nicht für alle Zonen eine Berechtigung. Antworten für alle Auflösungen werden üblicherweise für eine bestimmte Zeit im Speicher gecachet, welche von dem abgefragten Zone-Record festgelegt wird.
* ''Forwarding'' — Leitet Anfragen zum Auflösen an eine spezielle Liste von Nameservern weiter. Wenn keiner der angegebenen Nameserver den Auflösungsprozess durchführen kann, wird der Vorgang abgebrochen und die Auflösung schlägt fehl.
 
Ein Nameserver kann einem oder mehreren dieser Typen zugehören. Zum Beispiel kann ein Nameserver für einige Zonen der Master und für andere Zonen der Slave sein und für andere ausschließlich Auflösungen weiterleiten.
 
==== BIND als Nameserver ====
BIND führt Namensauflösungsdienste mittles <tt>/usr/sbin/named</tt> Daemon durch. BIND enthält auch eine administrative Utility, <tt>/usr/sbin/rndc</tt> genannt.
 
BIND speichert seine Konfigurationsdateien in den folgenden zwei Orten:
* <tt>/etc/named.conf</tt> — Die Konfigurationsdatei für den <tt>named</tt> Daemon.
* <tt>/var/named/</tt> directory — Das <tt>named</tt> Arbeitsverzeichnis, welches Zone, Statistiken, und Cache-Dateien enthält.
 
=== /etc/named.conf ===
Die Datei <tt>named.conf</tt> ist eine Ansammlung von Direktiven, die in verschachtelte, geschweifte Klammern platzierte <tt>{ }</tt>-Optionen verwenden. Administratoren müssen vorsichtig beim Bearbeiten der Datei <tt>named.conf</tt> sein und jegliche syntaktische Fehler vermeiden, da auch die kleinsten Fehler den Service <tt>named</tt> vom Starten abhalten können.
 
{|| class="wikitable sortable options"
|-
||
| | '''Warnung'''
|-
| | &nbsp;
| | Bearbeiten Sie die Datei <tt>/etc/named.conf</tt> oder andere Dateien aus dem <tt>/var/named/</tt>-Verzeichnis ''nicht'' manuell, wenn Sie mit dem '''Domain Name Service Configuration Tool''' arbeiten. Alle manuell vorgenommenen Änderungen an dieser Dateien werden überschrieben, wenn '''Domain Name Service Configuration Tool''' das nächste Mal verwendet wird.
|-
|}
Eine typische <tt>named.conf</tt>-Datei ist ähnlich wie folgt gegliedert:
 
''<statement-1>'' ["''<statement-1-name>''"] [''<statement-1-class>''] {
    ''<option-1>''<nowiki>;</nowiki>
    ''<option-2>''<nowiki>;</nowiki>
    ''<option-N>''<nowiki>;</nowiki>
};
''<statement-2>'' ["''<statement-2-name>''"] [''<statement-2-class>''] {
    ''<option-1>''<nowiki>;</nowiki>
    ''<option-2>''<nowiki>;</nowiki>
    ''<option-N>''<nowiki>;</nowiki>
};
''<statement-N>'' ["''<statement-N-name>''"] [''<statement-N-class>''] {
    ''<option-1>''<nowiki>;</nowiki>
    ''<option-2>''<nowiki>;</nowiki>
    ''<option-N>''<nowiki>;</nowiki>
};
 
==== Häufig verwendete Typen von Statements ====
Die folgenden Typen von Statements werden häufig in <tt>/etc/named.conf</tt> verwendet:
 
===== acl Statement =====
Das <tt>acl</tt> Statement (Access Control Statement) definiert eine Gruppe von Hosts, welchen Zugriff zum Nameserver erlaubt oder verboten werden kann.
 
Ein <tt>acl</tt> Statement hat folgende Form:
 
acl ''<acl-name>'' {
    ''<match-element>''<nowiki>;</nowiki>
    [''<match-element>''<nowiki>; ...]</nowiki>
};
 
In diesem Statement ersetzen Sie <tt>''<acl-name>''</tt> mit dem Namen der Access-Control-Liste (Liste der Zugriffskontrolle) und ersetzen Sie <tt>''<match-element>''</tt> mit einer List von IP-Adressen, wobei Adressen durch ein Semikolon getrennt werden. Meistens wird eine individuelle IP-Adresse oder IP-Netzwerk-Notation (wie <tt>10.0.1.0/24</tt>) benutzt, um die IP Adresse im <tt>acl</tt> Statement zu identifizieren.
 
Die folgenden Access-Control-Listen sind bereits als Schlüsselwörter definiert, um die Konfiguration zu vereinfachen:
* <tt>any</tt> — Vergleicht jede IP-Adresse.
* <tt>localhost</tt> — Vergleicht jede IP-Adresse, die auf dem lokalen System verwendet wird.
* <tt>localnets</tt> — Vergleicht jede IP-Adresse auf allen Netzwerken, mit denen das lokale System verbunden ist.
* <tt>none</tt> — Vergleicht keine IP-Adressen.
 
Wenn mit anderen Statements (wie dem <tt>options</tt> Statement) verwendet, können <tt>acl</tt> Statements sehr hilfreich dabei sein, BIND Nameserver vor unbefugtem Zugriff zu schützen.
 
Das folgende Beispiel gibt zwei Access-Control-Listen an und benutzt ein <tt>options</tt> Statement, um anzugeben, wie diese vom Nameserver behandelt werden sollen:
 
  acl black-hats {
    10.0.2.0/24;
    192.168.0.0/24;
  };
acl red-hats {
    10.0.1.0/24;
  };
options {
    blackhole { black-hats; };
    allow-query { red-hats; };
    allow-recursion { red-hats; };
  }
 
Dieses Beispiel enthält zwei Access-Control-Listen, <tt>black-hats</tt> und <tt>red-hats</tt>. Hosts in der <tt>black-hats</tt> Liste ist der Zugriff zum Nameserver verboten, während Hosts in der <tt>red-hats</tt> Liste normaler Zugriff gewährt ist.
 
===== include Statement =====
Das <tt>include</tt> Statement erlaubt Dateien in <tt>named.conf</tt> einzuschliessen. Auf diese Weise können empfindliche Konfigurationsdaten (wie <tt>Keys</tt>) in einer separaten Datei mit eingeschränkten Rechten gehalten werden.
 
Ein <tt>include</tt> Statement hat die folgende Form:
include  "''<file-name>''"
 
In diesem Statement, ersetzen Sie <tt>''<file-name>''</tt> mit dem absoluten Pfad zu einer Datei.
 
===== options Statement =====
Das <tt>options</tt> Statement legt Konfigurationsoptionen des globalen Servers fest und setzt Defaults für andere Statements. Es kann verwendet werden, um den Ort des <tt>named</tt> Arbeitsverzeichnisses anzugeben, den Typ der erlaubten Queries, uvm.
 
Das <tt>options</tt> Statement hat die folgende Form:
options {
        ''<option>''<nowiki>;</nowiki>
        [''<option>''<nowiki>; ...] </nowiki>
};
 
In diesem Statement, ersetzen Sie die <tt>''<option>''</tt> Direktiven mit einer gültigen Option.
 
Die folgenden sind häufig benutzte Optionen:
* <tt>allow-query</tt> — Legt fest, welche Hosts diesen Nameserver abfragen dürfen. Standardmäßig sind alle Hosts dazu berechtigt. Mit Hilfe einer Access-Controll-Liste, einer Sammlung von IP-Adressen oder Netzwerken kann festgelegt werden, dass nur bestimmte Hosts den Nameserver abfragen dürfen.
* <tt>allow-recursion</tt> — Ähnelt der Option <tt>allow-query</tt>, mit der Ausnahme, dass sie sich auf rekursive Abfragen bezieht. Standardmäßig können alle Hosts rekursive Abfragen auf dem Nameserver durchführen.
* <tt>blackhole</tt> — Gibt an, welchen Hosts es nicht erlaubt ist Anfragen an den Server zu stellen.
* <tt>directory</tt> — Ändert das <tt>named</tt>-Arbeitsverzeichnis, so dass es sich von dem Default, <tt>/var/named/</tt>, unterscheidet.
* <tt>forward</tt> — Kontrolliert das Verhalten beim Weiterleiten einer <tt>forwarders</tt> Direktive.
 
Die folgenden Optionen werden angenommen:
* <tt>first</tt> — Gibt an, dass Nameserver, die in der <tt>forwarders</tt>-Option festgelegt sind, zuerst nach Informationen abgefragt werden. Sollten anschließend keine Informationen vorhanden sein, versucht <tt>named</tt> die Auflösung selbst durchzuführen.
* <tt>only</tt> — Gibt an, dass <tt>named</tt> nicht versucht, die Auflösung selbst durchzuführen, wenn die <tt>forwarders</tt> Direktive nicht erfolgreich war.
* <tt>forwarders</tt> — Legt eine Liste von Nameservern fest, bei denen Abfragen für Auflösungen weitergeleitet werden.
* <tt>listen-on</tt> — Legt die Netzwerk-Schnittstelle fest, die <tt>named</tt> verwendet, um Anfragen zu prüfen. Standardmäßig werden alle Schnittstellen verwendet. Auf diese Weise, sollte der DNS Server auch der Gateway sein, kann BIND dazu konfiguriert werden nur Anfragen, welche von einem dieser Netzwerke gestellt wurden, zu beantworten. Eine <tt>listen-on</tt> Direktive kann folgendermaßen aussehen:
 
options {
    listen-on { 10.0.1.1; };
};
Auf diese Art und Weise werden nur Anfragen von der Netzwerk-Schnittstelle akzeptiert, die das private Netzwerk (<tt>10.0.1.1</tt>) verwendet.
* <tt>notify</tt> — Wird verwendet, wenn die Zone als Slave <tt>type</tt> festgelegt ist.
 
Die <tt>masters</tt>- Option teilt dem <tt>named</tt> eines Slaves die IP-Adressen mit, von denen maßgebliche Informationen über die Zone angefragt werden:
** <tt>yes</tt> — Informiert Slave-Server.
** <tt>no</tt> — Informiert Slave-Server nicht.
** <tt>explicit</tt> — Informiert Slave-Server nur dann, wenn diese in einer <tt>also-notify</tt> List innerhalb des Zonen Statement angegeben sind.
* <tt>pid-file</tt> — Legt die Lokalität für die Prozess-ID-Datei fest, die von <tt>named</tt> erstellt wurde.
* <tt>root-delegation-only</tt> — Schaltet die Erzwingung von Delegation-Properties in Top-Level-Domänen ein (TLDs) sowie auch Rootzonen mit einer optionellen Exclude-Liste. ''Delegation'' ist der Vorgang des Unterteilens einer einzelnen Zone in mehrere Subzonen. Um eine delegierte Zone zu erstellen, werden sogenannte ''NS records''benutzt. NameServer-Records (Delegation-Records) geben die maßgeblichen (autoritativen) Nameserver für eine bestimmte Zone bekannt. <br/>Das folgende <tt>root-delegation-only</tt>-Beispiel legt eine Exclude-Liste von TLDs fest, deren 'undelegated' Reaktion erwartet und angenommen wird.
 
Options {
    root-delegation-only exclude { "ad"; "ar"; "biz"; "cr"; "cu"; "de"; "dm"; "id;
                                  "lu"; "lv"; "md"; "ms"; "museum"; "name"; "no"; "pa";
                                  "pf"; "se"; "sr"; "to"; "tw"; "us"; "uy"; };
};
* <tt>statistics-file</tt> — Erlaubt das Festlegen eines alternativen Ortes in welcher die Statistik-Dateien abgelegt werden. Standardmäßig werden <tt>named</tt>-Statistiken in <tt>/var/named/named.stats</tt> gespeichert.
 
Es gibt noch zahlreiche andere Optionen, bei denen einige voneinander abhängig sind, um fehlerfrei zu funktionieren. Weitere Informationen hierzu finden Sie im ''BIND 9 Administrator Reference Manual'', in [http://web.mit.edu/rhel-doc/4/RH-DOCS/rhel-rg-de-4/s1-bind-additional-resources.html#S2-BIND-INSTALLED-DOCS Abschnitt 12.7.1], und in den man-Seiten zu <tt>bind.conf</tt>.
 
===== zone Statement =====
Ein <tt>zone</tt> Statement legt die Eigenschaften einer Zone, wie den Ort der Konfigurationsdatei und Zonen-spezifische Optionen fest. Dieses Statement kann dazu benutzt werden, um globale <tt>options</tt> Statements zu überschreiben.
 
Ein <tt>zone</tt> Statement hat die folgende Form:
 
zone ''<zone-name>'' ''<zone-class>'' {
      ''<zone-options>''<nowiki>;</nowiki>
      [''<zone-options>''<nowiki>; ...]</nowiki>
};
 
In diesem Statement <tt>''<zone-name>''</tt> ist der Name der Zone, <tt>''<zone-class>''</tt> ist die optionale Klasse der Zone, und <tt>''<zone-options>''</tt> ist eine List von Optionen, welche die Eigenschaften der Zone bestimmen.
 
Das <tt>''<zone-name>''</tt>-Attribut für das Zonen Statement ist besonders wichtig, da es den Standardwert für die <tt>$ORIGIN</tt>-Anweisung festlegt, welche den Zonen-Dateien im Verzeichnis <tt>/var/named/</tt> entspricht. Der Daemon <tt>named</tt> hängt den Namen der Zone an jeden Nicht-FQDN an, welcher in der Zonen-Datei aufgelistet ist.
 
Wenn, zum Beispiel, ein <tt>zone</tt> Statement den Namespace für <tt>example.com</tt> angibt, verwende <tt>example.com</tt> als <tt>''<zone-name>''</tt>, damit es an Hostnamen in der <tt>example.com</tt> Zonen-Datei angehängt wird.
 
Für mehr Information zu Zonen-Dateien, siehe [http://web.mit.edu/rhel-doc/4/RH-DOCS/rhel-rg-de-4/s1-bind-zone.html Abschnitt 12.3].
 
Die am häufigsten verwendeten Optionen von <tt>zone</tt> Statement sind die Folgenden:
* <tt>allow-query</tt> — Legt fest, welche Clients Informationen über diese Zone anfordern dürfen. Standardmäßig sind alle Anfragen zulässig.
* <tt>allow-transfer</tt> — Bestimmt die Slave-Server, die den Transfer der Informationen über die Zonen anfordern dürfen. Standardmäßig sind alle Transfer-Anfragen zulässig.
* <tt>allow-update</tt> — Bestimmt die Hosts, die Informationen in ihrer Zone dynamisch aktualisieren dürfen. Standardmäßig sind Anfragen für dynamische Updates nicht zulässig. <br/>Wenn Sie zulassen, dass Hosts Informationen über ihre Zonen aktualisieren, sollten Sie unbedingt sicherstellen, dass Sie diese Option nur aktivieren, wenn der Host absolut sicher ist. Es ist besser, die Updates der Zonen-Records manuell von einem Administrator durchführen zu lassen und den <tt>named</tt>-Service, soweit möglich, neu zu laden.
* <tt>file</tt> — Bestimmt den Namen der Datei im <tt>named</tt>-Arbeitsverzeichnis, die die Zone-Konfigurationsdateien enthält. Standardmäßig ist dies <tt>/var/named/</tt>.
* <tt>masters</tt> — Gibt die IP-Adressen an, von denen authoritäre Zoneninformationen erfragt werden können. Wird nur verwendet, wenn die Zone als <tt>type</tt> <tt>slave</tt> spezifiziert ist.
* <tt>notify</tt> — Gibt an, ob <tt>named</tt> den Slave-Servern mitteilt, daß eine Zone geändert wurde. Diese Direktive kennt die folgenden Optionen:
** <tt>yes</tt> — Informiert Slave-Server.
** <tt>no</tt> — Informiert Slave-Server nicht.
** <tt>explicit</tt> — Informiert Slave-Server nur dann, wenn diese in einer <tt>also-notify</tt> List innerhalb des Zonen Statement angegeben sind.
* <tt>type</tt> — Gibt den Typ der Zone an.
 
Folgend ist eine Liste der gültigen Optionen:
*
** <tt>delegation-only</tt> — Erzwingt den Delegation-Status von Infrastruktur-Zonen wie z.B. COM, NET oder ORG. Jegliche Antwort ohne explizite oder implizite Delegation wird als <tt>NXDOMAIN</tt> behandelt. Diese Option ist nur in TLDs oder root-Zone-Dateien anwendbar, die in rekursiven oder Caching Implementationen verwendet werden.
** <tt>forward</tt> — Weist den Nameserver an, alle Anfragen zu Informationen über die Zone an andere Nameserver weiterzuleiten.
** <tt>hint</tt> — Ein spezieller Zonen-Typ, mit dem auf die Root-Nameserver verwiesen wird, die verwendet werden, um Abfragen zu lösen, wenn eine Zone ansonsten unbekannt ist. Sie brauchen neben der Standarddatei <tt>/etc/named.conf</tt> keine zusätzliche Hinweisdatei zu konfigurieren.
** <tt>master</tt> — Bezeichnet den Nameserver, der für diese Zone maßgeblich ist. Wenn die Konfigurationsdateien für diese Zone auf Ihrem System sind, sollte der <tt>master</tt>-Typ eingestellt werden.
** <tt>slave</tt> — Bezeichnet den Nameserver, der für diese Zone der Slave-Server ist und der <tt>named</tt> mitteilt, die Zonen-Konfigurationsdateien für diese Zone von der IP-Adresse des Master-Nameservers abzufragen.
* <tt>zone-statistics</tt> — Weist <tt>named</tt> an, die Statistiken über diese Zone aufzubewahren und diese entweder in der Standard-Datei (<tt>/var/named/named.stats</tt>) oder an einer Stelle abzulegen, die mit der <tt>statistics-file</tt>-Option im <tt>server</tt>-Statement, sofern vorhanden, dafür eingerichtet wurde. Sehen Sie [http://web.mit.edu/rhel-doc/4/RH-DOCS/rhel-rg-de-4/s1-bind-namedconf.html#S2-BIND-NAMEDCONF-STATE-OTHER Abschnitt 12.2.2] für weitere Information über das <tt>server</tt>-Statement.
 
===== Beispiele von zone-Statements =====
Die meisten Änderungen in der <tt>/etc/named.conf</tt>-Datei eines Master- oder Slave-Nameservers betreffen das Hinzufügen, Modifizieren oder Löschen von <tt>zone</tt>-Direktiven. Obwohl diese <tt>zone</tt>-Anweisungen mehrere Optionen enthalten können, werden von den meisten Nameservern nur wenige verwendet. Die folgenden <tt>zone</tt>-Direktiven sind sehr allgemeine Beispiele, die auf Master-Slave-Nameservern verwendet werden können.
 
Nachfolgend finden Sie ein Beispiel für eine <tt>zone</tt>- Anweisung für den primären Nameserver, der <tt>example.com</tt> (<tt>192.168.0.1</tt>) hostet:
 
zone "example.com" IN {
  type master;
  file "example.com.zone";
  allow-update { none; };
};
 
Diese <tt>zone</tt>-Direktive benennt die Zone <tt>example.com</tt>, stellt als Typ <tt>master</tt> ein und weist den <tt>named</tt>-Service an, die Datei <tt>/var/named/example.com.zone</tt> zu lesen und weist <tt>named</tt> an, Aktualisierungen durch andere Hosts nicht zuzulassen.


Eine <tt>zone</tt>-Anweisung eines Slave-Servers für <tt>example.com</tt> unterscheidet sich etwas vom vorherigen Beispiel. Für einen Slave-Server wird der Typ auf <tt>slave</tt> festgelegt. An die Stelle der Zeile <tt>allow-update</tt> tritt eine Anweisung, die <tt>named</tt> die IP-Adresse des Master-Servers mitteilt.
; Mit Ausnahme des Hostnamens wird jeder Bereich als ''Zone'' bezeichnet, die einen bestimmten ''Namespace'' (Namensbereich) festlegt.  
* Ein Namespace kontrolliert die Bezeichnung der Subdomains auf der linken Seite.  
* In diesem Beispiel sind zwar nur zwei Subdomains angegeben, ein FQDN muss aber mindestens eine und kann viel mehr Subdomains enthalten, je nach der Organisation des Namespace.


Nachfolgend finden Sie ein Beispiel für eine <tt>zone</tt>-Anweisung für die <tt>example.com</tt> Zone:
; Die Zonen werden mit Hilfe von ''Zone-Dateien'' in authorisierten Nameservern festgelegt
* Die Zone-Dateien beschreiben den Namenspace der Zone, den für eine bestimmte Domain oder Subdomain zu verwendenden Mail-Server, uvm.
* Die Zone-Dateien sind auf ''primären Nameservern'' (auch ''Master-Nameserver'' genannt) gespeichert, die für Änderungen an Dateien maßgeblich sind, sowie auf ''sekundären Nameservern ''(auch ''Slave-Nameserver'' genannt), die ihre Zone-Dateien von den primären Nameservern erhalten.
* Jeder Nameserver kann gleichzeitig für unterschiedliche Zonen sowohl primärer als auch sekundärer Nameserver sein.
* Zugleich können sie auch für mehrere Zonen maßgeblich sein.
* Dies hängt alles von der Konfiguration des Nameservers ab.


zone "example.com" {
=== Nameserver Arten ===
  type slave;
; Primäre Nameserver können auf vier verschiedene Arten konfiguriert sein
  file "example.com.zone";
{| class="wikitable options big"
  masters { 192.168.0.1; };
};
 
Diese <tt>zone</tt>-Anweisung weist <tt>named</tt> auf dem Slave-Server an, bei dem Master-Server mit der IP <tt>192.168.0.1</tt> nach Informationen für die Zone <tt>example.com</tt> zu suchen. Die Informationen, die der Slave-Server vom Master-Server erhält, werden in der Datei <tt>/var/named/example.com.zone</tt> gespeichert.
 
==== Andere Statement-Typen ====
Die Folgende ist eine Liste von weniger verwendeten Statement-Typen welche in <tt>named.conf</tt> verfügbar sind:
* <tt>controls</tt> — Konfiguriert verschiedene Sicherheitsbedingungen, die für den Befehl <tt>rndc</tt> zum Verwalten des <tt>named</tt>-Services nötig sind. <br/>Unter [http://web.mit.edu/rhel-doc/4/RH-DOCS/rhel-rg-de-4/s1-bind-rndc.html#S2-BIND-RNDC-CONFIGURATION-NAMEDCONF Abschnitt 12.4.1] sehen Sie, wie die <tt>controls</tt>-Anweisung aussehen sollte, einschließlich der verfügbaren Optionen.
* <tt>key "''<key-name>''"</tt> — Legt für einen bestimmten Schlüssel einen Namen fest. Schlüssel werden verwendet, um verschiedene Aktionen zu authentifizieren, wie z.B. sichere Updates oder die Verwendung des <tt>rndc</tt>-Befehls.
 
Mit <tt>key</tt> werden zwei Optionen verwendet:
* <tt>algorithm ''<algorithm-name>''</tt> — Der verwendete Algorithmus-Typ, z.B. <tt>dsa</tt> oder <tt>hmac-md5</tt>.
* <tt>secret "''<key-value>''"</tt> — Der verschlüsselte Schlüssel.
 
Unter [http://web.mit.edu/rhel-doc/4/RH-DOCS/rhel-rg-de-4/s1-bind-rndc.html#S2-BIND-RNDC-CONFIGURATION-RNDCCONF Abschnitt 12.4.2] finden Sie die Anweisungen zum Schreiben eines <tt>key</tt>-Statement.
* <tt>logging</tt> — Erlaubt die Verwendung mehrerer Arten von Protokollen mit der Bezeichnung ''channels''. Wird die Option <tt>channel</tt> in der <tt>logging</tt>-Anweisung verwendet, wird ein benutzerdefiniertes Protokoll mit eigenem Dateinamen (<tt>file</tt>), Größenbeschränkung (<tt>size</tt>), Version (<tt>version</tt>), und dessen Wichtigkeit (<tt>severity</tt>) erstellt. Nachdem ein benutzerdefinierter Channel festgelegt wurde, wird dieser mit der Option <tt>category</tt> klassifiziert und beginnt mit dem Protokollieren, wenn <tt>named</tt> neu gestartet wird. <br/>Standardmäßig protokolliert <tt>named</tt> normale Mitteilungen im <tt>syslog</tt>-Daemon, der diese in <tt>/var/log/messages</tt> platziert. Dies geschieht, weil sich verschiedene standardmäßige Channel mit unterschiedlicher Wichtigkeit im BIND befinden. Zum Beispiel verarbeitet ein Channel die Protokoll-Mitteilungen (<tt>default_syslog</tt>) und ein anderer speziell Debugging-Mitteilungen (<tt>default_debug</tt>). Die standardmäßige Kategorie <tt>default</tt>, verwendet zum normalen Protokollieren, ohne spezielle Konfigurationen, integrierte Channel. <br/>Den Protokollierungsprozess individuell anzupassen kann sehr aufwendig sein und übersteigt den Umfang dieses Kapitels. Informationen über die Erstellung von benutzerdefinierten BIND-Protokollen finden Sie im ''BIND 9 Administrator Reference Manual'' in [http://web.mit.edu/rhel-doc/4/RH-DOCS/rhel-rg-de-4/s1-bind-additional-resources.html#S2-BIND-INSTALLED-DOCS Abschnitt 12.7.1].
* <tt>server</tt> — Definiert bestimmte Optionen, die Auswirkungen darauf haben, wie <tt>named</tt> sich gegenüber Remote-Name-Servern verhalten soll, insbesondere im Hinblick auf Benachrichtigungen und Zone-Übertragungen. <br/>Die Option <tt>transfer-format</tt> kontrolliert, ob mit jeder Mitteilung ein Resource-Record (<tt>one-answer</tt>) oder mehrere Ressource-Records mit jeder Meldung gesendet werden (<tt>many-answers</tt>). Da <tt>many-answers</tt> leistungsfähiger ist, wird es nur von neueren Name-Servern angenommen.
* <tt>trusted-keys</tt> — Enthält verschiedene öffentliche Schlüssel für die Verwendung mit Secure DNS (DNSSEC). Unter [http://web.mit.edu/rhel-doc/4/RH-DOCS/rhel-rg-de-4/s1-bind-features.html#S2-BIND-FEATURES-SECURITY Abschnitt 12.5.3] finden Sie eine Einführung in die BIND-Sicherheit.
* <tt>view "''<view-name>''"</tt> — Erstellt spezielle Ansichten, die bestimmten Informationen entsprechen, die von dem Host abhängig sind, der den Name-Server kontaktiert. Dadurch erhalten einige Hosts Informationen, die sich vollkommen von denen unterscheiden, die andere Hosts erhalten. Eine andere Möglichkeit ist, nur bestimmte Zonen für bestimmte sichere Hosts zugänglich zu machen, während nicht sichere Hosts nur Abfragen für andere Zonen erstellen können. <br/>Es können auch mehrere Ansichten verwendet werden, solange ihre Namen eindeutig sind. Die <tt>match-clients</tt>-Option legt die IP-Adressen fest, die für eine bestimmte Ansicht verwendet werden. Alle <tt>option</tt>-Direktiven können in einer Ansicht verwendet werden. Sie überschreiben dabei die allgemeinen, bereits für <tt>named</tt> konfigurierten Optionen. Die meisten <tt>view</tt>-Direktiven enthalten mehrere <tt>zone</tt>-Anweisungen, die für die <tt>match-clients</tt>-Liste gelten. Es ist wichtig, in welcher Reihenfolge die <tt>view</tt>-Anweisungen aufgelistet sind, da die erste <tt>view</tt>-Direktive, die mit einer bestimmten IP-Adresse des Client übereinstimmt, verwendet wird. <br/>Unter [http://web.mit.edu/rhel-doc/4/RH-DOCS/rhel-rg-de-4/s1-bind-features.html#S2-BIND-FEATURES-VIEWS Abschnitt 12.5.2] finden Sie weitere Informationen zum <tt>view</tt>-Statement.
 
==== Kommentar-Tags ====
Die Folgende ist eine Liste gültiger, in <tt>named.conf</tt> verwendeter, Kommentar-Tags:
* <tt>//</tt> — Wenn an den Anfang der Zeile gestellt, wird diese Zeile von <tt>named</tt> ignoriert.
* <tt><nowiki>#</nowiki></tt> — Wenn an den Anfang der Zeile gestellt, wird diese Zeile von <tt>named</tt> ignoriert.
* <tt>/*</tt> und <tt><nowiki>*/</nowiki></tt> — Hierin eingeschlossener Text wird von <tt>named</tt> ignoriert.
 
=== Zone-Dateien ===
''Zone-Dateien'' sind im <tt>named</tt>-Arbeitsverzeichnis, <tt>/var/named/</tt>, gespeichert und enthalten Informationen über einen bestimmten Namespace. Jede Zone-Datei ist gemäß der Daten der <tt>file</tt>-Option in der <tt>zone</tt>-Direktive benannt. Normalerweise bezieht sich der Name auf die entsprechende Domain und identifiziert die Datei als Datei, die Zone-Daten enthält, wie z.B. <tt>example.com.zone</tt>.
 
Jede Zone-Datei kann Direktiven und Resource-Records enthalten. ''Direktiven'' weisen den Name-Server an, bestimmte Aktionen auszuführen oder spezielle Einstellungen für die Zone zu verwenden. ''Resource-Records'' legen die Parameter der Zone fest. Diese ordnen bestimmten Systemen innerhalb des Namespaces der Zone eine Identität zu. Anweisungen sind optional, aber Resource-Records sind notwendig, um dieser Zone den Name-Service zur Verfügung zu stellen.
 
Alle Anweisungen und Resource-Records sollten in einer eigenen Zeile stehen.
 
Kommentare können in Zone-Dateien nach dem Semikolon (<tt><nowiki>;</nowiki></tt>) platziert werden.
 
==== Zone-Dateien-Direktiven ====
Anweisungen werden durch das vorangestellte Dollarzeichen <tt>$</tt> identifiziert, das vor dem Namen der Anweisung üblicherweise im oberen Teil der Zone-Datei steht.
 
Folgende Anweisungen werden am häufigsten verwendet:
* <tt>$INCLUDE</tt> — Weist <tt>named</tt> an, in diese Zone-Datei an Stelle der Anweisung eine andere Zone-Datei einzufügen. Dadurch können zusätzliche Einstellungen der Zone getrennt von der Haupt-Zone-Datei gespeichert werden.
* <tt>$ORIGIN</tt> — Stellt den Domain-Name so ein, dass er an alle ungeeigneten Records angefügt wird. Wie z.B. die, die ausschließlich den Host festlegen.
 
Eine Zone-Datei könnte z.B. folgende Zeile enthalten:
$ORIGIN example.com.An alle Namen, die in Resource-Records verwendet werden und nicht mit einem Punkt (<tt>.</tt>) enden, wird <tt>example.com</tt> angehängt.
 
{|| class="wikitable sortable options"
|-
|-
||
! Option !! Beschreibung
| | '''Anmerkung'''
|-
|-
| | &nbsp;
| Master || Speichert die ursprünglichen und maßgeblichen Zonen für einen bestimmten Namespace, und beantwortet Fragen von anderen Nameservern, die nach Antworten für diesen Namespace suchen.
| | Die Verwendung der <tt>$ORIGIN</tt>-Direktive ist nicht erforderlich, wenn der Name der Zone in <tt>/etc/named.conf</tt> mit dem Wert übereinstimmt, den Sie <tt>$ORIGIN</tt> zuweisen würden. Standardmäßig wird der Name der Zone als Wert der <tt>$ORIGIN</tt>-Anweisung verwendet.
|-
|-
|}
| Slave || Beantwortet ebenfalls die Anfragen anderer Nameserver bezüglich des Namespace, für den dieser die Autorität darstellt.  
 
* Die Slave-Nameserver erhalten ihre Informationen über ein Namespace jedoch von Master-Nameservern.
* <tt>$TTL</tt> — Legt den Standard-''Time to Live (TTL)''-Wert für die Zone fest. Dieser Wert legt für die Name-Server in Sekunden fest, wie lange das Resource-Record für die Zone gültig ist. Ein Resource- Record kann einen eigenen TTL-Wert besitzen, der den Wert dieser Anweisung für die Zone überschreibt.
 
Wird dieser Wert erhöht, können die Remote-Name-Server die Zone-Informationen länger verarbeiten. Dadurch werden zwar die Abfragen für diese Zone reduziert, es vergrößert sich jedoch der Zeitraum, bis man von den Änderungen der Resource-Records profitieren kann.
 
==== Resource-Records der Zone-Datei ====
Die Hauptkomponente einer Zone-Datei sind deren Resource-Records.
 
Es gibt viele Typen von Resource-Records. Folgende werden am häufigsten verwendet:
* <tt>A</tt> — Adressen-Record, das einem Namen eine IP-Adresse zuweist. Beispiel:
 
''<host>''    IN    A    ''<IP-address>''Wenn der <tt>''<host>''</tt>-Wert nicht angegeben wird, verweist ein <tt>A</tt>-Record auf eine standardmäßige IP-Adresse für den oberen Teil des Namespaces. Dieses System gilt für alle nicht-FQDN-Anfragen.
 
Beachten Sie das folgende <tt>A</tt>-Record-Beispiel für die <tt>example.com</tt> Zone-Datei:
              IN    A      10.0.1.3
server1      IN    A      10.0.1.5Anfragen für <tt>example.com</tt> richten sich an 10.0.1.3, während Anfragen für <tt>server1.example.com</tt> sich an 10.0.1.5 richten. * <tt>CNAME</tt> — Name-Record, welcher Namen untereinander zuordnet. Dieser Typ ist auch als Alias bekannt.
 
Im nächsten Beispiel wird <tt>named</tt> angewiesen, dass alle Anfragen, die an den <tt>''<alias-name>''</tt> gesendet werden, auf den Host <tt>''<real-name>''</tt> zeigen. <tt>CNAME</tt>-Records werden am häufigsten verwendet, um auf Dienste zu verweisen, die ein allgemeines Namensschema für den korrekten Host, wie <tt>www</tt> für Web-Server, verwenden. server1      IN    A      10.0.1.5
www          IN    CNAME  server1* <tt>MX</tt> — Mail eXchange- Record, das angibt, welchen Weg eine Mail nimmt, die an ein bestimmtes Namespace gesendet und von dieser Zone kontrolliert wurde.
 
      IN    MX    ''<preference-value>''  ''<email-server-name>''In diesem Beispiel ermöglicht <tt>''<preference-value>''</tt>, die E-Mail-Server der Reihenfolge nach zu nummerieren, auf denen Sie für dieses Namespace bestimmte E-Mails empfangen möchten, indem Sie einigen E-Mail-Systemen den Vorrang vor anderen geben. Der <tt>MX</tt>-Resource-Record mit dem niedrigsten <tt>''<preference-value>''</tt> wird den anderen vorgezogen. Sie können mehreren E-Mail-Servern denselben Wert zuweisen, um den E-Mail-Verkehr zwischen den Servern zu verteilen.
 
Der <tt>''<email-server-name>''</tt> kann ein Hostname oder ein FQDN sein.      IN    MX    10    mail.example.com.
      IN    MX    20    mail2.example.com.In diesem Beispiel wird der erste <tt>mail.example.com</tt>-E-Mail-Server vor dem <tt>mail2.example.com</tt>-E-Mail-Server bevorzugt, wenn eine E-Mail für die Domain <tt>example.com</tt> ankommt. * <tt>NS</tt> — Name-Server-Record, der die maßgeblichen Name-Server für eine bestimmte Zone anzeigt.
 
Beispiel für einen <tt>NS</tt>-Record:
      IN    NS    ''<nameserver-name>''Der <tt>''<nameserver-name>''</tt> sollte ein FQDN sein.
 
Anschließend werden zwei Nameserver als maßgeblich für die Domain aufgelistet. Es ist nicht so wichtig, ob diese Namenserver Slave- oder Master-Nameserver sind, da beide bereits maßgebend sind.      IN    NS    dns1.example.com.
      IN    NS    dns2.example.com.* <tt>PTR</tt> — PoinTeR-Record verweist auf einen anderen Teil des Namespace.
 
<tt>PTR</tt>-Records werden primär für eine umgekehrte Namensauflösung verwendet, da diese IP-Adressen zu einem bestimmten Namen verweisen. Unter [http://web.mit.edu/rhel-doc/4/RH-DOCS/rhel-rg-de-4/s1-bind-zone.html#S2-BIND-CONFIGURATION-ZONE-REVERSE Abschnitt 12.3.4] finden Sie weitere Beispiele von <tt>PTR</tt>-Records in Verwendung. * <tt>SOA</tt> — Start Of Authority-Record, gibt wichtige maßgebliche Informationen über den Namespace an den Name-Server.
 
Nach den Direktiven festgelegt ist ein <tt>SOA</tt>-Resource-Record, der erste Resource-Record in einer Zone-Datei.
 
Das folgende Beispiel zeigt die Basisstruktur eines <tt>SOA</tt>-Resource-Record:
@    IN    SOA    ''<primary-name-server>''    ''<hostmaster-email>'' (
                    ''<serial-number>''
                    ''<time-to-refresh>''
                    ''<time-to-retry>''
                    ''<time-to-expire>''
                    ''<minimum-TTL> )''
 
Das <tt>@</tt>-Symbol richtet die <tt>$ORIGIN</tt>-Anweisung (oder den Namen der Zone, falls die <tt>$ORIGIN</tt>-Direktive nicht eingestellt ist) als Namespace ein, das von diesem <tt>SOA</tt>-Resource-Record eingestellt wurde. Als <tt>''<primary-Nameserver>''</tt> wird der erste, für diese Domain maßgebliche Name-Server verwendet und die E-Mail der über diesen Namespace zu kontaktierenden Person wird durch die <tt>''<hostmaster-email>''</tt> ersetzt.
 
Die <tt>''<serial-number>''</tt> wird bei jeder Änderung der Zone-Datei erhöht, so dass <tt>named</tt> erkennt, dass diese Zone neu geladen werden kann. Die <tt>''<time-to-refresh>''</tt> teilt den Slave-Servern mit, wie lange sie warten müssen, bevor sie beim Master-Nameserver anfragen, ob alle Änderungen für die Zone durchgeführt wurden. Der Wert der <tt>''<serial-number>''</tt> wird vom Slave-Server verwendet, um festzustellen, ob veraltete Daten der Zone verwendet werden, die aktualisiert werden sollten.
 
Die <tt>''<time-to-retry>''</tt> gibt den Zeitraum an, nach dem eine neue Anfrage bezüglich der Aktualisierung durchgeführt werden soll, wenn der Master-Nameserver auf die letzte Anfrage nicht reagiert hat. Wenn der Master-Nameserver nicht geantwortet hat, bevor die <tt>''<time-to-expire>''</tt> abläuft, reagiert der Slave-Nameserver nicht mehr auf Anfragen bezüglich des Namespaces.
 
<tt>''<minimum-TTL>''</tt> ist die Zeit, die anderen Nameservern zum Verarbeiten der Zonen-Informationen mindestens zur Verfügung steht.
 
In BIND werden alle Zeiten in Sekunden angegeben. Sie können jedoch auch Abkürzungen für andere Zeiteinheiten verwenden, wie z.B. Minuten (<tt>M</tt>), Stunden (<tt>H</tt>), Tage (<tt>D</tt>) und Wochen (<tt>W</tt>). In der Tabelle unter [http://web.mit.edu/rhel-doc/4/RH-DOCS/rhel-rg-de-4/s1-bind-zone.html#TB-BIND-SECONDS Tabelle 12-1] finden Sie Zeiträume in Sekunden und die entsprechende Zeit in anderen Formaten.
 
{|| class="wikitable sortable options"
|-
! | Sekunden
! | Andere Zeiteinheiten
|-
| | <tt>60</tt>
| | <tt>1M</tt>
|-
| | <tt>1800</tt>
| | <tt>30M</tt>
|-
| | <tt>3600</tt>
| | <tt>1H</tt>
|-
| | <tt>10800</tt>
| | <tt>3H</tt>
|-
| | <tt>21600</tt>
| | <tt>6H</tt>
|-
| | <tt>43200</tt>
| | <tt>12H</tt>
|-
| | <tt>86400</tt>
| | <tt>1D</tt>
|-
| | <tt>259200</tt>
| | <tt>3D</tt>
|-
| | <tt>604800</tt>
| | <tt>1W</tt>
|-
|-
| | <tt>31536000</tt>
| Caching-Only || Bietet Dienste für IP-Auflösungen, hat aber nicht für alle Zonen eine Berechtigung.
| | <tt>365D</tt>
* Antworten für alle Auflösungen werden üblicherweise für eine bestimmte Zeit im Speicher gecachet, welche von dem abgefragten Zone-Record festgelegt wird.
|-
|-
| Forwarding || Leitet Anfragen zum Auflösen an eine spezielle Liste von Nameservern weiter.
* Wenn keiner der angegebenen Nameserver den Auflösungsprozess durchführen kann, wird der Vorgang abgebrochen und die Auflösung schlägt fehl.
|}
|}


; Sekunden im Vergleich zu anderen Zeiteinheiten
; Ein Nameserver kann einem oder mehreren dieser Typen zugehören
Zum Beispiel kann ein Nameserver für einige Zonen der Master und für andere Zonen der Slave sein und für andere ausschließlich Auflösungen weiterleiten.


Das folgende Beispiel zeigt Ihnen, wie ein <tt>SOA</tt>-Resource-Record aussehen könnte, wenn es mit echten Werten konfiguriert ist.           
=== BIND als Nameserver ===
@    IN    SOA    dns1.example.com.    hostmaster.example.com. (
BIND führt Namensauflösungsdienste mittles <tt>/usr/sbin/named</tt> Daemon durch
                    2001062501 ; serial
; BIND enthält auch eine administrative Utility
                    21600      <nowiki>; refresh after 6 hours</nowiki>
/usr/sbin/rndc
                    3600      <nowiki>; retry after 1 hour</nowiki>
                    604800    <nowiki>; expire after 1 week</nowiki>
                    86400 )    <nowiki>; minimum TTL of 1 day</nowiki>


==== Beispiele für Zone-Dateien ====
; BIND speichert seine Konfigurationsdateien in den folgenden zwei Orten
Einzeln betrachtet könnten die Anweisungen und Resource-Records schwer zu verstehen sein. Sind beide in einer gemeinsamen Datei plaziert, wird es einfacher.
* <tt>/etc/named.conf</tt> — Die Konfigurationsdatei für den <tt>named</tt> Daemon.
 
* <tt>/var/named/</tt> directory — Das <tt>named</tt> Arbeitsverzeichnis, welches Zone, Statistiken, und Cache-Dateien enthält.
Im nächsten Beispiel ist eine sehr einfache Zone-Datei abgebildet.
 
$ORIGIN example.com.
$TTL 86400
@    IN    SOA    dns1.example.com.    hostmaster.example.com. (
  2001062501 ; serial
  21600      <nowiki>; refresh after 6 hours</nowiki>
  3600      <nowiki>; retry after 1 hour</nowiki>
  604800    <nowiki>; expire after 1 week</nowiki>
  86 400 )    <nowiki>; minimum TTL of 1 day</nowiki>
 
  IN    NS    dns1.example.com.
  IN    NS    dns2.example.com.
      IN    MX    10    mail.example.com.
      IN    MX    20    mail2.example.com.
              IN    A      10.0.1.5
server1      IN    A      10.0.1.5
server2      IN    A      10.0.1.7
dns1        IN    A      10.0.1.2
dns2        IN    A      10.0.1.3
ftp          IN    CNAME  server1
mail        IN    CNAME  server1
mail2        IN    CNAME  server2
www          IN    CNAME  server2
 
In diesem Beispiel werden Standard-Anweisungen und <tt>SOA</tt>-Werte verwendet. Die maßgeblichen Name-Server sind dabei als <tt>dns1.example.com</tt> und <tt>dns2.example.com</tt> eingestellt, die über <tt>A</tt>-Records verfügen, wodurch sie mit <tt>10.0.1.2</tt> bzw. <tt>10.0.1.3</tt> verbunden sind.
 
Die mit <tt>MX</tt>-Records konfigurierten E-Mail-Server verweisen auf <tt>server1</tt> und <tt>server2</tt> über <tt>CNAME</tt>- Records. Da die <tt>server1</tt>- und <tt>server2</tt>-Namen nicht mit einem Punkt enden (<tt>.</tt>), wird die <tt>$ORIGIN</tt>-Domain nach ihnen abgelegt, wobei sie zu <tt>server1.domain.com</tt> und <tt>server2.domain.com</tt> erweitert werden. Mit den dazugehörigen <tt>A</tt>-Resource-Records können dann ihre IP-Adressen bestimmt werden.
 
Die beliebten FTP- und Web-Dienste, die unter den standardmäßigen Namen <tt>ftp.domain.com</tt> und <tt>www.domain.com</tt> zur Verfügung stehen, verweisen auf Rechner, die entsprechende Dienste für die Namen bieten, die <tt>CNAME</tt>-Records verwenden.
 
==== Zone-Dateien für die umgekehrte Auflösung von Namen ====
Eine Zone-Datei für die Auflösung von Reverse-Namen wird verwendet, um eine IP-Adresse in ein bestimmtes Namespace in einem FQDN umzusetzen. Sie ähnelt einer standardmäßigen Zone-Datei, mit dem Unterschied, dass die <tt>PTR</tt>-Resource-Records zur Verknüpfung der IP-Adressen mit gültigen Domain-Namen verwendet werden.
 
Ein <tt>PTR</tt>-Record sieht Folgendem ähnlich:
 
''<last-IP-digit>''      IN    PTR    ''<FQDN-of-system>''
 
Die <tt>''<last-IP-digit>''</tt>ist die letzte Nummer in einer IP-Adresse, mit der auf die FQDN eines bestimmtenSystems hingewiesen wird.
 
Im folgenden Beispiel werden die IP-Adressen <tt>10.0.1.20</tt> durch <tt>10.0.1.25</tt> den korrespondierenden FQDN zugewiesen.
 
$ORIGIN 1.0.10.in-addr.arpa.
$TTL 86400
@    IN    SOA    dns1.example.com.    hostmaster.example.com. (
                    2001062501 ; serial
                    21600      <nowiki>; refresh after 6 hours</nowiki>
                    3600      <nowiki>; retry after 1 hour</nowiki>
                    604800    <nowiki>; expire after 1 week</nowiki>
                    86400 )    <nowiki>; minimum TTL of 1 day</nowiki>
      IN    NS    dns1.example.com.
      IN    NS    dns2.example.com.
20    IN    PTR    alice.example.com.
21    IN    PTR    betty.example.com.
22    IN    PTR    charlie.example.com.
23    IN    PTR    doug.example.com.
24    IN    PTR    ernest.example.com.
25    IN    PTR    fanny.example.com.
 
Diese Zone-Datei würde mit einer <tt>zone</tt>-Anweisung in der <tt>named.conf</tt>-Datei in den Dienst übernommen, was dann so ähnlich aussieht wie:
 
zone "1.0.10.in-addr.arpa" IN {
  type master;
  file "example.com.rr.zone";
  allow-update { none; };
};
 
Es gibt nur einen kleinen Unterschied zwischen diesem Beispiel und einer standardmäßigen <tt>zone</tt>-Direktive: der Name wird anders angegeben. Bitte beachten Sie, dass bei einer Zone für eine umgekehrte Auflösung die ersten drei Blöcke der IP-Adresse zum Umkehren benötigt werden und <tt>.in-addr.arpa</tt> danach angegeben ist. Dadurch kann ein einzelner Block von IP-Ziffern, der in der Zone-Datei zum umgekehrten Auflösen von Namen verwendet wird, richtig an diese Zone angefügt werden.
 
=== Die Verwendung von rndc ===
BIND enthält das Utility <tt>rndc</tt>, mit dem Sie den <tt>named</tt>-Daemon über die Befehlszeile vom lokalen und von einem Remote Host verwalten können.
 
Um zu verhindern, dass nicht authorisierte Benutzer Zugriff zum <tt>named</tt>-Daemon erlangen, verwendet BIND eine Authentifizierungsmethode, auf einem gemeinsamen geheimen Schlüssel basierend, um Hostsystemen den Zugriff zu gewähren. Das heisst, das ein übereinstimmender Schlüssel in <tt>/etc/named.conf</tt> und der <tt>rndc</tt> Konfigurationsdatei <tt>/etc/rndc.conf</tt> existieren muss.
 
==== Konfigurieren von /etc/named.conf ====
Um die Verbindung von <tt>rndc</tt>zu Ihrem <tt>named</tt>-Dienst zu ermöglichen, muss beim Start von <tt>named</tt> die <tt>controls</tt>-Anweisung in Ihrer <tt>/etc/named.conf</tt>-Datei vorhanden sein.
 
Das folgende Beispiel einer <tt>controls</tt>-Anweisung ermöglicht es Ihnen, <tt>rndc</tt>-Befehle vom lokalen Host auszuführen.
 
Controls {
  inet 127.0.0.1 allow { localhost; } keys { ''<key-name>''<nowiki>; };</nowiki>
};
 
Diese Anweisung weist <tt>named</tt> an, am standardmäßigen TCP-Port 953 nach Loopback-Adressen zu suchen und lässt <tt>rndc</tt>-Befehle zu, die vom lokalen Host ausgeführt werden, wenn der richtige Schlüssel angegeben wird. Der <tt>''<key-name>''</tt> bezieht sich auf die <tt>key</tt>-Direktive, die sich auch in der <tt>/etc/named.conf</tt>-Datei befindet. Im nächsten Beispiel wird eine <tt>key</tt>-Anweisung veranschaulicht.
 
key "''<key-name>''" {
  algorithm hmac-md5;
  secret "''<key-value>''";
};
 
In diesem Beispiel benutzt <tt>''<key-value>''</tt> einen HMAC-MD5-Algorithmus. Mit dem nachfolgenden Befehl können Sie Ihre eigenen Schlüssel unter Verwendung eines HMAC-MD5-Algorithmus erstellen:
 
dnssec-keygen -a hmac-md5 -b ''<bit-length>'' -n HOST ''<key-file-name>''
 
Es empfiehlt sich, einen Schlüssel mit einer Größe von mindestens 256 Bit zu erstellen. Der Schlüssel, der im <tt>''<key-value>''</tt>-Bereich gespeichert werden sollte, kann in der Datei <tt>''<key-file-name>''</tt>, welche von diesem Befehl erzeugt wurde, gefunden werden.
 
; Warnung
: Da <tt>/etc/named.conf</tt> von jedem gelesen werden kann, ist es angeraten, das <tt>key</tt>-Statement in eine separate Datei auszulagern, welche nur von root gelesen werden kann und ein <tt>include</tt>-Statement zu verwenden, um diese Datei einzubinden. Zum Beispiel:
include "/etc/rndc.key";
 
==== Konfigurieren von /etc/rndc.conf ====
Die <tt>key</tt>-Anweisung ist die wichtigste in der Datei <tt>/etc/rndc.conf</tt>.
 
key "''<key-name>''" {
  algorithm hmac-md5;
  secret "''<key-value>''";
};
 
<tt>''<key-name>''</tt> und <tt>''<key-value>''</tt> sollten exakt mit den Einstellungen in <tt>/etc/named.conf</tt> übereinstimmen.
 
Um den Schlüsseln, welche in <tt>/etc/named.conf</tt> auf dem Ziel-Server angegeben sind, zu entsprechen, fügen Sie folgende Zeilen zu <tt>/etc/rndc.conf</tt> hinzu.
 
Options {
  default-server  localhost;
  default-key    "''<key-name>''";
};
 
Diese Anweisung setzt den globalen Default-Schlüssel. Die<tt>rndc</tt> Konfigurationsdatei kann allerdings auch verschiedene Schlüssel für verschiedene Server verwenden, wie im folgenden Beispiel gezeigt:
 
server localhost {
  key  "''<key-name>''";
};
 
; Achtung
: Stellen Sie sicher, dass jeweils nur ein root-Benutzer auf die Datei <tt>/etc/rndc.conf</tt> zugreifen kann.
 
Für weitere Informationen zur Datei <tt>/etc/rndc.conf</tt>, siehe die <tt>rndc.conf</tt> man-Seiten.
 
==== Befehlszeilenoptionen ====
Ein <tt>rndc</tt>-Befehl sieht wie folgt aus:
 
rndc ''<options>'' ''<command>'' ''<command-options>''
 
Wenn <tt>rndc</tt> auf einem korrekt konfigurierten lokalen Host ausgeführt wird, stehen Ihnen folgende Befehle zur Verfügung:
* <tt>halt</tt> — Hält den <tt>named</tt>-Service sofort an.
* <tt>querylog</tt> — Protokolliert alle Abfragen, die von Clients auf diesem Name-Server durchgeführt wurden.
* <tt>refresh</tt> — Aktualisiert die Datenbank des Nameservers.
* <tt>reload</tt> — Weist den Name-Server an, die Zone-Dateien neu zu laden, aber alle vorher verarbeiteten Antworten zu behalten. Dadurch können Sie Änderungen in den Zone-Dateien durchführen, ohne dass die gespeicherten Auflösungen von Namen verloren gehen.
* Wenn sich Ihre Änderungen nur auf eine bestimmte Zone auswirken, können Sie lediglich diese Zone neu laden. Geben Sie hierzu nach dem <tt>reload</tt>-Befehl den Namen der Zone ein.
* <tt>stats</tt> — Schreibt die aktuellen <tt>named</tt>-Statistiken in die Datei <tt>/var/named/named.stats</tt>.
* <tt>stop</tt> — Stoppt den Server vorsichtig, und speichert dabei alle dynamischen Updates und die vorhandenen ''Incremental Zone Transfers'' (''IXFR'') Daten, vor dem Beenden.
 
Gelegentlich werden Sie bestimmt auch die Standardeinstellungen in der <tt>/etc/rndc.conf</tt>-Datei übergehen wollen. Hierzu stehen Ihnen folgende Optionen zur Verfügung:
* <tt>-c ''<configuration-file>''</tt> — Gibt einen alternativen Speicherort der Konfigurationsdatei an.
* <tt>-p ''<port-number>''</tt> — Legt für die <tt>rndc</tt>-Verbindung eine andere als die standardmäßige Portnummer 953 fest.
* <tt>-s ''<server>''</tt> — Ermöglicht es Ihnen, einen anderen als den <tt>default-server</tt> in <tt>/etc/rndc.conf</tt> anzugeben.
* <tt>-y ''<key-name>''</tt> — Ermöglicht es Ihnen, einen anderen als den <tt>default-key</tt> in der <tt>/etc/rndc.conf</tt>-Datei einzustellen.
 
Zusätzliche Informationen zu diesen Optionen finden Sie auf der <tt>rndc</tt>-man-Seite
 
=== Erweiterte Funktionen von BIND ===
Die meisten BIND-Implementierungen verwenden für die Dienste zur Auflösung von Namen oder als Autorität für bestimmte Domains oder Sub-Domains nur <tt>named</tt>. Die Version 9 von BIND verfügt jedoch auch über eine Reihe weiterer Features, die - korrekte Konfigurierung und Verwendung vorausgesetzt - einen sichereren und effizienteren DNS-Dienst gewährleisten.
 
; Achtung
: Einige dieser Features, wie z.B. DNSSEC, TSIG und IXFR (welche in den folgenden Abschnitten beschrieben werden), sollten nur in Netzwerkumgebungen mit Nameservern verwendet werden, die diese Features unterstützen. Wenn Ihre Netzwerkumgebung Nicht-BIND- oder ältere BIND-Nameserver enthält, prüfen Sie bitte, ob es dafür verbesserte Features gibt, bevor Sie sie verwenden.
 
Alle hier vorgestellten Features werden im ''BIND 9 Administrator Reference Manual'' detaillierter beschrieben. Unter [http://web.mit.edu/rhel-doc/4/RH-DOCS/rhel-rg-de-4/s1-bind-additional-resources.html#S2-BIND-INSTALLED-DOCS Abschnitt 12.7.1] finden Sie mehr Informationen.
 
==== DNS-Protokoll-Erweiterungen ====
BIND unterstützt Incremental Zone Transfers (IXFR), bei denen Slave-Server nur die aktualisierten Teile einer Zone, die auf einem Master-Name-Server modifiziert wurden, heruntergeladen werden. Der standardmäßige TransferProcess erfordert, dass auch bei der kleinsten Änderung die gesamte Zone an alle Slave-Name-Server übermittelt wird. Für sehr populäre Domains mit sehr großzügigen Zone-Dateien und vielen Slave-Name-Servern macht IXFR den Benachrichtigungs- und Update-Prozess weniger ressourcenintensiv.
 
Beachten Sie bitte, dass IXFR nur zur Verfügung steht, wenn Sie für Änderungen der Master-Zonen-Records ''dynamisch updaten'' verwenden. Wenn Sie Zone-Dateien manuell bearbeiten, um Änderungen durchzuführen, verwenden Sie AXFR. Weitere Informationen über das dynamische Updaten finden Sie im ''BIND 9 Administrator Reference Manual''. Unter [http://web.mit.edu/rhel-doc/4/RH-DOCS/rhel-rg-de-4/s1-bind-additional-resources.html#S2-BIND-INSTALLED-DOCS Abschnitt 12.7.1] finden Sie mehr Informationen.
 
==== Mehrere Ansichten ====
Durch Verwendung der <tt>view</tt>-Anweisung in <tt>named.conf</tt>, kann BIND verschiedene Informationen bereitstellen, abhängig von welchem Netzwerk eine Anforderung gestellt wurde.
 
Dies ist vor allem dann nützlich, wenn Sie nicht möchten, dass externe Clients einen bestimmten DNS-Dienst ausführen oder bestimmte Informationen sehen können, während Sie dies auf dem lokalen Netzwerk internen Clients ermöglichen.
 
Die <tt>view</tt>-Anweisung verwendet die <tt>match-clients</tt>-Option, um IP-Adressen oder ganze Netzwerke zu vergleichen und diesen spezielle Optionen und Zone-Daten zu geben.
 
==== Sicherheit ====
BIND unterstützt eine Reihe verschiedener Methoden, um das Updaten von Zonen auf Master- oder Slave-Nameservern zu schützen:
* ''DNSSEC'' — Abkürzung für ''DNS SECurity''. Dieses Feature ist für Zonen, die mit einem ''Zonenschlüssel'' kryptographisch signiert werden, bestimmt. <br/>Auf diese Weise kann sichergestellt werden, dass die Informationen über eine spezielle Zone von einem Nameserver stammen, der mit einem bestimmten privaten Schlüssel signiert wurde, und der Empfänger über den öffentlichen Schlüssel dieses Nameservers verfügt. <br/>Version 9 von BIND unterstützt auch die SIG(0) öffentlicher/privater Schlüssel Methode für die Authentifizierung von Nachrichten.
* ''TSIG'' — Abkürzung für ''Transaction SIGnatures''. Dieses Feature erlaubt die Übertragung von Master zu Slave nur dann, wenn ein gemeinsam verwendeter geheimer Schlüssel auf beiden Name-Servern existiert. <br/>Dieses Feature unterstützt die auf der IP-Adresse basierende Methode der Transfer-Authorisierung. Somit muss ein unerwünschter Benutzer nicht nur Zugriff auf die IP-Adresse haben, um die Zone zu übertragen, sondern auch den geheimen Schlüssel kennen. <br/>Version 9 von BIND unterstützt auch ''TKEY'', eine weitere Methode der Autorisierung von Zone-Übertragungen auf der Basis eines gemeinsam verwendeten geheimen Schlüssels.
 
==== IP-Version 6 ====
Die Version 9 von BIND kann mit den <tt>A6</tt> Zone-Records Name-Service für die IP-Version 6 (IPv6)-Umgebungen zur Verfügung stellen.
 
Wenn Ihre Netzwerkumgebung sowohl über Ipv4- als auch IPv6-Hosts verfügt, können Sie den <tt>lwresd</tt> Lightweight-Resolver-Daemon in Ihren Netzwerk-Clients verwenden. Dieser Daemon ist ein sehr effektiver Caching-Only-Name-Server, der die neuesten <tt>A6</tt>- und <tt>DNAME</tt>-Records versteht, die mit Ipv6 verwendet werden. Auf der <tt>lwresd</tt>-man-Seite finden Sie weitere Informationen hierzu.
 
=== Allgemein zu vermeidende Fehler ===
Es kommt häufig vor, dass Anfänger bei der Bearbeitung der Konfigurationsdateien von BIND Fehler machen oder bei der Verwendung von <tt>named</tt> zunächst Schwierigkeiten haben. Viele der nachfolgend beschriebenen Probleme können Sie aber vermeiden, wenn Sie Folgendes beachten:
* ''Erhöhen Sie die Seriennummer, wenn Sie eine Zone-Datei bearbeiten.'' <br/>Wenn die Seriennummer nicht erhöht wird, hat Ihr Master-Name-Server zwar die korrekten neuen Informationen, Ihr Slave-Name-Server werden jedoch nie über diese Änderungen oder den Versuch informiert, die Daten in der Zone zu aktualisieren.
* ''Achten Sie darauf, dass Sie geschweifte Klammern und Strichpunkte in der <tt>/etc/named.conf</tt>-Datei richtig verwenden.'' <br/>Ein ausgelassenes Semikolon oder eine nicht geschlossene geschweifte Klammer kann dazu führen, dass <tt>named</tt> nicht startet.
* ''Denken Sie daran, in den Zone-Dateien nach jedem FQDN Punkte (<tt>.</tt>) zu setzen und sie beim Hostnamen wegzulassen.'' <br/>Der Punkt bedeutet, dass der angegebene Name komplett ist. Wird er weggelassen, platziert <tt>named</tt> den Namen der Zone oder des <tt>$ORIGIN</tt>-Werts hinter den Namen, um ihn zu vervollständigen.
* ''Wenn Ihre Firewall Verbindungen von Ihrem <tt>named</tt> zu anderen Nameservern blockiert, müssen Sie möglicherweise die Konfigurationsdatei bearbeiten.''
* Standardmäßig verwendet die Version 9 von BIND willkürliche Ports oberhalb von 1024, um andere Name-Server abzufragen. Einige Firewalls gehen jedoch von Name-Servern aus, die für die Kommunikation nur den Port 53 verwenden. Um die Verwendung des Port 53 durch <tt>named</tt> zu erzwingen, fügen Sie in <tt>/etc/named.conf</tt> folgende Zeile zur <tt>options</tt>-Direktive hinzu:
 
query-source address * port 53;


== Anhang ==
=== Siehe auch ===
{{Special:PrefixIndex/{{BASEPAGENAME}}/}}
=== Zusätzliche Ressourcen ===
=== Zusätzliche Ressourcen ===
==== Installierte Dokumentation ====
==== Installierte Dokumentation ====
* BIND verfügt über installierte Dokumentationen, die verschiedene Themen behandeln und jeweils in einem eigenen Verzeichnis abgelegt sind:
* BIND verfügt über installierte Dokumentationen, die verschiedene Themen behandeln und jeweils in einem eigenen Verzeichnis abgelegt sind:
** <tt>/usr/share/doc/bind-''<version-number>''/</tt> — Dieses Verzeichnis listet die neuesten Features. Ersetzen Sie dazu <tt>''<version-number>''</tt> mit der auf Ihrem System installierten Version von <tt>bind</tt>.
** <tt>/usr/share/doc/bind-''<version-number>''/</tt> — Dieses Verzeichnis listet die neuesten Features.  
** <tt>/usr/share/doc/bind-''<version-number>''/arm/</tt> — Enthält das ''BIND 9 Administrator Reference Manual'' im HTML- und SGML-Format, welches Details über die für BIND erforderlichen Ressourcen, Informationen zur Konfigurationsweise der verschiedenen Name-Server-Typen, zur Durchführung des Load-Balancing und anderen spezielleren Themen enthält. Die meisten neuen Benutzer werden sich mit dieser Informationsquelle am besten mit BIND vertraut machen können. Ersetzen Sie <tt>''<version-number>''</tt> mit der auf Ihrem System installierten Version von <tt>bind</tt>.
* Ersetzen Sie dazu <tt>''<version-number>''</tt> mit der auf Ihrem System installierten Version von <tt>bind</tt>.
** <tt>/usr/share/doc/bind-''<version-number>''/draft/</tt> — Enthält ausgewählte technische Dokumente, die sich mit dem DNS Service und damit verbundenen Problemen beschäftigen und einige Methoden zur Lösung dieser Probleme vorschlagen. Ersetzen Sie <tt>''<version-number>''</tt> mit der auf Ihrem System installierten Version von <tt>bind</tt>.
** <tt>/usr/share/doc/bind-''<version-number>''/arm/</tt> — Enthält das ''BIND 9 Administrator Reference Manual'' im HTML- und SGML-Format, welches Details über die für BIND erforderlichen Ressourcen, Informationen zur Konfigurationsweise der verschiedenen Name-Server-Typen, zur Durchführung des Load-Balancing und anderen spezielleren Themen enthält.  
** <tt>/usr/share/doc/bind-''<version-number>''/misc/</tt> — Enthält Dokumente über spezielle verbesserte Merkmale. Benutzer der Version 8 von BIND sollten sich das Dokument <tt>migration</tt> anschauen, das sich mit bestimmten Änderungen befasst, die für eine Verwendung der Version 9 von BIND vorzunehmen sind. In der <tt>options</tt>-Datei sind alle in BIND 9 implementierten Optionen aufgelistet, die in <tt>/etc/named.conf</tt> verwendet werden. Ersetzen Sie <tt>''<version-number>''</tt> mit der auf Ihrem System installierten Version von <tt>bind</tt>.
* Die meisten neuen Benutzer werden sich mit dieser Informationsquelle am besten mit BIND vertraut machen können.  
** <tt>/usr/share/doc/bind-''<version-number>''/rfc/</tt> — In diesem Verzeichnis finden Sie jedes RFC-Dokument, das mit BIND zusammenhängt. Ersetzen Sie <tt>''<version-number>''</tt> mit der auf Ihrem System installierten Version von <tt>bind</tt>.
* Ersetzen Sie <tt>''<version-number>''</tt> mit der auf Ihrem System installierten Version von <tt>bind</tt>.
* BIND-relevante man-Seiten — Es gibt einige man-Seiten zu den verschiedenen Applikationen und Konfigurationsdateien die im Bezug zu BIND stehen. Einige der wichtigeren man-Seiten sind wie folgt aufgelistet.
** <tt>/usr/share/doc/bind-''<version-number>''/draft/</tt> — Enthält ausgewählte technische Dokumente, die sich mit dem DNS Service und damit verbundenen Problemen beschäftigen und einige Methoden zur Lösung dieser Probleme vorschlagen.  
* Ersetzen Sie <tt>''<version-number>''</tt> mit der auf Ihrem System installierten Version von <tt>bind</tt>.
** <tt>/usr/share/doc/bind-''<version-number>''/misc/</tt> — Enthält Dokumente über spezielle verbesserte Merkmale.  
* Benutzer der Version 8 von BIND sollten sich das Dokument <tt>migration</tt> anschauen, das sich mit bestimmten Änderungen befasst, die für eine Verwendung der Version 9 von BIND vorzunehmen sind.  
* In der <tt>options</tt>-Datei sind alle in BIND 9 implementierten Optionen aufgelistet, die in <tt>/etc/named.conf</tt> verwendet werden.  
* Ersetzen Sie <tt>''<version-number>''</tt> mit der auf Ihrem System installierten Version von <tt>bind</tt>.
** <tt>/usr/share/doc/bind-''<version-number>''/rfc/</tt> — In diesem Verzeichnis finden Sie jedes RFC-Dokument, das mit BIND zusammenhängt.  
* Ersetzen Sie <tt>''<version-number>''</tt> mit der auf Ihrem System installierten Version von <tt>bind</tt>.
* BIND-relevante man-Seiten — Es gibt einige man-Seiten zu den verschiedenen Applikationen und Konfigurationsdateien die im Bezug zu BIND stehen.  
* Einige der wichtigeren man-Seiten sind wie folgt aufgelistet.


===== Administrative Applikationen =====
==== Administrative Applikationen ====
* <tt>man rndc</tt> — Erklärt die verschiedenen Optionen, die bei der Verwendung von <tt>rndc</tt> zur Kontrolle eines BIND Name-Servers zur Verfügung stehen.
* <tt>man rndc</tt> — Erklärt die verschiedenen Optionen, die bei der Verwendung von <tt>rndc</tt> zur Kontrolle eines BIND Name-Servers zur Verfügung stehen.


===== Server-Applikationen =====
==== Server-Applikationen ====
* <tt>man named</tt> — Untersucht ausgewählte Argumente, die zur Steuerung des BIND-Name-Server-Daemon verwendet werden können.
* <tt>man named</tt> — Untersucht ausgewählte Argumente, die zur Steuerung des BIND-Name-Server-Daemon verwendet werden können.
* <tt>man lwresd</tt> — Beschreibt den Lightweight-Resolver-Daemon und dessen verfügbare Optionen.
* <tt>man lwresd</tt> — Beschreibt den Lightweight-Resolver-Daemon und dessen verfügbare Optionen.


===== Konfigurationsdateien =====
==== Konfigurationsdateien ====
* <tt>man named.conf</tt> — Eine vollständige Liste von Optionen, welche in der <tt>named</tt>-Konfigurationsdatei zur Verfügung stehen.
* <tt>man named.conf</tt> — Eine vollständige Liste von Optionen, welche in der <tt>named</tt>-Konfigurationsdatei zur Verfügung stehen.
* <tt>man rndc.conf</tt> — Eine vollständige Liste von Optionen, welche in der <tt>rndc</tt>-Konfigurationsdatei zur Verfügung stehen.
* <tt>man rndc.conf</tt> — Eine vollständige Liste von Optionen, welche in der <tt>rndc</tt>-Konfigurationsdatei zur Verfügung stehen.


==== Hilfreiche Webseiten ====
<noinclude>
* [http://www.isc.org/products/BIND/ http://www.isc.org/products/BIND/] — Die Homepage des BIND-Projekts. Hier finden Sie Informationen aktuellen Releases und können das ''BIND 9 Administrator Reference Manual'' in der PDF-Version herunterladen.
* [http://www.redhat.com/mirrors/LDP/HOWTO/DNS-HOWTO.html http://www.redhat.com/mirrors/LDP/HOWTO/DNS-HOWTO.html] — Befasst sich mit BIND als Caching-Nameserver und der Konfiguration der einzelnen Zone-Dateien sowie der Konfiguration verschiedener Zone-Dateien, die als primärer Name-Server für eine Domain benötigt werden.
 
==== Bücher zum Thema ====
* ''Red Hat Enterprise Linux Handbuch zur System-Administration'' — Das Kapitel ''BIND-Konfiguration'' erklärt wie man mit Hilfe des'''Domain Name Service Configuration Tool''' einen DNS-Server einrichten kann.
* ''DNS and BIND'' von Paul Albitz und Cricket Liu; O'Reilly & Associates — Ein bekanntes Buch, das allgemeine und weiterführende Optionen der Konfiguration von BIND erklärt und Strategien zum Schutz Ihres DNS-Servers vorstellt.
* ''The Concise Guide to DNS and BIND'' von Nicolai Langfeldt; Que — Beschreibt die Verbindungen zwischen mehreren Netzwerkdiensten und BIND mit Schwerpunkt auf aufgabenorientierten technischen Themen.
 
== [https://wiki.debian.org/Bind9 Bind9]  ==
=== Introduction ===
Putting a DNS server on a network allows for the replacement of IP addresses of individual machines by a name. As a result, it's even possible to associate multiple names to the same machine to update the different available services.
 
For example, www.example.com and pop.example.com, could both point to the primary server where the mail server and the business intranet reside, and the domain could be example.com. It's easy to remember that these two services are running on the same machine whose IP address is 192.168.0.1.
 
Now imagine that our network administrator decides for some reason or another to move the mail server to the machine 192.168.0.11. The only thing that has to be changed is the DNS server configuration file. You could always go and modify the host configuration for all the users, but that would be time consuming and inconvenient.
 
=== Network Layout ===
We get internet access through an xxxbox (192.168.1.1), two DNS servers provided by our ISP (80.10.249.2, 80.10.246.129). In fact, these two latter servers will ever be referred to in the configuration because the xxxbox will be in charge of resolving names if the packet destination isn't known. Consequently, I consider the xxxbox like a primary server outside of our domain.
 
The “sid” server (192.168.1.10) is connected to the xxxbox via its primary network card. It's also connected to the LAN (192.168.0.0/24) by its secondary network interface(192.168.0.1). It's on this that we are going to install the primary DNS server for our domain example.com ([http://www.ietf.org/rfc/rfc2606.txt RFC 2606])
 
All the computers on the LAN are automatically assigned a single address by the DHCP service. The DHCP also provides the primary DNS server's address for our domain, and updatees the host names for the zone example.com so they can be associated with an ip address.
 
=== Server Management ===
==== Installation ====
The package bind9 will be used for installation.
 
<nowiki># apt-get install bind9 </nowiki>
 
and then if you want to also install the documentation (very useful):
 
<nowiki># apt-get install bind9-doc</nowiki>
 
==== Configuration ====
After installation, you might want to get familiar with some of the configuration files. They are in the directory /etc/bind/
 
===== TSIG Signature =====
The purpose of this signature is to authenticate transactions with BIND. Thus, the DHCP server cannot update the example.com domain if it loses this key. Copy and paste an existing key
 
<nowiki># cd /etc/bind/</nowiki>
<nowiki># cat rndc.key</nowiki>
key "rndc-key" {
        algorithm hmac-md5;
        secret "QJc08cnP1xkoF4a/eSZZbw==";
};
 
<nowiki># cp rndc.key ns-example-com_rndc-key</nowiki>
 
You can generate a new key with the following options:
* '''algorithm HMAC-MD5''' - identifies 157 (required for a TSIG signature and only algorithm supported by BIND)
* '''length of 512 octets''' (multiple of 64 with a maximum length of 512 for the above algorithm)
* '''name''' : ns-example-com_rndc-key
 
dnssec-keygen -a HMAC-MD5 -b 512 -n USER ns-example-com_rndc-key
Kns-example-com_rndc-key.+157+53334
 
The footprint associated with the key is 53334. We get two files, one with an extension key and the other with a private extension. This substitutes the key in the file ns-example-com_rndc-key with the one in one of these two files.
 
<nowiki># cat Kns-example-com_rndc-key.+157+53334.private</nowiki>
Private-key-format: v1.2
Algorithm: 157 (HMAC_MD5)
Key: LZ5m+L/HAmtc9rs9OU2RGstsg+Ud0TMXOT+C4rK7+YNUo3vNxKx/197o2Z80t6gA34AEaAf3F+hEodV4K+SWvA===
Bits: AAA==
<nowiki># cat ns-example-com_rndc-key</nowiki>
key "ns-example-com_rndc-key" {
        algorithm hmac-md5;
        secret "LZ5m+L/HAmtc9rs9OU2RGstsg+Ud0TMXOT+C4rK7+YNUo3vNxKx/197o2Z80t6gA34AEaAf3F+hEodV4K+SWvA==";
};
 
The file ns-example-com_rndc-key should not be made world readable for security reasons. This should be inserted into the bind configuration by an include because the bind configuration itself is world-readable. Also, it's a good idea to delete the key and private files generated before.
 
===== File /etc/bind/named.conf =====
This file is the main configuration file for the DNS file.
 
// Managing acls
acl internals { 127.0.0.0/8; 192.168.0.0/24; };
 
// Load options
include "/etc/bind/named.conf.options";
 
// TSIG key used for the dynamic update
include "/etc/bind/ns-example-com_rndc-key";
 
// Configure the communication channel for Administrative BIND9 with rndc
// By default, they key is in the rndc.key file and is used by rndc and bind9
// on the localhost
controls {
        inet 127.0.0.1 port 953 allow { 127.0.0.1; };
};
 
// prime the server with knowledge of the root servers
zone "." {
        type hint;
        file "/etc/bind/db.root";
};
 
include "/etc/bind/named.conf.default-zones";
include "/etc/bind/named.conf.local";
 
Note : with Debian Jessie the 'zone "." {...}' part is inside the file "named.conf.default-zones". You don't need to add it in the file "named.conf".
 
===== File /etc/bind/named.conf.default-zones =====
Note: as of Debian 7 "Wheezy" bind9 ships with a file containing default forward, reverse, and broadcast zones.
 
// be authoritative for the localhost forward and reverse zones, and for
// broadcast zones as per RFC 1912
zone "localhost" {
        type master;
        file "/etc/bind/db.local";
};
zone "127.in-addr.arpa" {
        type master;
        file "/etc/bind/db.127";
};
zone "0.in-addr.arpa" {
        type master;
        file "/etc/bind/db.0";
};
zone "255.in-addr.arpa" {
        type master;
        file "/etc/bind/db.255";
};
 
===== File /etc/bind/named.conf.options =====
This file contains all the configuration options for the DNS server
 
options {
        directory "/var/cache/bind";
 
        // Exchange port between DNS servers
        query-source address * port *;
 
        // Transmit requests to 192.168.1.1 if
        // this server doesn't know how to resolve them
        forward only;
        forwarders { 192.168.1.1; };
 
        auth-nxdomain no;    <nowiki># conform to RFC1035</nowiki>
 
        // From 9.9.5 ARM, disables interfaces scanning to prevent unwanted stop listening
        interface-interval 0;
        // Listen on local interfaces only(IPV4)
        listen-on-v6 { none; };
        listen-on { 127.0.0.1; 192.168.0.1; };
 
        // Do not transfer the zone information to the secondary DNS
        allow-transfer { none; };
 
        // Accept requests for internal network only
        allow-query { internals; };
 
        // Allow recursive queries to the local hosts
        allow-recursion { internals; };
 
        // Do not make public version of BIND
        version none;
};
 
The port associated with the '''query-source''' option must not in any case be frozen because it jeopardizes the DNS transactions in the case of a resolver. * [http://www.kb.cert.org/vuls/id/800113 Vulnerability Note VU#800113] http://www.kb.cert.org/vuls/id/800113
* [http://www.trusteer.com/bind9dns Bind9 DNS Cache Poisoning] http://www.trusteer.com/bind9dns
 
M. Rash wrote an interesting article about this and how to force the source port randomly via the iptables: [http://www.cipherdyne.org/blog/2008/07/mitigating-dns-cache-poisoning-attacks-with-iptables.html Mitigating DNS Cache Poisoning Attacks with iptables]
 
To reduce the delay timeout for UDP connections, and thus highlight the randomization, which by default is 30s by tuple, simply update the parameter net.netfilter.nf_conntrack_udp_timeout
 
<nowiki># sysctl -w net.netfilter.nf_conntrack_udp_timeout=10</nowiki>
 
to get timeout of 10s.
 
===== File /etc/bind/named.conf.local =====
This file contains the local DNS server configuration, and this is where you declare the zones associated with this server's domain(s).
 
// Manage the file logs
include "/etc/bind/named.conf.log";
 
// Domain Management example.com
// ------------------------------
//  - The server is defined as the master on the domain.
//  - There are no forwarders for this domain.
//  - Entries in the domain can be added dynamically
//    with the key ns-example-com_rndc-key
zone "example.com" {
        type master;
        file "/var/lib/bind/db.example.com";
        //forwarders {};
        // If we do not comment the ''forwarders'' "empty" clients of the local subnet in my case don't have access to the upstream DNS ?
        //allow-update { key ns-example-com_rndc-key; };
        allow-update { key rndc-key; };
        //confusion between the file name to import (ns-example-com_rndc-key) and the key label (rndc-key) ?
};
zone "0.168.192.in-addr.arpa" {
        type master;
        file "/var/lib/bind/db.example.com.inv";
        //see comment below (zone "example.com")
        //forwarders {};
        //allow-update { key ns-example-com_rndc-key; };
        allow-update { key rndc-key; };
};
 
// Consider adding the 1918 zones here, if they are not used in your
// organization
include "/etc/bind/zones.rfc1918";
 
NOTE: if you create a local non-FQDN and call it .local it clashes with some other packages (which?). Edit /etc/nsswitch.conf and move dns right after the files on the host line makes .local domains work.
 
===== File /etc/bind/named.conf.log =====
With Debian Jessie, you need to create this file in /etc/bind
 
logging {
        channel update_debug {
                file "/var/log/update_debug.log" versions 3 size 100k;
                severity debug;
                print-severity  yes;
                print-time      yes;
        };
        channel security_info {
                file "/var/log/security_info.log" versions 1 size 100k;
                severity info;
                print-severity  yes;
                print-time      yes;
        };
        channel bind_log {
                file "/var/log/bind.log" versions 3 size 1m;
                severity info;
                print-category  yes;
                print-severity  yes;
                print-time      yes;
        };
 
        category default { bind_log; };
        category lame-servers { null; };
        category update { update_debug; };
        category update-security { update_debug; };
        category security { security_info; };
};
 
Here we define different log methods for the different categories. The first category is, as its name indicates the default category that is usually assigned to syslog. All categories not mentioned, are similar to the default category. For a list of the different categories, see [http://www.bind9.net/manual/bind/9.3.2/Bv9ARM the bind9 administrator reference manual]. In terms of blade-servers, it ignores all the logs associated with them. It may be necessary to create /var/log in the chroot later.
 
==== Resource Records (RR) ====
DNS is made up of several registrations, RR or Resource Records, defining the various domain information. The first is dedicated to name resolution, in our case, it is the file db.example.com. The second will be used for reverse name resolution, it is the file db.example.com.inv.
 
===== Files in var/cache/bind/ =====
* RR for name reso (db.example.com file)
 
$TTL    3600
@      IN      SOA    sid.example.com. root.example.com. (
                    2007010401          <nowiki>; Serial</nowiki>
                          3600          <nowiki>; Refresh [1h]</nowiki>
                          600          <nowiki>; Retry </nowiki>  [10m]
                        86400          <nowiki>; Expire </nowiki> [1d]
                          600 )        <nowiki>; Negative Cache TTL [1h]</nowiki>
<nowiki>;</nowiki>
@      IN      NS      sid.example.com.
@      IN      MX      10 sid.example.com.
 
sid    IN      A      192.168.0.1
etch    IN      A      192.168.0.2
 
pop    IN      CNAME  sid
www    IN      CNAME  sid
mail    IN      CNAME  sid* RR for inverse name resol ( db.example.com.inv file)
 
@ IN SOA        sid.example.com. root.example.com. (
                    2007010401          <nowiki>; Serial</nowiki>
                          3600          <nowiki>; Refresh [1h]</nowiki>
                          600          <nowiki>; Retry </nowiki>  [10m]
                        86400          <nowiki>; Expire </nowiki> [1d]
                          600 )        <nowiki>; Negative Cache TTL [1h]</nowiki>
<nowiki>;</nowiki>
@      IN      NS      sid.example.com.
 
1      IN      PTR    sid.example.com.
2      IN      PTR    etch.example.com.
 
===== Some Explanations : =====
$TTL : (Time To Live) expresses the duration (in seconds) validity, by default, of the information contained in the RRs. Once this time expires, it is necessary to recheck the data. Types :
* '''SOA''' : Show romanization
 
to define information about the area. In this case the name of the primary DNS server "sid.example.com." and the email address of technical contact (root.example.com.; the @ is replaced by a dot). It is composed of several fields:
* 1. ''Serial'' : is the whole non-signed 32 bits. This is the serial number to increment with each change of file. It allows the secondary server to reload the information they have. The general purpose is to format it this way YYYYMMDDXX, either for the first amendment 01/04/2007 -> 2007040101, for the second 2007040102.
* 2. ''Refresh'' : defines the data refresh period.
* 3. ''Retry '': if an error occurs during the last refresh, it will be repeated at the end of time Retry.
* 4. Expires'''': the server is considered unavailable after the time expires. '''
* '''5. Negative cache TTL'''': set the lifetime of a NXDOMAIN response from us.
* '''NS''': information on behalf of nameservers for the domain. '''''
* ''''X.''': information on the mail server. Many can be defined. Thus, it is possible to give them a priority, assigning a number. The lower the number, the higher the priority.
* '''A''': associates a host name to an IPv4 address (32 bits) '''''
* ''''YYYY''': associates a host name to an IPv6 address (128 bits)
* '''CNAME''': identifies the canonical name of an alias (a name that points to another name) '''''
* ''''PTR''': This is simply the inverse resolution (the opposite of type A).
 
The classes in the association determines the Internet class. Other classes are available (CH and HS). For more information please consult the [http://www.ietf.org/rfc/rfc1035.txt RFC 1035]
 
==== /etc/resolv.conf File ====
search example.com
 
It's no more complicated than that !
 
=== Chroot ===
The named daemon is started using the bind user by default.
 
This option is found in the bind service config file''' /etc/default/bind9''' (NOTE: this is not valid for jessie who used systemd):
 
OPTIONS="-u bind"
 
The bind start script '''/etc/init.d/bind9''' reads this config file when the service is started.
 
Starting bind as a non root user is good practice but to run the daemon in a chroot environment we also need specify the chroot directory. This is done using the same OPTIONS variable in /etc/default/bind9.
 
To begin, start by stopping the bind service:
 
/etc/init.d/bind9 stop
 
Then edit /etc/default/bind9 (not for jessie):
 
OPTIONS="-u bind -t /var/bind9/chroot"
 
For Jessie, create the file /etc/systemd/system/bind9.service with options "-t /var/bind9/chroot":
 
[Unit]
Description=BIND Domain Name Server
Documentation=man:named(8)
After=network.target
 
[Service]
ExecStart=/usr/sbin/named -f -u bind -t /var/bind9/chroot
ExecReload=/usr/sbin/rndc reload
ExecStop=/usr/sbin/rndc stop
 
[Install]
WantedBy=multi-user.target
 
For Jessie, after creating the above unit file, update the symlink to the unit file with:
 
systemctl reenable bind9
 
Now create the chroot directory structure:
 
mkdir -p /var/bind9/chroot/{etc,dev,var/cache/bind,var/run/named}
 
Create the required device special files and set the correct permissions:
 
mknod /var/bind9/chroot/dev/null c 1 3
mknod /var/bind9/chroot/dev/random c 1 8
chmod 660 /var/bind9/chroot/dev/{null,random}
 
Move the current config directory into the new chroot directory:
 
mv /etc/bind /var/bind9/chroot/etc
 
Now create a symbolic link in /etc for compatibility:
 
ln -s /var/bind9/chroot/etc/bind /etc/bind
 
If you want to use the local timezone in the chroot (e.g. for syslog):
 
cp /etc/localtime /var/bind9/chroot/etc/
 
Change the ownership on the files you've just moved over and the rest of the newly created chroot directory structure:
 
chown bind:bind /var/bind9/chroot/etc/bind/rndc.key
chmod 775 /var/bind9/chroot/var/{cache/bind,run/named}
chgrp bind /var/bind9/chroot/var/{cache/bind,run/named}
 
Edit the PIDFILE variable in /etc/init.d/bind9 to the correct path:
 
PIDFILE=/var/bind9/chroot/var/run/named/named.pid
 
Finally tell rsyslog to listen to the bind logs in the correct place:
 
echo "\$AddUnixListenSocket /var/bind9/chroot/dev/log" > /etc/rsyslog.d/bind-chroot.conf
 
Restart rsyslog and start bind:
 
/etc/init.d/rsyslog restart; /etc/init.d/bind9 start
 
=== Client Manage ===
As I mentioned at the beginning, the assignment of IP addresses on the LAN is performed by the DHCP server. Thus, to set our DNS server to different clients, it is necessary to add the DHCP configuration file the following two lines:
 
option domain-name "example.com"
 
option domain-name-server sid.example.com
 
It must be added to the file (I think) the areas for which DHCP should automatically perform updates.
 
Syntax (everything after "=>" is my comments) :
 
zone [name.of.the.zone.] { * primary 127.0.0.1; => the primary DNS server is on the same machine as the DHCP <br/>key rndc-key; => it's necessary to provide the security key (via an ''include'') in the beginning of the DHCP server configuration file,
** this must be the same key that secures the allow-update for the zone in the ''named.conf.local'' of Bind9.
 
}
 
Examples de [name.of.the.zone.] (with the "." at the end) :
 
- example.com. : for the direct zone of this article,
 
- 0.168.192.in-addr.arpa. : for the inverse zone of this article.
 
For more information on the implementation of dynamic update of DNS records through DHCP is [http://www.dthconnex.com/dhcp_server.html here]
 
=== Testing tools ===
==== Dig Command ====
This can directly search the DNS server of your choice and get a lot of information in addition to name resolution and contrast resolution. '''$ dig nomade-frjo.stones.lan'''
<nowiki>; <<>> DiG 9.4.2 <<>> nomade-frjo.stones.lan</nowiki>
<nowiki>;; global options: </nowiki> printcmd
<nowiki>;; Got answer:</nowiki>
<nowiki>;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15760</nowiki>
<nowiki>;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2</nowiki>
 
<nowiki>;; QUESTION SECTION:</nowiki>
<nowiki>;nomade-frjo.stones.lan. </nowiki>              IN      A
 
<nowiki>;; ANSWER SECTION:</nowiki>
nomade-frjo.stones.lan. 900    IN      A      192.168.0.242
 
<nowiki>;; AUTHORITY SECTION:</nowiki>
stones.lan.            604800  IN      NS      emerald.stones.lan.
stones.lan.            604800  IN      NS      diamond.stones.lan.
 
<nowiki>;; ADDITIONAL SECTION:</nowiki>
diamond.stones.lan.    604800  IN      A      192.168.0.1
emerald.stones.lan.    604800  IN      A      192.168.0.2
 
<nowiki>;; Query time: 20 msec</nowiki>
<nowiki>;; SERVER: 127.0.0.1#53(127.0.0.1)</nowiki>
<nowiki>;; WHEN: Fri Mar 28 20:53:09 2008</nowiki>
<nowiki>;; MSG SIZE </nowiki> rcvd: 131
 
'''$ dig -x 192.168.0.242'''
<nowiki>; <<>> DiG 9.4.2 <<>> -x 192.168.0.242</nowiki>
<nowiki>;; global options: </nowiki> printcmd
<nowiki>;; Got answer:</nowiki>
<nowiki>;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37702</nowiki>
<nowiki>;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2</nowiki>
 
<nowiki>;; QUESTION SECTION:</nowiki>
<nowiki>;242.0.168.192.in-addr.arpa. </nowiki>  IN      PTR
 
<nowiki>;; ANSWER SECTION:</nowiki>
242.0.168.192.in-addr.arpa. 900 IN      PTR    nomade-frjo.stones.lan.
 
<nowiki>;; AUTHORITY SECTION:</nowiki>
0.168.192.in-addr.arpa. 604800  IN      NS      diamond.stones.lan.
0.168.192.in-addr.arpa. 604800  IN      NS      emerald.stones.lan.
 
<nowiki>;; ADDITIONAL SECTION:</nowiki>
diamond.stones.lan.    604800  IN      A      192.168.0.1
emerald.stones.lan.    604800  IN      A      192.168.0.2
 
<nowiki>;; Query time: 19 msec</nowiki>
<nowiki>;; SERVER: 127.0.0.1#53(127.0.0.1)</nowiki>
<nowiki>;; WHEN: Fri Mar 28 20:53:31 2008</nowiki>
<nowiki>;; MSG SIZE </nowiki> rcvd: 155
 
==== nslookup ====
* Kind of slow but still useful.
 
'''$ nslookup etch'''
Server:        192.168.0.1
Address:        192.168.0.1#53
Name:  etch.example.com
Address: 192.168.0.2
 
$ nslookup 192.168.0.2
Server:        192.168.0.1
Address:        192.168.0.1#53
2.0.168.192.in-addr.arpa        name = etch.example.com.* '''named-checkconf''' : Verifies the syntax of the configuration files for Bind9.
 
'''<nowiki># named-checkconf -z</nowiki>'''
zone localhost/IN: loaded serial 1
zone 127.in-addr.arpa/IN: loaded serial 1
zone 0.in-addr.arpa/IN: loaded serial 1
zone 255.in-addr.arpa/IN: loaded serial 1
zone estar.lan/IN: loaded serial 20080315
zone 0.168.192.in-addr.arpa/IN: loaded serial 20080315
zone 10.in-addr.arpa/IN: loaded serial 1
zone 16.172.in-addr.arpa/IN: loaded serial 1
zone 17.172.in-addr.arpa/IN: loaded serial 1
zone 18.172.in-addr.arpa/IN: loaded serial 1
zone 19.172.in-addr.arpa/IN: loaded serial 1
zone 20.172.in-addr.arpa/IN: loaded serial 1
zone 21.172.in-addr.arpa/IN: loaded serial 1
zone 22.172.in-addr.arpa/IN: loaded serial 1
zone 23.172.in-addr.arpa/IN: loaded serial 1
zone 24.172.in-addr.arpa/IN: loaded serial 1
zone 25.172.in-addr.arpa/IN: loaded serial 1
zone 26.172.in-addr.arpa/IN: loaded serial 1
zone 27.172.in-addr.arpa/IN: loaded serial 1
zone 28.172.in-addr.arpa/IN: loaded serial 1
zone 29.172.in-addr.arpa/IN: loaded serial 1
zone 30.172.in-addr.arpa/IN: loaded serial 1
zone 31.172.in-addr.arpa/IN: loaded serial 1
zone 168.192.in-addr.arpa/IN: loaded serial 1* '''named-checkzone''' : Verifies the validity of zone files before resetting the configuration.
 
'''<nowiki># named-checkzone example.com /var/lib/bind/db.example.com</nowiki>'''
zone example.com/IN: loaded serial 20080315
OK
<nowiki># named-checkzone 0.168.192.in-addr.arpa /var/lib/bind/db.example.com.inv</nowiki>
zone 0.168.192.in-addr.arpa/IN: loaded serial 20080315
OK
 
=== Links and Resources ===
* [http://www.ietf.org/rfc/rfc1035.txt rfc1035] - Implementation ans specifications
* [http://www.ietf.org/rfc/rfc1591.txt rfc1591] - Domain Name System Structure and Delegation
* [http://www.ietf.org/rfc/rfc2606.txt rfc2606] - Reserved Top Level DNS Names
* [http://www.bind9.net/manual/bind/9.3.2/Bv9ARM http://www.bind9.net/manual/bind/9.3.2/Bv9ARM] - Bind 9 Administrator Manual
* Services Whois :
** [http://www.gandi.net/whois?l=FR Gandhi]
** [http://www.afnic.fr/outils/whois/ AFNIC]
 
== BIND9 - Slave-Server ==
=== Einleitung ===
A nameserver running BIND can be configured to serve each zone as either a master or a slave:
* A slave obtains its copy of the zone data by means of a zone transfer from another nameserver.
* A master obtains zone data from some other source, allowing it to operate independently of other nameservers.
 
Every zone should have at least two nameservers. Typical practice is to have one master, and one or two slaves which take their zone data from that master.
 
==== Tested on ====
* Debian (Lenny)
* Ubuntu (Lucid, Maverick)
 
==== Scenario ====
* Suppose that the zone <tt>example.com</tt> has two nameservers, <tt>ns0.example.com</tt> (198.51.100.1) and <tt>ns1.example.com</tt> (203.0.113.1).
* Of these, <tt>ns0</tt> is already configured as a master. You wish to configure <tt>ns1</tt> as a slave, taking its zone data from <tt>ns0</tt>.
* Both nameservers are running BIND version&nbsp;9.
 
==== File locations ====
On Debian-based systems, zone declarations should be placed in the file <tt>/etc/bind/named.conf.local</tt> and options in the file <tt>/etc/bind/named.conf.options</tt>.
 
You should not modify <tt>/etc/bind/named.conf</tt>.
 
Slave zone files should be placed in <tt>/var/lib/bind</tt> (not <tt>/etc/bind</tt>) so that <tt>named</tt> has permission to write to them. Log messages are written to <tt>/var/log/daemon.log</tt>.
 
=== Vorgehen ===
There are three points to address if <tt>ns1</tt> is to act as a slave to <tt>ns0</tt>:# <tt>ns1</tt> must be configured to act as a slave nameserver for the zone.
# <tt>ns1</tt> must be told when to perform a zone transfer. The preferred method for <tt>ns0</tt> to send it a notification whenever a transfer is needed.
# <tt>ns0</tt> must be configured to allow zone transfers to <tt>ns1</tt>.
 
For most purposes the default configuration of BIND would satisfy points 2 and 3, however it is good practice to configure it explicitly if you intend to rely on its behaviour.
 
==== Add slave zone declaration to ns1 ====
The <tt>named</tt> configuration file must include a zone declaration for each zone to be served. Here is a suitable declaration for the zone <tt>example.com</tt> on <tt>ns1</tt>:
 
zone "example.com" {
  type slave;
  masters { 198.51.100.1; };
  file "/var/lib/bind/db.example.com";
};
 
Setting the <tt>type</tt> to <tt>slave</tt> specifies that the zone data is obtained from another nameserver.
 
The <tt>masters</tt> statement contains a list of nameservers from which zone data can be obtained.
 
These need not be masters in the sense defined above: it is possible (and sometimes necessary) for a slave to obtain zone data from another slave.
 
Masters must be specified as IP addresses, not as domain names, however it is possible to define a ‘masters list’ containing the required addresses which can then be referred to symbolically (see below).
 
Zone files are optional for slave nameservers, but strongly recommended otherwise the slave will lose all knowledge of the zone content whenever it is restarted.
 
It will not then be able to start serving the zone again until it has performed a zone transfer, and if the master is unavailable for any reason then the period of downtime could be substantial.
 
==== Enable notifications from ns0 ====
There are two ways to control when zone transfers take place:
* by polling at regular intervals, or
* by having the master notify the slave when the zone has changed.
 
The latter method is preferred as it is both quicker and more efficient.
 
BIND sends notifications by default, however it is good practice to enable them explicitly if they are an important part of the configuration. This can be done for individual zones:
 
zone "example.com" {
  type master;
  file "/var/lib/bind/db.example.com";
  notify yes;
  // …
};
 
or as the default for all zones:
 
options {
  notify yes;
  // …
};
 
The setting for a zone takes precedence, therefore if you use the latter method then you should check that it has not been overridden.
 
The master needs to know which nameservers to notify. By default it notifies the ones that have <tt>NS</tt> records, which for most purposes is sufficient.
 
Nameservers that do not have <tt>NS</tt> records can be notified by adding an <tt>also-notify</tt> statement. As previously this can be done either for an individual zone:
 
zone "example.com" {
  type master;
  notify yes;
  also-notify { 203.0.113.1; };
  file "/var/lib/bind/db.example.com";
};
 
or as the default for all zones:
 
options {
  notify yes;
  also-notify { 203.0.113.1; };
  // …
};
 
==== Allow zone transfers on ns0  ====
By default BIND allows zone transfers from anywhere. Opinion is divided as to whether this is good practice, and it is not unusual for a more restrictive policy to be imposed.
 
The servers that are allowed to perform transfers are specified in an <tt>allow-transfer</tt> statement. As with notifications this can be done either for an individual zone:
 
zone "example.com" {
  type master;
  notify yes;
  allow-transfer { 203.0.113.1; };
  file "/var/lib/bind/db.example.com";
};
 
or as the default for all zones:
 
options {
  notify yes;
  allow-transfer { 203.0.113.1; };
  // …
};
 
If you are content for zone transfers to be unrestricted then you can make this explicit using an address of <tt>any</tt>:
 
options {
  notify yes;
  allow-transfer { any; };
  // …
};
 
==== Reload ns0 ====
If the configuration of <tt>ns0</tt> has been changed in any way then it should be reloaded. * [http://www.microhowto.info/howto/cause_a_system_service_to_reload_its_configuration.html Cause a system service to reload its configuration]http://www.microhowto.info/howto/cause_a_system_service_to_reload_its_configuration.html.
 
==== Reload ns1 ====
The configuration of <tt>ns1</tt> will have changed, so it will certainly need to be reloaded. This should be the last thing that you do (after reloading <tt>ns0</tt> if necessary). * [http://www.microhowto.info/howto/cause_a_system_service_to_reload_its_configuration.html Cause a system service to reload its configuration]http://www.microhowto.info/howto/cause_a_system_service_to_reload_its_configuration.html.
 
=== Testing ===
==== Is ns1 serving the zone? ====
You can test whether <tt>ns1</tt> is operational by using the <tt>dig</tt> command to request the statement of authority record for the zone in question:
 
dig @203.0.113.1 -t SOA example.com +norecurs
 
The <tt>+norecurs</tt> flag at the end of the command instructs <tt>dig</tt> to perform a non-recursive query. The answer should be similar to the following:
 
<nowiki>;; ANSWER SECTION:</nowiki>
example.com.            86400  IN      SOA    example.com. hostmaster.example.com. 41 28800 7200 604800 86400
 
Receiving the correct answer indicates that <tt>ns1</tt> is functioning as a nameserver, but not necessarily that it is a slave for <tt>example.com</tt>: the answer could have been cached from a previous recursive query.
 
To tell the difference you should inspect the flags that are displayed near the start of the response:
 
<nowiki>;; Got answer:</nowiki>
<nowiki>;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42311</nowiki>
<nowiki>;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2</nowiki>
 
The <tt>aa</tt> flag is the significant one. If <tt>ns1</tt> is operating as a slave then the <tt>aa</tt> flag will be present, meaning that the answer is authoritative.
 
==== Check notifications  ====
The initial zone transfer is not dependent on notifications, but subsequent ones are (unless you intend to rely on polling). To test whether they are working you will need to modify the zone on <tt>ns0</tt> and check whether the change is replicated on <tt>ns1</tt>. The least invasive change you can make is to increment the serial number.
 
Edit the zone file on <tt>ns0</tt> and locate the SOA record. This should look similar to:
 
@      IN      SOA    example.com. hostmaster.example.com. (
                        41
                        8H
                        2H
                        1W
                        1D)
 
The serial number in this record is 41, therefore you should increment it to 42:
 
@      IN      SOA    example.com. hostmaster.example.com. (
                        42
                        8H
                        2H
                        1W
                        1D)
 
Now reload the configuration of <tt>named</tt> on <tt>ns0</tt> (see [http://www.microhowto.info/howto/cause_a_system_service_to_reload_its_configuration.html Cause a system service to reload its configuration]). <tt>ns0</tt> should notify <tt>ns1</tt> that it has a copy of the zone with a serial number of 42.
 
The copy of the zone held by <tt>ns1</tt> has an older serial number, 41, so when it receives the notification it should request a zone transfer.
 
You can determine whether this has happened by re-requesting the SOA record:
 
dig @203.0.113.1 -t SOA example.com +norecurs
 
If the serial number has changed to 42 then a zone transfer has occurred, which probably means that notifications are working:
 
<nowiki>;; ANSWER SECTION:</nowiki>
example.com.            86400  IN      SOA    example.com. hostmaster.example.com. 42 28800 7200 604800 86400
 
For additional confidence that a notification caused the transfer you can either repeat the test or inspect the logs.
 
=== Troubleshooting ===
If the tests described above indicate that <tt>ns1</tt> is not functioning as intended then you should attempt to answer the following questions:# Is <tt>named</tt> is running on <tt>ns0</tt> as an authoritative nameserver for <tt>example.com</tt>?
# Is <tt>named</tt> is running on <tt>ns1</tt>?
# Has <tt>ns1</tt> successfully performed an initial zone transfer, and if not why?
# Does <tt>ns0</tt> notify <tt>ns1</tt> when the zone serial number changes?
# Does <tt>ns1</tt> perform further zone transfers when notified by <tt>ns0</tt>?
# Questions 1 to 3 are relevant when <tt>ns1</tt> is not working as a nameserver at all. Questions 4 and 5 are relevant when it is working, but not responding to updates.
 
==== Is named running on ns0? ====
Before looking at <tt>ns1</tt> it would be prudent to check that <tt>ns0</tt> is working.
 
A good way to do this is to perform a remote query from <tt>ns0</tt> to <tt>ns1</tt> concerning the zone you are attempting to serve:
 
dig @198.51.100.1 -t SOA example.com
 
This should give an answer similar to the following:
 
<nowiki>;; ANSWER SECTION:</nowiki>
example.com.            86400  IN      SOA    example.com. hostmaster.example.com. 41 28800 7200 604800 86400
 
The <tt>aa</tt> flag should be set, indicating that this is an authoritative response:
 
<nowiki>;; Got answer:</nowiki>
<nowiki>;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13518</nowiki>
<nowiki>;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2</nowiki>
 
If either of these are missing then that would indicate <tt>ns0</tt> is running as a nameserver, but is not authoritative for <tt>example.com</tt>.
 
The absence of any response at all could indicate that there is no nameserver running on <tt>ns0</tt>, or that there is a problem with network connectivity.
 
Whatever the reason, it will need to be addressed before the slave nameserver on <tt>ns1</tt> can be properly tested.
 
==== Is named running on ns1? ====
You can check whether <tt>named</tt> is running using the <tt>ps</tt> command:
 
ps -C named
 
This should give a response of the form:
 
  PID TTY          TIME CMD
11409 ?        00:00:00 named
 
If no process is listed then you should try restarting <tt>named</tt>, then check again using <tt>ps</tt>. If it does not start then this may indicate that:
* there is a syntax error in one of the configuration files, or
* another process is listening on port 53.
 
The first of these is the more likely explanation. The log should contain enough information to identify the cause.
 
==== Did ns1 performed initial zone transfer? ====
You can check whether an initial zone transfer has occurred by looking for the zone file. This is the argument to the <tt>file</tt> statement in the zone declaration:
 
zone "example.com" {
  type slave;
  masters { 198.51.100.1; };
  file "/var/lib/bind/db.example.com";
};
 
The file should have been created by <tt>named</tt>, and have content equivalent to (but probably not identical to) the master zone file on <tt>ns0</tt>.
 
===== If it has not been written then this could be because: =====
* <tt>ns1</tt> has not requested a zone transfer, or
* <tt>ns1</tt> sent the request to the wrong nameserver, or
* <tt>ns1</tt> cannot communicate with <tt>ns1</tt>, or
* <tt>ns0</tt> refused to transfer the zone, or
* <tt>ns1</tt> received the zone data, but was unable to write the file.
 
You can check the first four points by viewing DNS traffic to and from <tt>ns1</tt> using <tt>tcpdump</tt>:
 
tcpdump -n "host ns1.example.com and (udp port 53 or tcp port 53)"
 
You should see an initial query for the SOA record (normally UDP), followed by the zone transfer (always TCP).
 
If <tt>ns0</tt> refused to transfer the zone then this should be recorded in the log on <tt>ns0</tt>, for example:
 
client 203.0.113.1#42541: zone transfer 'example.com/AXFR/IN' denied
 
If the transfer occurred but the file could not be written then this should be recorded in the log on <tt>ns1</tt>, for example:
 
dumping master file: /etc/bind/tmp-nIOVHD85JX: open: permission denied
 
See below for further consideration of these errors.
 
==== Dose ns0 notifies ns1? ====
You can check whether <tt>ns0</tt> is notifying <tt>ns1</tt> by using <tt>tcpdump</tt> to view the traffic:
 
tcpdump -n "host ns1.example.com and (udp port 53 or tcp port 53)"
 
A notification should look similar to:
 
198.51.100.1.3278 > 203.0.113.1.53: 62737 notify [b2&3=0x2400] [1a] SOA? example.com. (95)
203.0.113.1.53 > 198.51.100.1.3278: 62737 notify* 0/0/0 (29)
 
Notifications should also be logged by the sender:
 
zone example.com/IN: sending notifies (serial 42)
 
and by the receiver:
 
client 198.51.100.1#3278: received notify for zone 'example.com'
 
If notifications are not being sent or logged then you should check that they are enabled for the zone in question, and that <tt>ns1</tt> is either:
* listed as a nameserver using an <tt>NS</tt> record in the master zone file, or
* listed in a <tt>also-notify</tt> statement in the master zone declaration.
 
==== Is ns1 performing zone transfers? ====
Subsequent zone transfers can be viewed in the same way as the initial transfer, but may be considerably smaller if you have enabled the use of incremental transfers.
 
The most likely reason for the slave not requesting a transfer when it has received a notification is if it already has a copy of the zone with the same or a more recent serial number.
 
In that case you should advance the serial number of the master zone file until it is greater than that of the slave zone file.
 
=== Fehlermeldungen ===
==== Zone transfer denied ====
An error of the form:
 
client 203.0.113.1#42541: zone transfer 'example.com/AXFR/IN' denied
 
on <tt>ns0</tt> indicates that zone transfers have been restricted to a specific list of nameservers and that <tt>ns1</tt> is not one of them. You should look for a relevant <tt>allow-transfer</tt> statement in the configuration of <tt>ns0</tt> and add <tt>ns1</tt> to the list.
 
==== Dumping master file: permission denied ====
An error of the form:
 
dumping master file: /etc/bind/tmp-nIOVHD85JX: open: permission denied
 
on <tt>ns1</tt> indicates that <tt>named</tt> has successfully performed a zone transfer, but was unable to write the result to a zone file because it did not have permission to write to the relevant directory.
 
In this particular case it has been incorrectly configured to write the zone file to <tt>/etc/bind</tt>.
 
You should not attempt to fix this by granting write access to that directory: there are good security reasons why <tt>named</tt> should only have read access to its configuration.
 
Instead you should write the zone file to some other location. On Debian-based systems, the appropriate location is <tt>/var/lib/bind</tt>.
 
=== Variationen ===
==== Use a masters list ====
If it is necessary to refer to the same master nameserver(s) repeatedly then it is good practice to define a ‘masters list’ containing the relevant IP address(es) so that they can be referred to symbolically.
 
For example:
 
masters ns0 { 198.51.100.1; };
 
zone "example.com" {
        type slave;
        masters { ns0; };
        notify no;
        file "/var/lib/bind/zone.example.com";
};


zone "example.net" {
=== Links ===
        type slave;
==== Weblinks ====
        masters { ns0; };
# [https://www.isc.org/products/BIND/ https://www.isc.org/products/BIND/] — Die Homepage des BIND-Projekts.
        notify no;
# Hier finden Sie Informationen aktuellen Releases und können das ''BIND 9 Administrator Reference Manual'' in der PDF-Version herunterladen.
        file "/var/lib/bind/zone.example.net";
# [https://www.redhat.com/mirrors/LDP/HOWTO/DNS-HOWTO.html https://www.redhat.com/mirrors/LDP/HOWTO/DNS-HOWTO.html] — Befasst sich mit BIND als Caching-Nameserver und der Konfiguration der einzelnen Zone-Dateien sowie der Konfiguration verschiedener Zone-Dateien, die als primärer Name-Server für eine Domain benötigt werden.
};


Doing this reduces the risk of specifying the wrong IP address, and simplifies the task of changing the address should this ever be necessary.
[[Kategorie:BIND9]]
[[Kategorie:Domain Name System/Client]]
</noinclude>

Aktuelle Version vom 20. August 2025, 08:07 Uhr

Berkeley Internet Name Domain - Programmpaket zur Namensauflösung im Domain Name System


Beschreibung

Berkeley Internet Name Domain (BIND)

Die meisten modernen Netzwerke, einschließlich dem Internet, erlauben dem Benutzer andere Computer über deren Namen zu bestimmen.

  • Dies befreit den Benutzer davon, die numerische Netzwerk-Adresse behalten zu müssen.
  • Der effektivste Weg ein Netzwerk zu konfigurieren, sodass es namensbasierte Verbindungen zulässt, ist durch das Einrichten eines Domain Name Service (DNS) oder Nameserver, welcher Rechnernamen in numerische Adressen auflöst und umgekehrt.
Warnung
Wenn Sie das Domain Name Service Configuration Tool verwenden, sollten Sie die BIND-Konfigurationsdateien nicht manuell bearbeiten, da alle manuell vorgenommenen Änderungen vom Domain Name Service Configuration Tool beim nächsten mal überschrieben werden, wenn dieses benutzt wird.

Einführung

Wenn Hosts auf einem Netzwerk zu einem anderen über deren Hostnamen, auch fully qualified domain name (FQDN) genannt, verbinden, wird DNS verwendet, um die IP-Adressen der Rechner über deren Hostnamen zu bestimmen.

Die Verwendung von DNS und FQDN sind auch für Systemadministratoren vorteilhaft
  • Dank dieser Namen verfügen Administratoren über die Flexibilität, IP-Adressen für einzelne Rechner zu ändern, ohne namenbasierte Abfragen der Rechner ausführen zu müssen.
  • Umgekehrt können die Administratoren festlegen, welche Rechner eine namenbasierte Abfrage in einer für die Benutzer transparenten Weise handhaben.
DNS wird im Allgemeinen mit Hilfe zentralisierter Server implementiert, die für einige Domains authorisiert sind und sich auf andere DNS-Server für andere Domains beziehen.
Eine Client-Applikation verbindet üblicherweise über den Port 53 mit dem Nameserver und fragt Informationen über diesen ab.
  • Der Nameserver wird versuchen, mit Hilfe einer Resolver-Bibliothek den FQDN zu lösen.
  • Diese Bibliothek kann die vom Host angeforderten Informationen oder Daten über den Namen aus einer früheren Abfrage enthalten.
  • Wenn der Nameserver die Antwort nicht in seiner Resolver-Bibliothek findet, wird er andere Nameserver, die sogenannten Root-Nameserver verwenden, um festzulegen, welche Nameserver für diesen FQDN autorisiert sind.
  • Mit dieser Information wird anschließend bei den autorisierten Nameservern dieser Name abgefragt, um die IP-Adresse festzustellen.
  • Bei einem Reverse-Lookup wird die gleiche Prozedur durchgeführt, allerdings mit dem Unterschied, dass hier eine unbekannte IP-Adresse und nicht ein Name abgefragt wird.

Nameserver Zonen

Im Internet kann ein FQDN eines Hosts in verschiedene Bereiche eingeteilt werden
  • Diese Bereiche werden in einer Hierarchie (ähnlich einem Baum) mit Hauptstamm, primären Abzweigungen, sekundären Abzweigungen und weitere angeordnet.

Betrachten Sie den folgenden FQDN: 

bob.sales.example.com
Wenn Sie sehen möchten, wie ein FQDN aufgelöst wurde, um eine IP-Adresse für ein bestimmtes System zu finden, müssen Sie den Namen von rechts nach links lesen.
  • Jede Ebene der Hierarchie ist durch Punkte (.) voneinander getrennt.
  • In diesem Beispiel bestimmt com die Top-Level-Domain für diesen FQDN.
  • Der domain-Name ist eine Subdomain von com mit sales als Subdomain von example.
  • Ganz links im FQDN befindet sich der Hostname, bob, der einen bestimmten Computer identifiziert.
Mit Ausnahme des Hostnamens wird jeder Bereich als Zone bezeichnet, die einen bestimmten Namespace (Namensbereich) festlegt.
  • Ein Namespace kontrolliert die Bezeichnung der Subdomains auf der linken Seite.
  • In diesem Beispiel sind zwar nur zwei Subdomains angegeben, ein FQDN muss aber mindestens eine und kann viel mehr Subdomains enthalten, je nach der Organisation des Namespace.
Die Zonen werden mit Hilfe von Zone-Dateien in authorisierten Nameservern festgelegt
  • Die Zone-Dateien beschreiben den Namenspace der Zone, den für eine bestimmte Domain oder Subdomain zu verwendenden Mail-Server, uvm.
  • Die Zone-Dateien sind auf primären Nameservern (auch Master-Nameserver genannt) gespeichert, die für Änderungen an Dateien maßgeblich sind, sowie auf sekundären Nameservern (auch Slave-Nameserver genannt), die ihre Zone-Dateien von den primären Nameservern erhalten.
  • Jeder Nameserver kann gleichzeitig für unterschiedliche Zonen sowohl primärer als auch sekundärer Nameserver sein.
  • Zugleich können sie auch für mehrere Zonen maßgeblich sein.
  • Dies hängt alles von der Konfiguration des Nameservers ab.

Nameserver Arten

Primäre Nameserver können auf vier verschiedene Arten konfiguriert sein
Option Beschreibung
Master Speichert die ursprünglichen und maßgeblichen Zonen für einen bestimmten Namespace, und beantwortet Fragen von anderen Nameservern, die nach Antworten für diesen Namespace suchen.
Slave Beantwortet ebenfalls die Anfragen anderer Nameserver bezüglich des Namespace, für den dieser die Autorität darstellt.
  • Die Slave-Nameserver erhalten ihre Informationen über ein Namespace jedoch von Master-Nameservern.
Caching-Only Bietet Dienste für IP-Auflösungen, hat aber nicht für alle Zonen eine Berechtigung.
  • Antworten für alle Auflösungen werden üblicherweise für eine bestimmte Zeit im Speicher gecachet, welche von dem abgefragten Zone-Record festgelegt wird.
Forwarding Leitet Anfragen zum Auflösen an eine spezielle Liste von Nameservern weiter.
  • Wenn keiner der angegebenen Nameserver den Auflösungsprozess durchführen kann, wird der Vorgang abgebrochen und die Auflösung schlägt fehl.
Ein Nameserver kann einem oder mehreren dieser Typen zugehören

Zum Beispiel kann ein Nameserver für einige Zonen der Master und für andere Zonen der Slave sein und für andere ausschließlich Auflösungen weiterleiten.

BIND als Nameserver

BIND führt Namensauflösungsdienste mittles /usr/sbin/named Daemon durch

BIND enthält auch eine administrative Utility
/usr/sbin/rndc
BIND speichert seine Konfigurationsdateien in den folgenden zwei Orten
  • /etc/named.conf — Die Konfigurationsdatei für den named Daemon.
  • /var/named/ directory — Das named Arbeitsverzeichnis, welches Zone, Statistiken, und Cache-Dateien enthält.

Anhang

Siehe auch

Zusätzliche Ressourcen

Installierte Dokumentation

  • BIND verfügt über installierte Dokumentationen, die verschiedene Themen behandeln und jeweils in einem eigenen Verzeichnis abgelegt sind:
    • /usr/share/doc/bind-<version-number>/ — Dieses Verzeichnis listet die neuesten Features.
  • Ersetzen Sie dazu <version-number> mit der auf Ihrem System installierten Version von bind.
    • /usr/share/doc/bind-<version-number>/arm/ — Enthält das BIND 9 Administrator Reference Manual im HTML- und SGML-Format, welches Details über die für BIND erforderlichen Ressourcen, Informationen zur Konfigurationsweise der verschiedenen Name-Server-Typen, zur Durchführung des Load-Balancing und anderen spezielleren Themen enthält.
  • Die meisten neuen Benutzer werden sich mit dieser Informationsquelle am besten mit BIND vertraut machen können.
  • Ersetzen Sie <version-number> mit der auf Ihrem System installierten Version von bind.
    • /usr/share/doc/bind-<version-number>/draft/ — Enthält ausgewählte technische Dokumente, die sich mit dem DNS Service und damit verbundenen Problemen beschäftigen und einige Methoden zur Lösung dieser Probleme vorschlagen.
  • Ersetzen Sie <version-number> mit der auf Ihrem System installierten Version von bind.
    • /usr/share/doc/bind-<version-number>/misc/ — Enthält Dokumente über spezielle verbesserte Merkmale.
  • Benutzer der Version 8 von BIND sollten sich das Dokument migration anschauen, das sich mit bestimmten Änderungen befasst, die für eine Verwendung der Version 9 von BIND vorzunehmen sind.
  • In der options-Datei sind alle in BIND 9 implementierten Optionen aufgelistet, die in /etc/named.conf verwendet werden.
  • Ersetzen Sie <version-number> mit der auf Ihrem System installierten Version von bind.
    • /usr/share/doc/bind-<version-number>/rfc/ — In diesem Verzeichnis finden Sie jedes RFC-Dokument, das mit BIND zusammenhängt.
  • Ersetzen Sie <version-number> mit der auf Ihrem System installierten Version von bind.
  • BIND-relevante man-Seiten — Es gibt einige man-Seiten zu den verschiedenen Applikationen und Konfigurationsdateien die im Bezug zu BIND stehen.
  • Einige der wichtigeren man-Seiten sind wie folgt aufgelistet.

Administrative Applikationen

  • man rndc — Erklärt die verschiedenen Optionen, die bei der Verwendung von rndc zur Kontrolle eines BIND Name-Servers zur Verfügung stehen.

Server-Applikationen

  • man named — Untersucht ausgewählte Argumente, die zur Steuerung des BIND-Name-Server-Daemon verwendet werden können.
  • man lwresd — Beschreibt den Lightweight-Resolver-Daemon und dessen verfügbare Optionen.

Konfigurationsdateien

  • man named.conf — Eine vollständige Liste von Optionen, welche in der named-Konfigurationsdatei zur Verfügung stehen.
  • man rndc.conf — Eine vollständige Liste von Optionen, welche in der rndc-Konfigurationsdatei zur Verfügung stehen.


Links

Weblinks

  1. https://www.isc.org/products/BIND/ — Die Homepage des BIND-Projekts.
  2. Hier finden Sie Informationen aktuellen Releases und können das BIND 9 Administrator Reference Manual in der PDF-Version herunterladen.
  3. https://www.redhat.com/mirrors/LDP/HOWTO/DNS-HOWTO.html — Befasst sich mit BIND als Caching-Nameserver und der Konfiguration der einzelnen Zone-Dateien sowie der Konfiguration verschiedener Zone-Dateien, die als primärer Name-Server für eine Domain benötigt werden.
Abgerufen von „https://wiki.foxtom.de/index.php?title=Berkeley_Internet_Name_Domain&oldid=151526“