Berkeley Internet Name Domain/etc/named.conf

/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 beispielsweise
• 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 beispielsweise
• sichere Updates oder die Verwendung des rndc-Befehls.

Mit key werden zwei Optionen verwendet:

• algorithm <algorithm-name> — Der verwendete Algorithmus-Typ, beispielsweise 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.