Berkeley Internet Name Domain (BIND): Unterschied zwischen den Versionen
K Textersetzung - „Kurzbeschreibung“ durch „Beschreibung“ |
|||
(28 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt) | |||
Zeile 1: | Zeile 1: | ||
'''topic''' - Beschreibung | |||
== Beschreibung == | |||
== Berkeley Internet Name Domain (BIND) == | == 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 | ; 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 == | |||
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 | ; 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 === | |||
Im Internet kann ein FQDN eines Hosts in verschiedene Bereiche eingeteilt werden | ; 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: | |||
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. | |||
* 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. | |||
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. | ; 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 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 | ; Primäre Nameserver können auf vier verschiedene Arten konfiguriert sein | ||
{| class="wikitable sortable options" | |||
|- | |||
! 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 | ; 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 führt Namensauflösungsdienste mittles <tt>/usr/sbin/named</tt> Daemon durch | ||
; BIND enthält auch eine administrative Utility | |||
/usr/sbin/rndc | |||
BIND speichert seine Konfigurationsdateien in den folgenden zwei Orten | ; BIND speichert seine Konfigurationsdateien in den folgenden zwei Orten | ||
* <tt>/etc/named.conf</tt> — Die Konfigurationsdatei für den <tt>named</tt> Daemon. | * <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. | * <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. | ; 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. | |||
; Warnung | |||
: 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>''] { | ''<statement-1>'' ["''<statement-1-name>''"] [''<statement-1-class>''] { | ||
''<option-1>''<nowiki>;</nowiki> | ''<option-1>''<nowiki>;</nowiki> | ||
Zeile 76: | Zeile 106: | ||
}; | }; | ||
=== Häufig verwendete Statements === | |||
==== acl Statement ==== | |||
Das <tt>acl</tt> Statement (Access Control Statement) definiert eine Gruppe von Hosts, welchen Zugriff zum Nameserver erlaubt oder verboten werden kann. | Das <tt>acl</tt> Statement (Access Control Statement) definiert eine Gruppe von Hosts, welchen Zugriff zum Nameserver erlaubt oder verboten werden kann. | ||
Zeile 89: | Zeile 117: | ||
}; | }; | ||
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. | 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: | Die folgenden Access-Control-Listen sind bereits als Schlüsselwörter definiert, um die Konfiguration zu vereinfachen: | ||
Zeile 116: | Zeile 145: | ||
} | } | ||
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. | 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. | 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: | Ein <tt>include</tt> Statement hat die folgende Form: | ||
Zeile 126: | Zeile 157: | ||
In diesem Statement, ersetzen Sie <tt>''<file-name>''</tt> mit dem absoluten Pfad zu einer Datei. | 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 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: | Das <tt>options</tt> Statement hat die folgende Form: | ||
Zeile 138: | Zeile 170: | ||
Die folgenden sind häufig benutzte Optionen: | 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-query</tt> — Legt fest, welche Hosts diesen 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. | * 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>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>directory</tt> — Ändert das <tt>named</tt>-Arbeitsverzeichnis, so dass es sich von dem Default, <tt>/var/named/</tt>, unterscheidet. | ||
Zeile 145: | Zeile 180: | ||
Die folgenden Optionen werden angenommen: | 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>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>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>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: | * <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 { | options { | ||
listen-on { 10.0.1.1; }; | 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. | 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. | * <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: | 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: | ||
Zeile 162: | Zeile 201: | ||
** <tt>explicit</tt> — Informiert Slave-Server nur dann, wenn diese in einer <tt>also-notify</tt> List innerhalb des Zonen Statement angegeben sind. | ** <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>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. | * <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 { | Options { | ||
Zeile 169: | Zeile 210: | ||
"pf"; "se"; "sr"; "to"; "tw"; "us"; "uy"; }; | "pf"; "se"; "sr"; "to"; "tw"; "us"; "uy"; }; | ||
}; | }; | ||
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>. | * <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 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: | Ein <tt>zone</tt> Statement hat die folgende Form: | ||
Zeile 186: | Zeile 230: | ||
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. | 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. | 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. | 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. | ||
Zeile 193: | Zeile 238: | ||
Die am häufigsten verwendeten Optionen von <tt>zone</tt> Statement sind die Folgenden: | 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-query</tt> — Legt fest, welche Clients Informationen über diese Zone anfordern dürfen. | ||
* <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. | * Standardmäßig sind alle 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>allow-transfer</tt> — Bestimmt die Slave-Server, die den Transfer der Informationen über die Zonen anfordern dürfen. | ||
* <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>. | * Standardmäßig sind alle Transfer-Anfragen zulässig. | ||
* <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>allow-update</tt> — Bestimmt die Hosts, die Informationen in ihrer Zone dynamisch aktualisieren dürfen. | ||
* <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: | * 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>yes</tt> — Informiert Slave-Server. | ||
** <tt>no</tt> — Informiert Slave-Server nicht. | ** <tt>no</tt> — Informiert Slave-Server nicht. | ||
Zeile 206: | Zeile 258: | ||
Folgend ist eine Liste der gültigen Optionen: | 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>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>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>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. | ||
** <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. | * 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>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. | * <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. | 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: | 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: | ||
Zeile 226: | Zeile 286: | ||
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. | 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. | 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. | |||
Nachfolgend finden Sie ein Beispiel für eine <tt>zone</tt>-Anweisung für die <tt>example.com</tt> Zone: | Nachfolgend finden Sie ein Beispiel für eine <tt>zone</tt>-Anweisung für die <tt>example.com</tt> Zone: | ||
Zeile 236: | Zeile 298: | ||
}; | }; | ||
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. | 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: | 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>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. | * <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: | 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>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. | * <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. | 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>logging</tt> — Erlaubt die Verwendung mehrerer Arten von Protokollen mit der Bezeichnung ''channels''. | ||
* <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. | * 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. | ||
* <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. | * 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. | ||
* <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. | * 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: | 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>//</tt> — Wenn an den Anfang der Zeile gestellt, wird diese Zeile von <tt>named</tt> ignoriert. | ||
Zeile 259: | Zeile 339: | ||
* <tt>/*</tt> und <tt><nowiki>*/</nowiki></tt> — Hierin eingeschlossener Text wird 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>. | ''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. | 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. | Alle Anweisungen und Resource-Records sollten in einer eigenen Zeile stehen. | ||
Zeile 268: | Zeile 352: | ||
Kommentare können in Zone-Dateien nach dem Semikolon (<tt><nowiki>;</nowiki></tt>) platziert werden. | 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. | 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: | 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>$INCLUDE</tt> — Weist <tt>named</tt> an, in diese Zone-Datei an Stelle der Anweisung eine andere Zone-Datei einzufügen. | ||
* <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. | * 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: | 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. | $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. | ||
; Anmerkung | ; Anmerkung | ||
: 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. | : 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. | |||
* <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. | * <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. | 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. | Die Hauptkomponente einer Zone-Datei sind deren Resource-Records. | ||
Es gibt viele Typen von Resource-Records. Folgende werden am häufigsten verwendet: | Es gibt viele Typen von Resource-Records. | ||
* <tt>A</tt> — Adressen-Record, das einem Namen eine IP-Adresse zuweist. Beispiel: | * 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. | ''<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: | Beachten Sie das folgende <tt>A</tt>-Record-Beispiel für die <tt>example.com</tt> Zone-Datei: | ||
IN A 10.0.1.3 | 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. | 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 | 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. | 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. | 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. | Der <tt>''<email-server-name>''</tt> kann ein Hostname oder ein FQDN sein. IN MX 10 mail.example.com. | ||
Zeile 308: | Zeile 405: | ||
IN NS ''<nameserver-name>''Der <tt>''<nameserver-name>''</tt> sollte ein FQDN sein. | 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. | 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. | 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. | <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. | Nach den Direktiven festgelegt ist ein <tt>SOA</tt>-Resource-Record, der erste Resource-Record in einer Zone-Datei. | ||
Zeile 323: | Zeile 422: | ||
''<minimum-TTL> )'' | ''<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. | 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>''<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. | 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. | <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. | 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" | {|| class="wikitable sortable options" | ||
Zeile 372: | Zeile 478: | ||
; Sekunden im Vergleich zu anderen Zeiteinheiten | ; Sekunden im Vergleich zu anderen Zeiteinheiten | ||
Das folgende Beispiel zeigt Ihnen, wie ein <tt>SOA</tt>-Resource-Record aussehen könnte, wenn es mit echten Werten konfiguriert ist. | Das folgende Beispiel zeigt Ihnen, wie ein <tt>SOA</tt>-Resource-Record aussehen könnte, wenn es mit echten Werten konfiguriert ist. | ||
@ IN SOA dns1.example.com. hostmaster.example.com. ( | @ IN SOA dns1.example.com. hostmaster.example.com. ( | ||
2001062501 ; serial | 2001062501 ; serial | ||
Zeile 380: | Zeile 486: | ||
86400 ) <nowiki>; minimum TTL of 1 day</nowiki> | 86400 ) <nowiki>; minimum TTL of 1 day</nowiki> | ||
=== Beispiele für Zone-Dateien === | |||
Einzeln betrachtet könnten die Anweisungen und Resource-Records schwer zu verstehen sein. Sind beide in einer gemeinsamen Datei plaziert, wird es einfacher. | Einzeln betrachtet könnten die Anweisungen und Resource-Records schwer zu verstehen sein. | ||
* Sind beide in einer gemeinsamen Datei plaziert, wird es einfacher. | |||
Im nächsten Beispiel ist eine sehr einfache Zone-Datei abgebildet. | Im nächsten Beispiel ist eine sehr einfache Zone-Datei abgebildet. | ||
Zeile 393: | Zeile 500: | ||
604800 <nowiki>; expire after 1 week</nowiki> | 604800 <nowiki>; expire after 1 week</nowiki> | ||
86 400 ) <nowiki>; minimum TTL of 1 day</nowiki> | 86 400 ) <nowiki>; minimum TTL of 1 day</nowiki> | ||
IN NS dns1.example.com. | IN NS dns1.example.com. | ||
IN NS dns2.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 | IN A 10.0.1.5 | ||
Zeile 412: | Zeile 519: | ||
www IN CNAME server2 | www IN CNAME server2 | ||
In diesem Beispiel werden Standard-Anweisungen und <tt>SOA</tt>-Werte verwendet | ; 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 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. | |||
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. | * 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. | 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: | Ein <tt>PTR</tt>-Record sieht Folgendem ähnlich: | ||
Zeile 456: | Zeile 565: | ||
}; | }; | ||
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. | 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. | |||
== 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. | 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 | ; 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. | : 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. | 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. | 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. | 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. | 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. | ||
Zeile 478: | Zeile 598: | ||
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. | 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: | 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. | * ''DNSSEC'' — Abkürzung für ''DNS SECurity''. | ||
* ''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. | * 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. | 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. | 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. | |||
== 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 ==== | |||
* <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 ==== | |||
* <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 ==== | |||
* <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. | ||
==== | <noinclude> | ||
=== Links === | |||
==== Weblinks ==== | |||
# [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. | |||
[[Kategorie:BIND9]] | |||
</noinclude> | |||
Aktuelle Version vom 19. Oktober 2024, 13:38 Uhr
topic - Beschreibung
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 usw. 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.
|
Caching-Only | Bietet Dienste für IP-Auflösungen, hat aber nicht für alle Zonen eine Berechtigung.
|
Forwarding | Leitet Anfragen zum Auflösen an eine spezielle Liste von Nameservern weiter.
|
- 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.
/etc/named.conf
- Die Datei named.conf ist eine Ansammlung von Direktiven, die in verschachtelte, geschweifte Klammern platzierte { }-Optionen verwenden.
- Administratoren müssen vorsichtig beim Bearbeiten der Datei named.conf sein und jegliche syntaktische Fehler vermeiden, da auch die kleinsten Fehler den Service named vom Starten abhalten können.
- Warnung
- Bearbeiten Sie die Datei /etc/named.conf oder andere Dateien aus dem /var/named/-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 named.conf-Datei ist ähnlich wie folgt gegliedert
<statement-1> ["<statement-1-name>"] [<statement-1-class>] { <option-1>; <option-2>; <option-N>; }; <statement-2> ["<statement-2-name>"] [<statement-2-class>] { <option-1>; <option-2>; <option-N>; }; <statement-N> ["<statement-N-name>"] [<statement-N-class>] { <option-1>; <option-2>; <option-N>; };
Häufig verwendete Statements
acl Statement
Das acl Statement (Access Control Statement) definiert eine Gruppe von Hosts, welchen Zugriff zum Nameserver erlaubt oder verboten werden kann.
Ein acl Statement hat folgende Form:
acl <acl-name> { <match-element>; [<match-element>; ...] };
In diesem Statement ersetzen Sie <acl-name> mit dem Namen der Access-Control-Liste (Liste der Zugriffskontrolle) und ersetzen Sie <match-element> mit einer List von IP-Adressen, wobei Adressen durch ein Semikolon getrennt werden.
- Meistens wird eine individuelle IP-Adresse oder IP-Netzwerk-Notation (wie 10.0.1.0/24) benutzt, um die IP Adresse im acl Statement zu identifizieren.
Die folgenden Access-Control-Listen sind bereits als Schlüsselwörter definiert, um die Konfiguration zu vereinfachen:
- any — Vergleicht jede IP-Adresse.
- localhost — Vergleicht jede IP-Adresse, die auf dem lokalen System verwendet wird.
- localnets — Vergleicht jede IP-Adresse auf allen Netzwerken, mit denen das lokale System verbunden ist.
- none — Vergleicht keine IP-Adressen.
Wenn mit anderen Statements (wie dem options Statement) verwendet, können acl 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 options 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, black-hats und red-hats.
- Hosts in der black-hats Liste ist der Zugriff zum Nameserver verboten, während Hosts in der red-hats Liste normaler Zugriff gewährt ist.
include Statement
Das include Statement erlaubt Dateien in named.conf einzuschliessen.
- Auf diese Weise können empfindliche Konfigurationsdaten (wie Keys) in einer separaten Datei mit eingeschränkten Rechten gehalten werden.
Ein include Statement hat die folgende Form:
include "<file-name>"
In diesem Statement, ersetzen Sie <file-name> mit dem absoluten Pfad zu einer Datei.
options Statement
Das options Statement legt Konfigurationsoptionen des globalen Servers fest und setzt Defaults für andere Statements.
- Es kann verwendet werden, um den Ort des named Arbeitsverzeichnisses anzugeben, den Typ der erlaubten Queries, uvm.
Das options Statement hat die folgende Form:
options { <option>; [<option>; ...] };
In diesem Statement, ersetzen Sie die <option> Direktiven mit einer gültigen Option.
Die folgenden sind häufig benutzte Optionen:
- allow-query — 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.
- allow-recursion — Ähnelt der Option allow-query, mit der Ausnahme, dass sie sich auf rekursive Abfragen bezieht.
- Standardmäßig können alle Hosts rekursive Abfragen auf dem Nameserver durchführen.
- blackhole — Gibt an, welchen Hosts es nicht erlaubt ist Anfragen an den Server zu stellen.
- directory — Ändert das named-Arbeitsverzeichnis, so dass es sich von dem Default, /var/named/, unterscheidet.
- forward — Kontrolliert das Verhalten beim Weiterleiten einer forwarders Direktive.
Die folgenden Optionen werden angenommen:
- first — Gibt an, dass Nameserver, die in der forwarders-Option festgelegt sind, zuerst nach Informationen abgefragt werden.
- Sollten anschließend keine Informationen vorhanden sein, versucht named die Auflösung selbst durchzuführen.
- only — Gibt an, dass named nicht versucht, die Auflösung selbst durchzuführen, wenn die forwarders Direktive nicht erfolgreich war.
- forwarders — Legt eine Liste von Nameservern fest, bei denen Abfragen für Auflösungen weitergeleitet werden.
- listen-on — Legt die Netzwerk-Schnittstelle fest, die named 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 listen-on 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 (10.0.1.1) verwendet.
- notify — Wird verwendet, wenn die Zone als Slave type festgelegt ist.
Die masters- Option teilt dem named eines Slaves die IP-Adressen mit, von denen maßgebliche Informationen über die Zone angefragt werden:
- yes — Informiert Slave-Server.
- no — Informiert Slave-Server nicht.
- explicit — Informiert Slave-Server nur dann, wenn diese in einer also-notify List innerhalb des Zonen Statement angegeben sind.
- pid-file — Legt die Lokalität für die Prozess-ID-Datei fest, die von named erstellt wurde.
- root-delegation-only — 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 recordsbenutzt.
- NameServer-Records (Delegation-Records) geben die maßgeblichen (autoritativen) Nameserver für eine bestimmte Zone bekannt.
Das folgende root-delegation-only-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"; }; };
* statistics-file — Erlaubt das Festlegen eines alternativen Ortes in welcher die Statistik-Dateien abgelegt werden.
- Standardmäßig werden named-Statistiken in /var/named/named.stats 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 Abschnitt 12.7.1, und in den man-Seiten zu bind.conf.
zone Statement
Ein zone Statement legt die Eigenschaften einer Zone, wie den Ort der Konfigurationsdatei und Zonen-spezifische Optionen fest.
- Dieses Statement kann dazu benutzt werden, um globale options Statements zu überschreiben.
Ein zone Statement hat die folgende Form:
zone <zone-name> <zone-class> { <zone-options>; [<zone-options>; ...] };
In diesem Statement <zone-name> ist der Name der Zone, <zone-class> ist die optionale Klasse der Zone, und <zone-options> ist eine List von Optionen, welche die Eigenschaften der Zone bestimmen.
Das <zone-name>-Attribut für das Zonen Statement ist besonders wichtig, da es den Standardwert für die $ORIGIN-Anweisung festlegt, welche den Zonen-Dateien im Verzeichnis /var/named/ entspricht.
- Der Daemon named hängt den Namen der Zone an jeden Nicht-FQDN an, welcher in der Zonen-Datei aufgelistet ist.
Wenn, zum Beispiel, ein zone Statement den Namespace für example.com angibt, verwende example.com als <zone-name>, damit es an Hostnamen in der example.com Zonen-Datei angehängt wird.
Für mehr Information zu Zonen-Dateien, siehe Abschnitt 12.3.
Die am häufigsten verwendeten Optionen von zone Statement sind die Folgenden:
- allow-query — Legt fest, welche Clients Informationen über diese Zone anfordern dürfen.
- Standardmäßig sind alle Anfragen zulässig.
- allow-transfer — Bestimmt die Slave-Server, die den Transfer der Informationen über die Zonen anfordern dürfen.
- Standardmäßig sind alle Transfer-Anfragen zulässig.
- allow-update — Bestimmt die Hosts, die Informationen in ihrer Zone dynamisch aktualisieren dürfen.
- Standardmäßig sind Anfragen für dynamische Updates nicht zulässig.
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 named-Service, soweit möglich, neu zu laden.
- file — Bestimmt den Namen der Datei im named-Arbeitsverzeichnis, die die Zone-Konfigurationsdateien enthält.
- Standardmäßig ist dies /var/named/.
- masters — Gibt die IP-Adressen an, von denen authoritäre Zoneninformationen erfragt werden können.
- Wird nur verwendet, wenn die Zone als type slave spezifiziert ist.
- notify — Gibt an, ob named den Slave-Servern mitteilt, daß eine Zone geändert wurde.
- Diese Direktive kennt die folgenden Optionen:
- yes — Informiert Slave-Server.
- no — Informiert Slave-Server nicht.
- explicit — Informiert Slave-Server nur dann, wenn diese in einer also-notify List innerhalb des Zonen Statement angegeben sind.
- type — Gibt den Typ der Zone an.
Folgend ist eine Liste der gültigen Optionen:
-
- delegation-only — Erzwingt den Delegation-Status von Infrastruktur-Zonen wie z. B.
- COM, NET oder ORG.
- Jegliche Antwort ohne explizite oder implizite Delegation wird als NXDOMAIN behandelt.
- Diese Option ist nur in TLDs oder root-Zone-Dateien anwendbar, die in rekursiven oder Caching Implementationen verwendet werden.
- forward — Weist den Nameserver an, alle Anfragen zu Informationen über die Zone an andere Nameserver weiterzuleiten.
- hint — 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 /etc/named.conf keine zusätzliche Hinweisdatei zu konfigurieren.
- master — Bezeichnet den Nameserver, der für diese Zone maßgeblich ist.
- Wenn die Konfigurationsdateien für diese Zone auf Ihrem System sind, sollte der master-Typ eingestellt werden.
- slave — Bezeichnet den Nameserver, der für diese Zone der Slave-Server ist und der named mitteilt, die Zonen-Konfigurationsdateien für diese Zone von der IP-Adresse des Master-Nameservers abzufragen.
- zone-statistics — Weist named an, die Statistiken über diese Zone aufzubewahren und diese entweder in der Standard-Datei (/var/named/named.stats) oder an einer Stelle abzulegen, die mit der statistics-file-Option im server-Statement, sofern vorhanden, dafür eingerichtet wurde.
- Sehen Sie Abschnitt 12.2.2 für weitere Information über das server-Statement.
Beispiele von zone-Statements
Die meisten Änderungen in der /etc/named.conf-Datei eines Master- oder Slave-Nameservers betreffen das Hinzufügen, Modifizieren oder Löschen von zone-Direktiven.
- Obwohl diese zone-Anweisungen mehrere Optionen enthalten können, werden von den meisten Nameservern nur wenige verwendet.
- Die folgenden zone-Direktiven sind sehr allgemeine Beispiele, die auf Master-Slave-Nameservern verwendet werden können.
Nachfolgend finden Sie ein Beispiel für eine zone- Anweisung für den primären Nameserver, der example.com (192.168.0.1) hostet:
zone "example.com" IN { type master; file "example.com.zone"; allow-update { none; }; };
Diese zone-Direktive benennt die Zone example.com, stellt als Typ master ein und weist den named-Service an, die Datei /var/named/example.com.zone zu lesen und weist named an, Aktualisierungen durch andere Hosts nicht zuzulassen.
Eine zone-Anweisung eines Slave-Servers für example.com unterscheidet sich etwas vom vorherigen Beispiel.
- Für einen Slave-Server wird der Typ auf slave festgelegt.
- An die Stelle der Zeile allow-update tritt eine Anweisung, die named die IP-Adresse des Master-Servers mitteilt.
Nachfolgend finden Sie ein Beispiel für eine zone-Anweisung für die example.com Zone:
zone "example.com" { type slave; file "example.com.zone"; masters { 192.168.0.1; }; };
Diese zone-Anweisung weist named auf dem Slave-Server an, bei dem Master-Server mit der IP 192.168.0.1 nach Informationen für die Zone example.com zu suchen.
- Die Informationen, die der Slave-Server vom Master-Server erhält, werden in der Datei /var/named/example.com.zone gespeichert.
Andere Statement-Typen
Die Folgende ist eine Liste von weniger verwendeten Statement-Typen welche in named.conf verfügbar sind:
- controls — Konfiguriert verschiedene Sicherheitsbedingungen, die für den Befehl rndc zum Verwalten des named-Services nötig sind.
Unter Abschnitt 12.4.1 sehen Sie, wie die controls-Anweisung aussehen sollte, einschließlich der verfügbaren Optionen. - key "<key-name>" — 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 rndc-Befehls.
Mit key werden zwei Optionen verwendet:
- algorithm <algorithm-name> — Der verwendete Algorithmus-Typ, z. B. dsa oder hmac-md5.
- secret "<key-value>" — Der verschlüsselte Schlüssel.
Unter Abschnitt 12.4.2 finden Sie die Anweisungen zum Schreiben eines key-Statement.
- logging — Erlaubt die Verwendung mehrerer Arten von Protokollen mit der Bezeichnung channels.
- Wird die Option channel in der logging-Anweisung verwendet, wird ein benutzerdefiniertes Protokoll mit eigenem Dateinamen (file), Größenbeschränkung (size), Version (version), und dessen Wichtigkeit (severity) erstellt.
- Nachdem ein benutzerdefinierter Channel festgelegt wurde, wird dieser mit der Option category klassifiziert und beginnt mit dem Protokollieren, wenn named neu gestartet wird.
Standardmäßig protokolliert named normale Mitteilungen im syslog-Daemon, der diese in /var/log/messages platziert. - Dies geschieht, weil sich verschiedene standardmäßige Channel mit unterschiedlicher Wichtigkeit im BIND befinden.
- Zum Beispiel verarbeitet ein Channel die Protokoll-Mitteilungen (default_syslog) und ein anderer speziell Debugging-Mitteilungen (default_debug).
- Die standardmäßige Kategorie default, verwendet zum normalen Protokollieren, ohne spezielle Konfigurationen, integrierte Channel.
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 Abschnitt 12.7.1.
- server — Definiert bestimmte Optionen, die Auswirkungen darauf haben, wie named sich gegenüber Remote-Name-Servern verhalten soll, insbesondere im Hinblick auf Benachrichtigungen und Zone-Übertragungen.
Die Option transfer-format kontrolliert, ob mit jeder Mitteilung ein Resource-Record (one-answer) oder mehrere Ressource-Records mit jeder Meldung gesendet werden (many-answers). - Da many-answers leistungsfähiger ist, wird es nur von neueren Name-Servern angenommen.
- trusted-keys — Enthält verschiedene öffentliche Schlüssel für die Verwendung mit Secure DNS (DNSSEC).
- Unter Abschnitt 12.5.3 finden Sie eine Einführung in die BIND-Sicherheit.
- view "<view-name>" — 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.
Es können auch mehrere Ansichten verwendet werden, solange ihre Namen eindeutig sind. - Die match-clients-Option legt die IP-Adressen fest, die für eine bestimmte Ansicht verwendet werden.
- Alle option-Direktiven können in einer Ansicht verwendet werden.
- Sie überschreiben dabei die allgemeinen, bereits für named konfigurierten Optionen.
- Die meisten view-Direktiven enthalten mehrere zone-Anweisungen, die für die match-clients-Liste gelten.
- Es ist wichtig, in welcher Reihenfolge die view-Anweisungen aufgelistet sind, da die erste view-Direktive, die mit einer bestimmten IP-Adresse des Client übereinstimmt, verwendet wird.
Unter Abschnitt 12.5.2 finden Sie weitere Informationen zum view-Statement.
Kommentar-Tags
Die Folgende ist eine Liste gültiger, in named.conf verwendeter, Kommentar-Tags:
- // — Wenn an den Anfang der Zeile gestellt, wird diese Zeile von named ignoriert.
- # — Wenn an den Anfang der Zeile gestellt, wird diese Zeile von named ignoriert.
- /* und */ — Hierin eingeschlossener Text wird von named ignoriert.
Zone-Dateien
Zone-Dateien sind im named-Arbeitsverzeichnis, /var/named/, gespeichert und enthalten Informationen über einen bestimmten Namespace.
- Jede Zone-Datei ist gemäß der Daten der file-Option in der zone-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. example.com.zone.
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 (;) platziert werden.
Zone-Dateien-Direktiven
Anweisungen werden durch das vorangestellte Dollarzeichen $ identifiziert, das vor dem Namen der Anweisung üblicherweise im oberen Teil der Zone-Datei steht.
Folgende Anweisungen werden am häufigsten verwendet:
- $INCLUDE — Weist named 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.
- $ORIGIN — 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 (.) enden, wird example.com angehängt.
- Anmerkung
- Die Verwendung der $ORIGIN-Direktive ist nicht erforderlich, wenn der Name der Zone in /etc/named.conf mit dem Wert übereinstimmt, den Sie $ORIGIN zuweisen würden.
- Standardmäßig wird der Name der Zone als Wert der $ORIGIN-Anweisung verwendet.
- $TTL — 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:
- A — Adressen-Record, das einem Namen eine IP-Adresse zuweist.
- Beispiel:
<host> IN A <IP-address>Wenn der <host>-Wert nicht angegeben wird, verweist ein A-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 A-Record-Beispiel für die example.com Zone-Datei:
IN A 10.0.1.3 server1 IN A 10.0.1.5Anfragen für example.com richten sich an 10.0.1.3, während Anfragen für server1.example.com sich an 10.0.1.5 richten. * CNAME — Name-Record, welcher Namen untereinander zuordnet.
- Dieser Typ ist auch als Alias bekannt.
Im nächsten Beispiel wird named angewiesen, dass alle Anfragen, die an den <alias-name> gesendet werden, auf den Host <real-name> zeigen. CNAME-Records werden am häufigsten verwendet, um auf Dienste zu verweisen, die ein allgemeines Namensschema für den korrekten Host, wie www für Web-Server, verwenden.
- server1 IN A 10.0.1.5
www IN CNAME server1* MX — 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 <preference-value>, 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 MX-Resource-Record mit dem niedrigsten <preference-value> 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 <email-server-name> 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 mail.example.com-E-Mail-Server vor dem mail2.example.com-E-Mail-Server bevorzugt, wenn eine E-Mail für die Domain example.com ankommt. * NS — Name-Server-Record, der die maßgeblichen Name-Server für eine bestimmte Zone anzeigt.
Beispiel für einen NS-Record:
IN NS <nameserver-name>Der <nameserver-name> 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.* PTR — PoinTeR-Record verweist auf einen anderen Teil des Namespace.
PTR-Records werden primär für eine umgekehrte Namensauflösung verwendet, da diese IP-Adressen zu einem bestimmten Namen verweisen.
- Unter Abschnitt 12.3.4 finden Sie weitere Beispiele von PTR-Records in Verwendung. * SOA — Start Of Authority-Record, gibt wichtige maßgebliche Informationen über den Namespace an den Name-Server.
Nach den Direktiven festgelegt ist ein SOA-Resource-Record, der erste Resource-Record in einer Zone-Datei.
Das folgende Beispiel zeigt die Basisstruktur eines SOA-Resource-Record:
@ IN SOA <primary-name-server> <hostmaster-email> ( <serial-number> <time-to-refresh> <time-to-retry> <time-to-expire> <minimum-TTL> )
Das @-Symbol richtet die $ORIGIN-Anweisung (oder den Namen der Zone, falls die $ORIGIN-Direktive nicht eingestellt ist) als Namespace ein, das von diesem SOA-Resource-Record eingestellt wurde.
- Als <primary-Nameserver> 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 <hostmaster-email> ersetzt.
Die <serial-number> wird bei jeder Änderung der Zone-Datei erhöht, so dass named erkennt, dass diese Zone neu geladen werden kann.
- Die <time-to-refresh> 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 <serial-number> wird vom Slave-Server verwendet, um festzustellen, ob veraltete Daten der Zone verwendet werden, die aktualisiert werden sollten.
Die <time-to-retry> 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 <time-to-expire> abläuft, reagiert der Slave-Nameserver nicht mehr auf Anfragen bezüglich des Namespaces.
<minimum-TTL> 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 (M), Stunden (H), Tage (D) und Wochen (W).
- In der Tabelle unter Tabelle 12-1 finden Sie Zeiträume in Sekunden und die entsprechende Zeit in anderen Formaten.
Sekunden | Andere Zeiteinheiten |
---|---|
60 | 1M |
1800 | 30M |
3600 | 1H |
10800 | 3H |
21600 | 6H |
43200 | 12H |
86400 | 1D |
259200 | 3D |
604800 | 1W |
31536000 | 365D |
- Sekunden im Vergleich zu anderen Zeiteinheiten
Das folgende Beispiel zeigt Ihnen, wie ein SOA-Resource-Record aussehen könnte, wenn es mit echten Werten konfiguriert ist.
@ IN SOA dns1.example.com. hostmaster.example.com. ( 2001062501 ; serial 21600 ; refresh after 6 hours 3600 ; retry after 1 hour 604800 ; expire after 1 week 86400 ) ; minimum TTL of 1 day
Beispiele für Zone-Dateien
Einzeln betrachtet könnten die Anweisungen und Resource-Records schwer zu verstehen sein.
- Sind beide in einer gemeinsamen Datei plaziert, wird es einfacher.
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 ; refresh after 6 hours 3600 ; retry after 1 hour 604800 ; expire after 1 week 86 400 ) ; minimum TTL of 1 day 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 SOA-Werte verwendet
- Die maßgeblichen Name-Server sind dabei als dns1.example.com und dns2.example.com eingestellt, die über A-Records verfügen, wodurch sie mit 10.0.1.2 bzw. 10.0.1.3 verbunden sind.
- Die mit MX-Records konfigurierten E-Mail-Server verweisen auf server1 und server2 über CNAME- Records.
- Da die server1- und server2-Namen nicht mit einem Punkt enden (.), wird die $ORIGIN-Domain nach ihnen abgelegt, wobei sie zu server1.domain.com und server2.domain.com erweitert werden.
- Mit den dazugehörigen A-Resource-Records können dann ihre IP-Adressen bestimmt werden.
- Die beliebten FTP- und Web-Dienste, die unter den standardmäßigen Namen ftp.domain.com und www.domain.com zur Verfügung stehen, verweisen auf Rechner, die entsprechende Dienste für die Namen bieten, die CNAME-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 PTR-Resource-Records zur Verknüpfung der IP-Adressen mit gültigen Domain-Namen verwendet werden.
Ein PTR-Record sieht Folgendem ähnlich:
<last-IP-digit> IN PTR <FQDN-of-system>
Die <last-IP-digit>ist die letzte Nummer in einer IP-Adresse, mit der auf die FQDN eines bestimmtenSystems hingewiesen wird.
Im folgenden Beispiel werden die IP-Adressen 10.0.1.20 durch 10.0.1.25 den korrespondierenden FQDN zugewiesen.
$ORIGIN 1.0.10.in-addr.arpa. $TTL 86400 @ IN SOA dns1.example.com. hostmaster.example.com. ( 2001062501 ; serial 21600 ; refresh after 6 hours 3600 ; retry after 1 hour 604800 ; expire after 1 week 86400 ) ; minimum TTL of 1 day 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 zone-Anweisung in der named.conf-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 zone-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 .in-addr.arpa 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.
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 named.
- 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 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 Abschnitt 12.7.1 finden Sie mehr Informationen.
Mehrere Ansichten
Durch Verwendung der view-Anweisung in named.conf, 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 view-Anweisung verwendet die match-clients-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.
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.
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.
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.
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 A6 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 lwresd Lightweight-Resolver-Daemon in Ihren Netzwerk-Clients verwenden.
- Dieser Daemon ist ein sehr effektiver Caching-Only-Name-Server, der die neuesten A6- und DNAME-Records versteht, die mit Ipv6 verwendet werden.
- Auf der lwresd-man-Seite finden Sie weitere Informationen hierzu.
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
- 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 — 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.