Berkeley Internet Name Domain (BIND): Unterschied zwischen den Versionen
Keine Bearbeitungszusammenfassung |
|||
| Zeile 2.290: | Zeile 2.290: | ||
* DNS & BIND Cookbook - Cricket Liu - 4th Edition - [http://www.oreilly.com/ "O'Reilly Press"][http://www.oreilly.com/ http://www.oreilly.com/] | * DNS & BIND Cookbook - Cricket Liu - 4th Edition - [http://www.oreilly.com/ "O'Reilly Press"][http://www.oreilly.com/ http://www.oreilly.com/] | ||
== Controls clause == | === Controls clause === | ||
This section describes the controls clause in BIND 9.x. The controls clause is used to define access information and controls when using remote administration services, for example, the rndc utility. The controls clause takes a single '''inet''' statement type, though more than one '''inet''' statement may be defined. [http://www.zytrax.com/books/dns/ch7/statements.html Full list of statements]. | This section describes the controls clause in BIND 9.x. The controls clause is used to define access information and controls when using remote administration services, for example, the rndc utility. The controls clause takes a single '''inet''' statement type, though more than one '''inet''' statement may be defined. [http://www.zytrax.com/books/dns/ch7/statements.html Full list of statements]. | ||
Version vom 6. Februar 2023, 11:07 Uhr
TMP
Berkeley Internet Name Domain (BIND)
Die meisten modernen Netzwerke, einschließlich dem Internet, erlauben dem Benutzer andere Computer über deren Namen zu bestimmen. Dies befreit den Benutzer davon, die numerische Netzwerk-Adresse behalten zu müssen. Der effektivste Weg ein Netzwerk zu konfigurieren, sodass es namensbasierte Verbindungen zulässt, ist durch das Einrichten eines Domain Name Service (DNS) oder Nameserver, welcher Rechnernamen in numerische Adressen auflöst und umgekehrt.
Dieses Kapitel stellt den in Red Hat Enterprise Linux enthaltenen Nameserver vor, den Berkeley Internet Name Domain (BIND) DNS Server, mit dem Fokus auf die Struktur dessen Konfigurationsdateien und der Art und Weise, wie dieser lokal und auch remote verwaltet werden kann.
- 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:
- Master — Speichert die ursprünglichen und maßgeblichen Zonen für einen bestimmten Namespace, und beantwortet Fragen von anderen Nameservern, die nach Antworten für diesen Namespace suchen.
- Slave — Beantwortet ebenfalls die Anfragen anderer Nameserver bezüglich des Namespace, für den dieser die Autorität darstellt. Die Slave-Nameserver erhalten ihre Informationen über ein Namespace jedoch von Master-Nameservern.
- Caching-Only — Bietet Dienste für IP-Auflösungen, hat aber nicht für alle Zonen eine Berechtigung. Antworten für alle Auflösungen werden üblicherweise für eine bestimmte Zeit im Speicher gecachet, welche von dem abgefragten Zone-Record festgelegt wird.
- Forwarding — Leitet Anfragen zum Auflösen an eine spezielle Liste von Nameservern weiter. Wenn keiner der angegebenen Nameserver den Auflösungsprozess durchführen kann, wird der Vorgang abgebrochen und die Auflösung schlägt fehl.
Ein Nameserver kann einem oder mehreren dieser Typen zugehören. Zum Beispiel kann ein Nameserver für einige Zonen der Master und für andere Zonen der Slave sein und für andere ausschließlich Auflösungen weiterleiten.
BIND als Nameserver
BIND führt Namensauflösungsdienste mittles /usr/sbin/named Daemon durch. BIND enthält auch eine administrative Utility, /usr/sbin/rndc genannt.
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 Typen von Statements
Die folgenden Typen von Statements werden häufig in /etc/named.conf verwendet:
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.
Die Verwendung von rndc
BIND enthält das Utility rndc, mit dem Sie den named-Daemon über die Befehlszeile vom lokalen und von einem Remote Host verwalten können.
Um zu verhindern, dass nicht authorisierte Benutzer Zugriff zum named-Daemon erlangen, verwendet BIND eine Authentifizierungsmethode, auf einem gemeinsamen geheimen Schlüssel basierend, um Hostsystemen den Zugriff zu gewähren. Das heisst, das ein übereinstimmender Schlüssel in /etc/named.conf und der rndc Konfigurationsdatei /etc/rndc.conf existieren muss.
Konfigurieren von /etc/named.conf
Um die Verbindung von rndczu Ihrem named-Dienst zu ermöglichen, muss beim Start von named die controls-Anweisung in Ihrer /etc/named.conf-Datei vorhanden sein.
Das folgende Beispiel einer controls-Anweisung ermöglicht es Ihnen, rndc-Befehle vom lokalen Host auszuführen.
Controls {
inet 127.0.0.1 allow { localhost; } keys { <key-name>; };
};
Diese Anweisung weist named an, am standardmäßigen TCP-Port 953 nach Loopback-Adressen zu suchen und lässt rndc-Befehle zu, die vom lokalen Host ausgeführt werden, wenn der richtige Schlüssel angegeben wird. Der <key-name> bezieht sich auf die key-Direktive, die sich auch in der /etc/named.conf-Datei befindet. Im nächsten Beispiel wird eine key-Anweisung veranschaulicht.
key "<key-name>" {
algorithm hmac-md5;
secret "<key-value>";
};
In diesem Beispiel benutzt <key-value> einen HMAC-MD5-Algorithmus. Mit dem nachfolgenden Befehl können Sie Ihre eigenen Schlüssel unter Verwendung eines HMAC-MD5-Algorithmus erstellen:
dnssec-keygen -a hmac-md5 -b <bit-length> -n HOST <key-file-name>
Es empfiehlt sich, einen Schlüssel mit einer Größe von mindestens 256 Bit zu erstellen. Der Schlüssel, der im <key-value>-Bereich gespeichert werden sollte, kann in der Datei <key-file-name>, welche von diesem Befehl erzeugt wurde, gefunden werden.
- Warnung
- Da /etc/named.conf von jedem gelesen werden kann, ist es angeraten, das key-Statement in eine separate Datei auszulagern, welche nur von root gelesen werden kann und ein include-Statement zu verwenden, um diese Datei einzubinden. Zum Beispiel:
include "/etc/rndc.key";
Konfigurieren von /etc/rndc.conf
Die key-Anweisung ist die wichtigste in der Datei /etc/rndc.conf.
key "<key-name>" {
algorithm hmac-md5;
secret "<key-value>";
};
<key-name> und <key-value> sollten exakt mit den Einstellungen in /etc/named.conf übereinstimmen.
Um den Schlüsseln, welche in /etc/named.conf auf dem Ziel-Server angegeben sind, zu entsprechen, fügen Sie folgende Zeilen zu /etc/rndc.conf hinzu.
Options {
default-server localhost;
default-key "<key-name>";
};
Diese Anweisung setzt den globalen Default-Schlüssel. Dierndc Konfigurationsdatei kann allerdings auch verschiedene Schlüssel für verschiedene Server verwenden, wie im folgenden Beispiel gezeigt:
server localhost {
key "<key-name>";
};
- Achtung
- Stellen Sie sicher, dass jeweils nur ein root-Benutzer auf die Datei /etc/rndc.conf zugreifen kann.
Für weitere Informationen zur Datei /etc/rndc.conf, siehe die rndc.conf man-Seiten.
Befehlszeilenoptionen
Ein rndc-Befehl sieht wie folgt aus:
rndc <options> <command> <command-options>
Wenn rndc auf einem korrekt konfigurierten lokalen Host ausgeführt wird, stehen Ihnen folgende Befehle zur Verfügung:
- halt — Hält den named-Service sofort an.
- querylog — Protokolliert alle Abfragen, die von Clients auf diesem Name-Server durchgeführt wurden.
- refresh — Aktualisiert die Datenbank des Nameservers.
- reload — Weist den Name-Server an, die Zone-Dateien neu zu laden, aber alle vorher verarbeiteten Antworten zu behalten. Dadurch können Sie Änderungen in den Zone-Dateien durchführen, ohne dass die gespeicherten Auflösungen von Namen verloren gehen.
- Wenn sich Ihre Änderungen nur auf eine bestimmte Zone auswirken, können Sie lediglich diese Zone neu laden. Geben Sie hierzu nach dem reload-Befehl den Namen der Zone ein.
- stats — Schreibt die aktuellen named-Statistiken in die Datei /var/named/named.stats.
- stop — Stoppt den Server vorsichtig, und speichert dabei alle dynamischen Updates und die vorhandenen Incremental Zone Transfers (IXFR) Daten, vor dem Beenden.
Gelegentlich werden Sie bestimmt auch die Standardeinstellungen in der /etc/rndc.conf-Datei übergehen wollen. Hierzu stehen Ihnen folgende Optionen zur Verfügung:
- -c <configuration-file> — Gibt einen alternativen Speicherort der Konfigurationsdatei an.
- -p <port-number> — Legt für die rndc-Verbindung eine andere als die standardmäßige Portnummer 953 fest.
- -s <server> — Ermöglicht es Ihnen, einen anderen als den default-server in /etc/rndc.conf anzugeben.
- -y <key-name> — Ermöglicht es Ihnen, einen anderen als den default-key in der /etc/rndc.conf-Datei einzustellen.
Zusätzliche Informationen zu diesen Optionen finden Sie auf der rndc-man-Seite
Erweiterte Funktionen von BIND
Die meisten BIND-Implementierungen verwenden für die Dienste zur Auflösung von Namen oder als Autorität für bestimmte Domains oder Sub-Domains nur 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.
Allgemein zu vermeidende Fehler
Es kommt häufig vor, dass Anfänger bei der Bearbeitung der Konfigurationsdateien von BIND Fehler machen oder bei der Verwendung von named zunächst Schwierigkeiten haben. Viele der nachfolgend beschriebenen Probleme können Sie aber vermeiden, wenn Sie Folgendes beachten:
- Erhöhen Sie die Seriennummer, wenn Sie eine Zone-Datei bearbeiten.
Wenn die Seriennummer nicht erhöht wird, hat Ihr Master-Name-Server zwar die korrekten neuen Informationen, Ihr Slave-Name-Server werden jedoch nie über diese Änderungen oder den Versuch informiert, die Daten in der Zone zu aktualisieren. - Achten Sie darauf, dass Sie geschweifte Klammern und Strichpunkte in der /etc/named.conf-Datei richtig verwenden.
Ein ausgelassenes Semikolon oder eine nicht geschlossene geschweifte Klammer kann dazu führen, dass named nicht startet. - Denken Sie daran, in den Zone-Dateien nach jedem FQDN Punkte (.) zu setzen und sie beim Hostnamen wegzulassen.
Der Punkt bedeutet, dass der angegebene Name komplett ist. Wird er weggelassen, platziert named den Namen der Zone oder des $ORIGIN-Werts hinter den Namen, um ihn zu vervollständigen. - Wenn Ihre Firewall Verbindungen von Ihrem named zu anderen Nameservern blockiert, müssen Sie möglicherweise die Konfigurationsdatei bearbeiten.
- Standardmäßig verwendet die Version 9 von BIND willkürliche Ports oberhalb von 1024, um andere Name-Server abzufragen. Einige Firewalls gehen jedoch von Name-Servern aus, die für die Kommunikation nur den Port 53 verwenden. Um die Verwendung des Port 53 durch named zu erzwingen, fügen Sie in /etc/named.conf folgende Zeile zur options-Direktive hinzu:
query-source address * port 53;
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.
Hilfreiche Webseiten
- 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.
Bücher zum Thema
- Red Hat Enterprise Linux Handbuch zur System-Administration — Das Kapitel BIND-Konfiguration erklärt wie man mit Hilfe desDomain Name Service Configuration Tool einen DNS-Server einrichten kann.
- DNS and BIND von Paul Albitz und Cricket Liu; O'Reilly & Associates — Ein bekanntes Buch, das allgemeine und weiterführende Optionen der Konfiguration von BIND erklärt und Strategien zum Schutz Ihres DNS-Servers vorstellt.
- The Concise Guide to DNS and BIND von Nicolai Langfeldt; Que — Beschreibt die Verbindungen zwischen mehreren Netzwerkdiensten und BIND mit Schwerpunkt auf aufgabenorientierten technischen Themen.
DNS-Server- BIND9
Domain Name Service (DNS) is an Internet service that maps IP addresses and fully qualified domain names (FQDN) to one another. In this way, DNS alleviates the need to remember IP addresses.
Computers that run DNS are called name servers. Ubuntu ships with BIND (Berkley Internet Naming Daemon), the most widely deployed DNS server.
This guide is aimed at people looking to learn how to configure and maintain a DNS server, such as for a network (caching name server) or to serve DNS zones for a domain name.
Installation
BIND9 is available in the Main repository. No additional repository needs to be enabled for BIND9.
Before we begin, you should be familiar with RootSudo.
To install the server simply install the bind9 package. See InstallingSoftware for details on using package managers.
A very useful package for testing and troubleshooting DNS issues is the dnsutils package. Also, the BIND9 Documentation can be found in the bind9-doc package.
Set up DNS nameservers using BIND9
Just go to your linux console and type the following commands.
yum install bind
Create a new zone file for your domain and insert the sample zone file (see below). You have to change domain.com, serial and email parameters.
nano /var/named/domain.com.db
Open /etc/named.conf and place the following lines:
zone "domain.com" {
type master;
file "/var/named/domain.com.com.db";
};
Save changes to the file and restart bind.
service named restart
BIND9 Configuration Scenarios
BIND9 can provide many different DNS services. Some of the most useful setups are:
Caching Server
In this configuration BIND9 will find the answer to name queries and remember the answer for the next query. This can be useful for a slow internet connection. By caching DNS queries, you will reduce bandwidth and (more importantly) latency.
Primary Master Server
BIND9 can be used to serve DNS records (groups of records are referred to as zones) for a registered domain name or an imaginary one (but only if used on a restricted network).
Secondary Master Server
A secondary master DNS server is used to complement a primary master DNS server by serving a copy of the zone(s) configured on the primary server. Secondary servers are recommended in larger setups. If you intend to serve a registered domain name they ensure that your DNS zone is still available even if your primary server is not online.
Hybrids
You can even configure BIND9 to be a Caching and Primary Master DNS server simultaneously, a Caching and a Secondary Master server or even a Caching, Primary Master and Secondary Master server. All that is required is simply combining the different configuration examples.
Stealth Servers
There are also two other common DNS server setups (used when working with zones for registered domain names), Stealth Primary and Stealth Secondary. These are effectively the same as Primary and Secondary DNS servers, but with a slight organizational difference.
For example, you have 3 DNS servers; A, B and C.
A is the Primary, B and C are secondaries.
If you configure your registered domain to use A and B as your domain's DNS servers, then C is a Stealth Secondary. It's still a secondary, but it's not going to be asked about the zone you are serving to the internet from A and B
If you configure your registered domain to use B and C as your domain's DNS servers, then A is a stealth primary. Any additional records or edits to the zone are done on A, but computers on the internet will only ever ask B and C about the zone.
DNS Record Types
There are lots of different DNS record types, but some of the most common types are covered below.
IP Address Records
The most commonly used type of record. This record maps an IP Address to a hostname.
www IN A 1.2.3.4
Alias Records
Used to create an alias from an existing A record. You can create a CNAME record pointing to another CNAME record. But it doubles the number of requests made to the nameserver, thus making it an inefficient way to do so.
mail IN CNAME www www IN A 1.2.3.4
Mail Exchange Records
Used to define where email should be sent to and at what priority. Must point to an A record, not a CNAME. Multiple MX records can exist if multiple mail servers are responsible for that domain.
IN MX 10 mail.example.com.
[…]
mail IN A 1.2.3.4
Name Server
Used to define which servers serve copies of this zone. It must point to an A record, not a CNAME.
This is where Primary and Secondary servers are defined. Stealth servers are intentionally omitted.
IN NS ns.example.com.
[…]
ns IN A 1.2.3.4
DNS Zonendatei
Sample DNS Zone File for BIND
Use this file to set up your domains and nameservers in BIND9:
;================================================================= ;SAMPLE BIND DNS Zone FILE ;for ANY Domain (Just change domain.com to your site) ;================================================================ ; Before you start DONT FORGET THE DOT AND SERIAL INCREMENT $TTL 14400 $ORIGIN domain.com. ; SOA Record ; Specify Primary nameserver ns1.domain.com ; Serial should increment every update @ 14400 IN SOA ns1.domain.com. webmaster.domain.com. ( 2009092902 ; Serial in YYYYMMDDXX (XX is increment) 10800; refresh seconds 3600; retry 604800; expire 38400; minimum ); ; Website IP Address specified in A record IN A xx.xx.xx.xx ; Minimum 2 DNS nameserver names IN NS ns1.domain.com. IN NS ns2.domain.com. ; Mapping all Nameservers and their corresponding IPs (GLUE)
ns1 IN A xx.xx.xx.xx ns2 IN A xx.xx.xx.xx
; Specify any subdomains and www entry here using CNAME record
www IN CNAME domain.com. ftp IN CNAME domain.com. server IN CNAME domain.com. webmail IN CNAME domain.com.
; Setup MX record (mail exchanger with priority) domain.com. IN MX 10 mail.domain.com.
; set A record for mail mail IN A xx.xx.xx.xx;=====================================
Beispiel: Robot Standard-Template
Nachfolgende Zonendatei wurde für die Domain "grossefirma.de" erstellt:
$TTL 86400
@ IN SOA ns1.first-ns.de. postmaster.robot.first-ns.de. (
2000091604 ; Serial
14400 ; Refresh
1800 ; Retry
604800 ; Expire
86400 ) ; Minimum
@ IN NS ns1.first-ns.de. @ IN NS robotns2.second-ns.de. @ IN NS robotns3.second-ns.com.
localhost IN A 127.0.0.1 @ IN A 1.2.3.4 www IN A 2.3.4.5 mail IN A 2.3.4.5
loopback IN CNAME localhost pop IN CNAME www smtp IN CNAME www relay IN CNAME www imap IN CNAME www ftp 3600 IN CNAME ftp.anderedomain.de.
@ IN MX 10 mail
technik IN A 5.6.7.8 technik IN MX 10 technik
@ IN TXT "v=spf1 mx -all"
SOA-Record
$TTL 86400
@ IN SOA ns1.first-ns.de. postmaster.robot.first-ns.de. (
2000091604 ; Serial
14400 ; Refresh
1800 ; Retry
604800 ; Expire
86400 ) ; Minimum* Die TTL (Time To Live) der Zone beträgt 86400 Sekunden ($TTL 86400)
- Für die Internet-Domäne (das Zeichen @ ist Platzhalter für die Domäne "grossefirma.de" selbst) ist der Nameserver "ns1.first-ns.de" zuständig
- Der Punkt am Ende von "ns1.first-ns.de." verhindert, dass der primäre Nameserver "ns1.first-ns.de.grossefirma.de" genannt wird
- Der Administrator hat die E-Mailadresse "postmaster@robot.first-ns.de" (der erste Punkt wird immer durch das @-Zeichen ersetzt)
- Die Zonendatei wurde zuletzt am 16.09.2000 geändert, dies war die 4. Änderung an jenem Tag
- Der sekundäre Nameserver übernimmt alle 4 Stunden (TTL = 14.400 Sekunden; Time To Live) Änderungen vom primären Nameserver
- Im Fehlerfall versucht der sekundäre Nameserver den Abgleich nach 30 Minuten (1800 Sekunden) erneut
- Sollte der sekundäre Nameserver nach 7 Tagen (604800 Sekunden) keinen Abgleich mit dem primären Nameserver geschafft haben, erklärt er die Domain für ungültig
- Die Einträge sind normalerweise 24 Stunden (86400 Sekunden) gültig, falls kein anderer Wert definiert wird
- Andere Nameserver merken sich "negative" Antworten, also Anfragen nach nicht existierenden Hosts ebenfalls 24 Stunden
Nameserver
@ IN NS ns1.first-ns.de.
@ IN NS robotns2.second-ns.de. @ IN NS robotns3.second-ns.com.* Zuständig für die Nameserver sind "ns1.first-ns.de", "robotns2.second-ns.de" und "robotns3.second-ns.com"
- Der Punkt am Ende der Zeilen verhindert auch hier die Suche nach "ns1.first-ns.de.grossefirma.de", was in diesem Fall unsinnig wäre
- IP-Adressen sind in NS-Records nicht erlaubt (wird ein eigener Nameserver verwendet, dessen Hostname "ns1.grossefirma.de" lauten soll: Zusätzlich passenden A-Record definieren und Glue bei der Domainregistation angeben bzw. die Nameserver vorher bei den Registraren registrieren).
Hosts
localhost IN A 127.0.0.1 @ IN A 1.2.3.4 www IN A 2.3.4.5 mail IN A 2.3.4.5* "localhost.grossefirma.de" wird zur Loopback-Adresse "127.0.0.1" aufgelöst
- Anfagen z.B. im Webbrowser nach "grossefirma.de" (ohne "www.") werden nach "1.2.3.4" aufgelöst
- "www.grossefirma.de" hat die IP-Adresse "2.3.4.5"
- Es existiert ein Host mit dem Namen "mail.grossefirma.de", aber ob dieser auch der zuständige Mailserver ist, geht aus diesem Eintrag nicht hervor
Aliase
loopback IN CNAME localhost pop IN CNAME www smtp IN CNAME www relay IN CNAME www imap IN CNAME www ftp 3600 IN CNAME ftp.anderedomain.de.* "localhost.grossefirma.de" kann auch als "loopback.grossefirma.de" angesteuert werden
- "www.grossefirma.de" hat die zusätzlichen Namen "pop.grossefirma.de", "smtp.grossefirma.de", "relay.grossefirma.de" und "imap.grossefirma.de"
- "ftp.grossefirma.de" wird weitergeleitet zu "ftp.anderedomain.de", da der Punkt am Ende die Auflösung nach "ftp.anderedomain.de.grossefirma.de" verhindert
- "ftp.grossefirma.de" hat eine Gültigkeit von nur 1 Stunde (3600 Sekunden), daher sind Änderungen in den Einträgen relativ schnell bei den Nameservern im weltweiten Internet bekannt. Wichtig: solange der sekundäre Nameserver noch die veralteten Werte publiziert, verzögert sich eine eventuelle Änderung der Daten, daher sollte evtl. auch die Refresh-Zeit im SOA-Record verkürzt werden
Hinweis: Ist für eine Subdomain bereits ein CNAME-Record definiert, können für diese Subdomain keine weiteren Record-Typen gesetzt werden.
Mailserver
@ IN MX 10 mail* Es gibt nur einen Mailserver und das ist "mail.grossefirma.de"
- IP-Adressen sind bei MX-Records nicht erlaubt
- CNAME's sind in MX-Records nicht erlaubt, nur Verweise auf A-Records
- Weitere Mailserver könnten in eine zusätzliche Zeile eingetragen werden, dies ist aber oft nicht sinnvoll
- Bei mehreren Mailservern würde der mit der geringeren Priorität (hier 10) bevorzugt verwendet
"Subdomain"
technik IN A 5.6.7.8
technik IN MX 10 technik* Es ist innerhalb der Zonendatei eine "Subdomain" angelegt, allerdings ohne Delegation an einen externen Nameserver.
- Für die Subdomain "technik.grossefirma.de" ist der Host "technik.grossefirma.de" zuständig, der zur IP-Adresse 5.6.7.8 auflöst.
TXT records
@ IN TXT "v=spf1 mx -all"* Für "grossefirma.de" existiert ein TXT record mit dem Inhalt "v=spf1 mx -all"
- Nutzung beispielsweise für SPF (Sender Policy Framework)
Delegation einer Subdomain
Alternativ zum unter "Subdomain" beschriebenen Vorgehen, ist eine Delegation von Subdomains an einen anderen DNS-Server möglich.
Hinweis: Im Robot ist es nicht möglich, DNS-Zonen für Subdomains anzulegen! Hier können Subdomains nur wie im Abschnitt "Subdomain" beschrieben definiert werden.
Beispiel: Zu Testzwecken soll eine Subdomain für die Abteilung "Technik" einer großen Firma angelegt werden, die dann für kurzfristige interne Tests etc. verwendet werden kann. Die DNS-Einträge der Subdomain sollen unabhängig von den Einträgen der Domäne "grossefirma.de" verwaltet werden (die evtl. ein grosser und unflexibler Provider hostet).
Vorbereiten der Haupt-Domain
In der Zonendatei der Domain "grossefirma.de" werden folgende Einträge ergänzt:
technik IN NS ns.technik
ns.technik IN A 5.6.7.8
Hier werden Nameserveranfragen nach beispielsweise "www.technik.grossefirma.de" an "ns.technik.grossefirma.de" weitergeleitet. Da dieser Hostname ja selbst von eben diesem Nameserver aufgelöst werden müsste, wird in der übergeordneten Domain ein "Glue-Record" eingetragen: ns.technik.grossefirma.de --> 5.6.7.8.
Zonendatei für die neue Subdomain
Am neuen Nameserver muss nun noch eine Zonendatei für die neue Subdomain angelegt werden:
@ 86400 IN SOA ns1 admin (
2000091604 ; Serial
14400 ; Refresh
1800 ; Retry
604800 ; Expire
86400 ) ; Minimum
@ IN NS ns.technik ns IN A 5.6.7.8
@ IN MX 10 mail mail IN A 2.3.4.5
www IN A 2.3.4.5
Der Administrator hat die Mailadresse "admin@technik.grossefirma.de". * Der primäre Nameserver hat den Hostnamen "ns.technik.grossefirma.de".
- Es ist der einzige Nameserver (kein sekundärer Nameserver vorhanden).
- Er hat die IP-Adresse "5.6.7.8".
- Ein Host namens "mail.technik.grossefirma.de" mit der IP-Adresse "2.3.4.5" existiert und ist gleichzeitig zuständig für den Mailempfang der Subdomain.
- Es gibt einen weiteren Host mit Namen "www.technik.grossefirma.de", der zu "2.3.4.5" auflöst.
SOA Resource Record
SOA bedeutet Start of Authority (dt. Beginn der Zuständigkeit) und ist wichtiger Bestandteil einer Zonendatei im Domain Name System (DNS). Ein SOA-Record enthält wichtige Angaben zur Verwaltung der Zone, insbesondere zum Zonentransfer. Spezifiziert ist der SOA-Typ in RFC 1035.
Hintergrund
Üblicherweise werden DNS-Nameserver in Clustern aufgebaut. Der Datenbestand innerhalb eines Clusters wird mittels Zonentransfers synchronisiert. Der SOA-Eintrag in der Zonendatei (also in der Datei zur vollständigen Konfiguration und Beschreibung der Zone) enthält Daten, mit denen der Zonentransfer gesteuert wird. Es handelt sich dabei um die Seriennummer und verschiedene Timer.
Außerdem sind die E-Mail-Adresse des Verantwortlichen für diese Zone sowie der Name des primary Master-Servers aufgeführt. Normalerweise steht ein SOA-Record am Anfang der Datei. Eine Zone ohne diesen Eintrag erfüllt nicht den DNS-Standard und kann nicht transferiert werden.
Aufbau
Name
der Zone
IN
Zonenklasse (meist IN für Internet)
SOA
Kürzel für Start Of Authority
Primary
Primary Master für diese Zone, hat in der Praxis nur geringe Bedeutung:
- er definiert, an wen dynamische Updates gesendet werden sollen (siehe: Dynamisches Update)
- er gibt an, an wen keine Notifies gesendet werden (siehe: Zonentransfer)
Mail-Adresse
des Verantwortlichen für diese Zone. (Das @ wird durch . ersetzt. Punkte vor dem @ werden durch \. ersetzt; beispielsweise max\.mustermann.wikipedia.org für die E-Mail-Adresse max.mustermann@wikipedia.org)
Seriennummer
wird bei jeder Änderung inkrementiert (vorzugsweise JJJJMMTTVV; dient als Hinweis, wann die Zone zuletzt aktualisiert wurde[1])
Refresh
Sekundenabstand, in dem sekundäre Nameserver die Seriennummer vom primären Master abfragen sollen, um Änderungen der Zone festzustellen.[2] Empfehlung vom RIPE NCC für kleine und stabile Zonen: 86400 ≙ 24 Stunden.[1]
Retry
Sekundenabstand, in dem bei ausbleibender Antwort des Masters sekundäre Nameserver nochmals seine Seriennummer abfragen sollen. Dieser Wert muss kleiner als jener zum Refresh sein. Empfehlung vom RIPE NCC für kleine und stabile Zonen: 7200 ≙ 2 Stunden.[1]
Expire
Sekundenabstand, nach dem bei ausbleibender Antwort des Masters sekundäre Nameserver keine Antworten über die Zone mehr geben sollen. Dieser Wert muss größer als die Summe jener zum Refresh und Retry sein. Empfehlung vom RIPE NCC für kleine und stabile Zonen: 3600000 ≙ 1000 Stunden.[1]
TTL
Time to Live für Negatives Caching (Empfehlung vom RIPE NCC für kleine und stabile Zonen: 172800 ≙ 2 Tage[1]). Ursprünglich hatte dieses Feld die Bedeutung eines Minimum-TTL-Werts für alle Resource Records der Zone[3] und wurde in der Praxis als Standardwert verwendet, wenn bei einem Resource Record kein TTL-Wert angegeben war; diese Bedeutung wurde mit RFC 2308 abgeschafft.[4]
Beispiel eines SOA-Records in BIND
@ IN SOA master.example.com. hostmaster.example.com. (
2014031700 ; serial
3600 ; refresh
1800 ; retry
604800 ; expire
600 ) ; ttl
In diesem Beispiel wird festgelegt, dass sich ein Slave alle 3600 Sekunden mit seinem Master per Zonentransfer synchronisiert. Ist sein Master nicht erreichbar, wird alle 1800 Sekunden ein neuer Versuch gestartet. Kann der Master innerhalb von 604800 Sekunden (einer Woche) nicht kontaktiert werden, so erklärt der Slave die Zone example.com als inaktiv und beantwortet keine diesbezüglichen DNS-Requests mehr. DNS cached auch fehlgeschlagene Request. Die TTL beträgt 600 Sekunden.
Weiterhin wird definiert, dass der Primary Master dieser Zone master.example.com ist und dass der Administrator über die E-Mail-Adresse hostmaster@example.com erreichbar ist. Das @ muss durch einen . ersetzt werden. Kommt ein . vor dem @, z. B. vorname.nachname@example.com, so wird dieser mit einem \ maskiert – also z. B. vorname\.nachname.example.com.
Die Seriennummer beträgt zur Zeit 2014031700. Bei der nächsten Änderung muss sie (manuell) auf mindestens 2014031701 erhöht werden. Dabei hat sich die Konvention eingebürgert, das Datum in der Form Jahr-Monat-Tag sowie einen nachfolgenden zweistelligen Versionszähler als Seriennummer zu verwenden.
Änderung der Seriennummer
Beim Ändern der Seriennummern haben sich zwei Verfahren etabliert:
- Man beginnt bei 1 und erhöht bei jeder Änderung.
- Man trägt das aktuelle Datum mit einem zweistelligen Zähler (zum Beispiel 2004052101 = 21. Mai 2004, erste Änderung an diesem Tag), seltener auch der Uhrzeit ein. Dieses Vorgehen wird in RFC 1912 2.2 empfohlen.
Einzelnachweise
- Peter Koch: Recommendations for DNS SOA Values. RIPE Network Coordination Centre, 7. Juni 1999, abgerufen am 4. März 2016: „These recommendations are aimed at small and stable DNS zones.“
- RFC 1912 - Common DNS Operational and Configuration Errors. Februar 1996, abgerufen am 4. März 2016.
- RFC 1035 – Domain Names – Implementation and Specification
- RFC 2308 – Negative Caching of DNS Queries (DNS NCACHE)
Recommended DNS SOA record TTL
We currently have our DNS SOA record set to the following for stackoverflow.com:
primary name server = ns1.p19.dynect.net
serial = 2009090909
refresh = 3600 (1 hour)
retry = 600 (10 mins)
expire = 604800 (7 days)
default TTL = 60 (1 min)
Are there better choices for our refresh / retry / expire / default TTL for a site like stackoverflow.com which receives close to 1M pageviews per day?
Answers
All of those settings (except for "default TTL") only affect how frequently your domain's secondary DNS servers poll the primary DNS server for updates.
If your zone only changes infrequently (which I believe yours does) then your value for "refresh" is currently a bit on the low side. Typically the primary should send a NOTIFY message to each of the secondaries whenever there's an update at which point the secondaries grab the zone file immediately. These days the "refresh / retry / expire" mechanism is only a backstop to that.
In any event, it's likely that your DNS provider is automatically syncing changes to all of the relevant DNS servers on the fly without using DNS's built-in synchronisation mechanisms so the actual values are probably irrelevant.
Note that the "default TTL" field no longer means what it says. The real default TTL is set (in BIND at least) with the $TTL directive, and that's only used when there isn't an explicit TTL set on each record.
The "default TTL" field's meaning was changed in RFC 2308 and it's actually a hint for negative caching. If your server returns a negative response (e.g. NXDOMAIN or NODATA) it's how long the remote server should wait before trying again.
The current value is a bit on the low side, but there's no harm leaving it as is. It's often ignored anyway. Interestingly, the DNS diagnostic page from the dyn guys (our DNS hosts)..http://dnscog.com/report/stackoverflow.com
Check SOA MINTTL
Your SOA minttl value is 60 seconds, which is lower than the recommended minimum for general DNS use. If you regularly make changes to your DNS zone, or use DNS-based load balancing services, a small value here is OK.
Recommendation
Consider putting value between 1800 and 86400 to your SOA minttl field.
and this on SOA refresh
Check SOA refresh
Your SOA refresh field is 3600 seconds, which is lower than the recommended minimum. Having a low refresh value can result in unnecessary query volume or unexpected behavior, especially if you use a value of 0. If you regularly make changes to your DNS zone, or use DNS-based load balancing services, a smaller value will help to ensure changes propagate as quickly as possible.
Recommendation
Consider putting value between 7200 and 10800 to your SOA refresh field.
Another diagnostic page at http://www.intodns.com/stackoverflow.com doesn't offer any real hints.
Their minttl recommendation is bogus. That field hasn't had that meaning for over a decade. Their explanation of refresh is also suspect. The refresh interval only affects primary -> secondary slaving, and with a small zone like yours this value would cause no problems whatsoever. Furthermore if the DNS provider is using an out-of-band sync mechanism then the actual value is moot. (NB: I do DNS for a living) – Alnitak Sep 29 '09 at 8:46
p.s. if someone actually gave this as their own explanation and recommendation for the values I'd give it a -1 vote. As you're quoting someone else I won't ;-) – Alnitak Sep 29 '09 at 12:56
To clarify, the SOA Minimum TTL field stores the TTL value to be used to cache a negative request - a request made to the zone for some resource which doesn't exist. Their explanation is sort of true but fails to clarify it's only for negative responses. Secondly, the SOA Refresh is never used by normal DNS queries, it's only used in situations where you have secondary (slave) nameservers updating themselves from your primary (master) nameserver. So their explanation of that field is definitely untrue. – thomasrutter Dec 4 '12 at 12:10
Really, there is so much misinformation about what these records mean online that it's hard to find anything that's actually true. In summary, most of the values in the SOA record are meaningless for actual DNS queries, and are intended instead for you to use for your own internal zone transfer mechanism from your primary to secondary nameservers. The exception is the MinTTL but that isn't, as the standards suggest, minimum TTL nor is it a "default" TTL, but instead a suggested TTL for caching negative results. What matters much more are the individual TTLs for records like A and NS. – thomasrutter Jun 21 '14 at 12:47
All those intodns / dnscog / dnsstuff etc type sites just copy the same misinformation from each other. You can tell because a lot of their text is copy-pasted. I've found MXToolbox (mxtoolbox.com/DNSCheck.aspx) to be a more reliable resource. For example, their explanation of the SOA MINTTL value here is accurate - a rare quality. –
SOA TTL recommended >= 3600. SOA refresh recommended >= 14400. SOA retry recommended >= 3600. SOA expire recommended >= 604800. SOA minimum recommended between 300 and 86400.
Configuring BIND9
BIND9 Configuration files are stored in:
/etc/bind/
The main configuration is stored in the following files:
/etc/bind/named.conf
/etc/bind/named.conf.options /etc/bind/named.conf.local
Caching Server configuration
The default configuration is setup to act as a caching server. All that is required is simply adding the IP numbers of your ISP's DNS servers.
Simply uncomment and edit the following in /etc/bind/named.conf.options:
[…]
forwarders {
1.2.3.4;
5.6.7.8;
};
[...]
(where 1.2.3.4 and 5.6.7.8 are the IP numbers of your ISP's DNS servers)
Now restart the bind daemon:
sudo /etc/init.d/bind9 restart
Testing
If you installed the dnsutils package you can test your setup using the dig command:
dig -x 127.0.0.1
If all goes well you should see output similar to:
; <<>> DiG 9.4.1-P1 <<>> -x 127.0.0.1 ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13427 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1
[…]
;; Query time: 1 msec ;; SERVER: 172.18.100.80#53(172.18.100.80) ;; WHEN: Mon Nov 26 23:22:53 2007 ;; MSG SIZE rcvd: 93
The dig command can also be used to query other domains for example:
dig google.com
If you "dig" a domain name multiple times you should see a drastic improvement in the Query time: between the first and second query. This is due to the server caching the query.
Primary Master Server configuration
In this section BIND9 will be configured as the primary master for the domain example.com. Simply replace example.com with your fully qualified domain name.
Zone File
To add a DNS zone to BIND9, turning BIND9 into a Primary Master server, all you have to do is edit named.conf.local:
[…]
zone "example.com" {
type master;
file "/etc/bind/db.example.com";
};
[...]
Now use an existing zone file as a template:
sudo cp /etc/bind/db.local /etc/bind/db.example.com
Edit the new zone file /etc/bind/db.example.com change localhost. to the FQDN of your server, leaving the additional "." at the end. Change 127.0.0.1 to the nameserver's IP Address and root.localhost to a valid email address, but with a "." instead of the "@". also leaving the "." at the end.
Also, create an A record for ns.example.com the name server in this example:
;
; BIND data file for local loopback interface
;
$TTL 604800
@ IN SOA ns.example.com. root.example.com. (
1 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS ns.example.com.
ns IN A 192.168.1.10
;also list other computers box IN A 192.168.1.21
You must increment the serial number every time you make changes to the zone file. If you make multiple changes before restarting BIND9, simply increment the serial once.
Now, you can add DNS records to the bottom of the zone.
Tip: Many people like to use the last date edited as the serial of a zone, such as 2005010100 which is yyyymmddss (where s is serial)
Once you've made a change to the zone file BIND9 will need to be restarted for the changes to take effect:
sudo /etc/init.d/bind9 restart
Reverse Zone File
Now that the zone file is setup and resolving names to IP Adresses a Reverse zone is also required. A Reverse zone allows DNS to convert from an address to a name.
Edit /etc/bind/named.conf.local and add the following:
zone "1.168.192.in-addr.arpa" {
type master;
notify no;
file "/etc/bind/db.192";
};
Note: replace 1.168.192 with the first three octets of whatever private network you are using. Also, name the zone file db.192 in the example appropriately.
Now create the db.192 file:
sudo cp /etc/bind/db.127 /etc/bind/db.192
Next edit /etc/bind/db.192 changing the basically the same options as in /etc/bind/db.example.com:
;
; BIND reverse data file for local loopback interface
;
$TTL 604800
@ IN SOA ns.example.com. root.example.com. (
2 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS ns.
10 IN PTR ns.example.com.
; also list other computers 21 IN PTR box.example.com.
The serial number in the reverse zone needs to be incremented on each changes as well. For each A record you configure in /etc/bind/db.example.com you need to create a PTR record in /etc/bind/db.192.
After creating the reverse zone file restart bind9:
sudo /etc/init.d/bind9 restart
Testing
You should now be able to ping example.com and have it resolve to the host configured above:
ping example.com
You can also use the named-checkzone utility that is part of the bind9 package:
named-checkzone example.com /etc/bind/db.example.com
and
named-checkzone 1.168.192.in-addr.arpa. /etc/bind/db.192
This is a great way to make sure you haven't made any mistakes before restarting bind9.
You can use the dig utility to test the reverse zone as well as the new domain name:
dig 1.168.192.in-addr.arpa. AXFR
You should see output resolving 1.168.192.in-addr.arpa. to your nameserver.
Secondary Master Server configuration
Once a Primary Master has been configured a Secondary Master is needed in order to maintain the availability of the domain should the Primary become unavailable.
First, on the primary master server, the zone transfer needs to be allowed. Add the allow-transfer option to the sample Forward and Reverse zone definition in /etc/bind/named.conf.local:
[…]
zone "example.com" {
type master;
file "/etc/bind/db.example.com";
allow-transfer { @ip_secondary; };
};
[…]
zone "1.168.192.in-addr.arpa" {
type master;
notify no;
file "/etc/bind/db.192";
allow-transfer { @ip_secondary; };
};
[...]
Note: replace @ip_secondary with the actual IP Address of your secondary server.
Next, on the Secondary Master, install the bind9 package the same way as the primary. Then edit the /etc/bind/named.conf.local and add the following declarations for the Forward and Reverse zones:
[…]
zone "example.com" {
type slave;
file "/var/cache/bind/db.example.com";
masters { @ip_master; };
};
[…]
zone "1.168.192.in-addr.arpa" {
type slave;
file "/var/cache/bind/db.192";
masters { @ip_master; };
};
[...]
Note: replace @ip_master with the IP Address of the Primary. The zone file must be in /var/cache/bind/ because, by default, AppArmor only allows write access inside it (this was made specifically for a slave configuration. See AppArmor's configuration in /etc/apparmor.d/usr.sbin.named).
Restart the server, and in /var/log/syslog you should see something similar to:
syslog.5.gz:May 14 23:33:53 smith named[5064]: zone example.com/IN: transferred serial 2006051401 syslog.5.gz:May 14 23:33:53 smith named[5064]: transfer of 'example.com/IN' from 10.0.0.202#53: end of transfer syslog.5.gz:May 14 23:33:35 smith named[5064]: slave zone "1.168.192.in-addr.arpa" (IN) loaded (serial 2006051401)
Note: A zone is only transfered if the Serial Number on the Primary is larger than the one on the Secondary.
Testing
Testing the Secondary Master can be done using the same methods as the Primary. Also, you could shutdown BIND9 on the Primary then try pinging example.com from a host configured to use the Secondary as well as the Primary for name resolution. If all goes well the Secondary should resolve example.com.
Chroot
Chrooting BIND9 is a recommended setup from a security perspective if you don't have AppArmor installed. In a chroot enviroment, BIND9 has access to all the files and hardware devices it needs, but is unable to access anything it should not need. AppArmor is installed by default on recent Ubuntu releases. Unless you've explicitly disabled AppArmor, you might want to read this before you decide to attempt a chrooted bind. If you still want to go forward with it, you'll need this information, which isn't covered in the instructions that follow here.
To chroot BIND9, simply create a chroot enviroment for it and add the additional configuration below
Chroot Enviroment
Create the following directory structure
# mkdir -p /chroot/named $ cd /chroot/named # mkdir -p dev etc/namedb/slave var/run
Set permissions for chroot environment
# chown root:root /chroot # chmod 700 /chroot # chown bind:bind /chroot/named # chmod 700 /chroot/named
Create or move the bind configuration file.
# touch /chroot/named/etc/named.conf
or
# cp /etc/bind/named.conf /chroot/named/etc
Give write permissions to the user bind for /chroot/named/etc/namedb/slave directory.
# chown bind:bind /chroot/named/etc/namedb/slave
This is where the files for all slave zones will be kept. This increases security, by stopping the ability of an attacker to edit any of your master zone files if they do gain access as the bind user. Accordingly, all slave file names in the /chroot/named/etc/named.conf file will need to have directory names that designate the slave directory. An example zone definition is listed below.
zone "my.zone.com." {
type slave;
file "slaves/my.zone.com.dns";
masters {
10.1.1.10;
};
};
Create the devices BIND9 requires
# mknod /chroot/named/dev/null c 1 3 # mknod /chroot/named/dev/random c 1 8
Give the user bind access to the /chroot/named/var/run directory that will be used to strore PID and statistical data.
# chown bind:bind /chroot/named/var/run
BIND9's Configuration
Edit the bind startup options found in /etc/default/bind9. Change the line the reads:
/etc/default/bind9:
OPTIONS="-u bind"
So that it reads
/etc/default/bind9:
OPTIONS="-u bind -t /chroot/named -c /etc/named.conf"
The -t option changes the root directory from which bind operates to be /chroot/named. The -c option tells Bind that the configuration file is located at /etc/named.conf. Remember that this path is relative to the root set by -t.
The named.conf file must also recieve extra options in order to run correctly below is a minimal set of options:
/chroot/named/etc/named.conf:
options {
directory "/etc/namedb";
pid-file "/var/run/named.pid";
statistics-file "/var/run/named.stats";
};
Ubuntu's syslod Daemon Configuration
/etc/init.d/sysklogd:
[…]
SYSLOGD="-u syslog -a /chroot/named/dev/log"
[...]
(Author Note: Check this config)
Restart the syslog server and BIND9
# /etc/init.d/sysklogd restart # /etc/init.d/bind9 restart
At this point you should check /var/log/messages for any errors that may have been thrown by bind.
Starting, Stopping, and Restarting BIND9
Use the following command to start BIND9 :
# /etc/init.d/bind9 start
To stop it, use :
# /etc/init.d/bind9 stop
Finally, to restart it, run
# /etc/init.d/bind9 restart
Status
To check the status of your BIND9 installation:
$ host localhost
or
$ dig @localhost
(where localhost is the system you are setting BIND9 up on. If not localhost, use the appropriate IP number.)
Logging
BIND9 has a wide variety of logging configuration options available. There are two main options to BIND9 logging the channel option configures where logs go, and the category option determines what to log.
If no logging option is configured for the default option is:
logging {
category default { default_syslog; default_debug; };
category unmatched { null; };
};
Next we will configure BIND9 to send debug messages related to DNS queries to a separate file.
Channel Option
First, we need to configure a channel to specify which file to send the messages to. Edit /etc/bind/named.conf.local and add the following:
logging {
channel query.log {
file "/var/log/query.log";
// Set the severity to dynamic to see all the debug messages.
severity dynamic;
};
};
Category Option
Next, configure a category to send all DNS queries to the query file:
logging {
channel query.log {
file "/var/lib/bind/query.log";
// Set the severity to dynamic to see all the debug messages.
severity debug 3;
};
category queries { query.log; };
};
Note: the debug option can be set from 1 to 3. If a level isn't specified level 1 is the default.
Now restart BIND9 for the changes to take affect:
# /etc/init.d/bind9 restart
You should see the file /var/log/query.log fill with BIND9 log information. This is a simple example of the BIND9 logging options available see bind9.net manual for more information.
Slave Name Server
You need to set up another name server for robustness. You can (and probably will eventually) set up more than two authoritative name servers for your zones. Two name servers are the minimum -- if you have only one name server and it goes down, no one can look up domain names.
A second name server splits the load with the first server or handles the whole load if the first server is down. You could set up another primary master name server, but we don't recommend it. Instead, set up a slave name server. You can always change a slave name server into a primary master name server later if you decide to expend the extra effort it takes to run multiple primary master name servers.
How does a server know if it's the primary master or a slave for a zone? The named.conf file tells the name server whether it is the primary master or a slave on a per-zone basis. The NS records don't tell us which server is the primary master for a zone and which servers are slaves -- they only say who the servers are. (Globally, DNS doesn't care; as far as the actual name resolution goes, slave servers are as good as primary master servers.)
What's the difference between a primary master name server and a slave name server? The crucial difference is where the server gets its data. A primary master name server reads its data from zone data files. A slave name server loads its data over the network from another name server. This process is called a zone transfer.
A slave name server is not limited to loading zones from a primary mastername server; it can also load from another slave server.
The big advantage of slave name servers is that you maintain only one set of zone data files for a zone, the ones on the primary master name server. You don't have to worry about synchronizing the files among name servers; the slaves do that for you. The caveat is that a slave does not resynchronize instantly -- it polls to see if its zone data is current. The polling interval is one of those numbers in the SOA record that we haven't explained yet. (BIND Versions 8 and 9 support a mechanism to speed up the distribution of zone data, which we'll describe later.)
A slave name server doesn't need to retrieve all its zone data over the network; the overhead files, db.cache and db.127.0.0, are the same as on a primary master, so keep a local copy on the slave. That means that a slave name server is a primary master for 0.0.127.in-addr.arpa. Well, you could make it a slave for 0.0.127.in-addr.arpa, but that zone's data never changes -- it may as well be a primary master.
Setup
To set up your slave name server, create a directory for the zone data files on the slave name server host (e.g., /var/named ) and copy over the files /etc/named.conf, db.cache, and db.127.0.0 :
# rcp /etc/named.conf host:/etc # rcp db.cache db.127.0.0 host:db-file-directory
You must modify /etc/named.conf on the slave name server host. For BIND 4, change every occurrence of primary to secondary except for the 0.0.127.in-addr.arpa zone. Before the filename on each of these lines, add the IP address of the primary master server you just set up. For example, if the original BIND 4 configuration file line was this:
primary movie.edu db.movie.edu
then the modified line looks like this:
secondary movie.edu 192.249.249.3 db.movie.edu
If the original BIND 8 or 9 configuration file line was:
zone "movie.edu" in {
type master;
file "db.movie.edu";
};
change master to slave and add a masters line with the IP address of the master server:
zone "movie.edu" in {
type slave;
file "bak.movie.edu";
masters { 192.249.249.3; };
};
This tells the name server that it is a slave for the zone movie.edu and that it should track the version of this zone kept on the name server at 192.249.249.3. The slave name server keeps a backup copy of this zone in the local file bak.movie.edu.
For Movie U., we set up our slave name server on wormhole.movie.edu. Recall that the configuration file on terminator.movie.edu (the primary master) looks like this:
directory /var/named
primary movie.edu db.movie.edu primary 249.249.192.in-addr.arpa db.192.249.249 primary 253.253.192.in-addr.arpa db.192.253.253 primary 0.0.127.in-addr.arpa db.127.0.0 cache . db.cache
We copy /etc/named.conf, db.cache, and db.127.0.0 to wormhole.movie.edu, and edit the configuration file as previously described. The BIND 4 configuration file on wormhole.movie.edu now looks like this:
directory /var/named
secondary movie.edu 192.249.249.3 bak.movie.edu secondary 249.249.192.in-addr.arpa 192.249.249.3 bak.192.249.249 secondary 253.253.192.in-addr.arpa 192.249.249.3 bak.192.253.253 primary 0.0.127.in-addr.arpa db.127.0.0 cache . db.cache
The equivalent BIND 8 or 9 configuration file looks like this:
options {
directory "/var/named";
};
zone "movie.edu" in {
type slave;
file "bak.movie.edu";
masters { 192.249.249.3; };
};
zone "249.249.192.in-addr.arpa" in {
type slave;
file "bak.192.249.249";
masters { 192.249.249.3; };
};
zone "253.253.192.in-addr.arpa" in {
type slave;
file "db.192.253.253";
masters { 192.249.249.3; };
};
zone "0.0.127.in-addr.arpa" in {
type master;
file "db.127.0.0";
};
zone "." in {
type hint;
file "db.cache";
};
This causes the name server on wormhole.movie.edu to load movie.edu, 249.249.192.in-addr.arpa, and 253.253.192.in-addr.arpa over the network from the name server at 192.249.249.3 (terminator.movie.edu). It also saves a backup copy of these files in /var/named. You may find it handy to isolate the backup zone data files in a subdirectory. We name them with a unique prefix like bak, since on rare occasions, we may have to delete all of the backup files manually. It's also helpful to be able to tell at a glance that they're backup zone data files so that we're not tempted to edit them. We'll cover more on backup files later.
Now start up the slave name server. Check for error messages in the syslog file as you did for the primary master server. As on the primary master, the command to start up a name server is:
# /usr/sbin/named
One extra check to make on the slave that you didn't have to make on the primary master is to see that the name server created the backup files. Shortly after we started our slave name server on wormhole.movie.edu, we saw bak.movie.edu, bak.192.249.249, and bak.192.253.253 appear in the /var/named directory. This means the slave has successfully loaded these zones from the primary master and saved a backup copy.
To complete setting up your slave name server, try looking up the same domain names you looked up after you started the primary master server. This time, you must run nslookup on the host running the slave name server so that the slave server is queried. If your slave is working fine, add the proper lines to your system startup files so that the slave name server is started when your system boots up and hostname(1) is set to a domain name.
Backup Files
Slave name servers are not required to save a backup copy of the zone data. If there is a backup copy, the slave server reads it on startup and later checks with the master server to see if the master server has a newer copy instead of loading a new copy of the zone immediately. If the master server has a newer copy, the slave pulls it over and saves it in the backup file.
Why save a backup copy? Suppose the master name server is down when the slave starts up. The slave will be unable to transfer the zone and therefore won't function as a name server for that zone until the master server is up. With a backup copy, the slave has zone data, although it might be slightly out of date. Since the slave does not have to rely on the master server always being up, it's a more robust setup.
To run without a backup copy, omit the filename at the end of the secondary lines in the BIND 4 configuration file. In BIND 8 or 9, remove the file line. However, we recommend configuring all your slave name servers to save backup copies. There is very little extra cost to saving a backup zone data file, but there is a very high cost if you get caught without a backup file when you need it most.
SOA Values
Remember this SOA record?
movie.edu. IN SOA terminator.movie.edu. al.robocop.movie.edu. (
1 ; Serial
3h ; Refresh after 3 hours
1h ; Retry after 1 hour
1w ; Expire after 1 week
1h ) ; Negative caching TTL of 1 day
We never explained what the values between the parentheses were for.
The serial number applies to all the data within the zone. We chose to start our serial number at 1, a logical place to start. But many people find it more useful to use the date in the serial number instead, like 1997102301. This format is YYYYMMDDNN, where YYYY is the year, MM is the month, DD is the day, and NN is a count of how many times the zone data was modified that day. These fields won't work in any other order, since no other order gives a value that always increases as the date changes. This is critical: whatever format you choose, it's important that the serial number always increase when you update your zone data.
When a slave name server contacts a master server for zone data, it first asks for the serial number on the data. If the slave's serial number for the zone is lower than the master server's, the slave's zone data is out of date. In this case, the slave pulls a new copy of the zone. If a slave starts up and there is no backup file to read, it will always load the zone. As you might guess, when you modify the zone data files on the primary master, you must increment the serial number. Updating your zone data files is covered in Chapter 7, "Maintaining BIND".
The next four fields specify various time intervals, in seconds by default:
refresh
The refresh interval tells a slave for the zone how often to check that the data for this zone is up to date. To give you an idea of the system load this feature causes, a slave makes one SOA query per zone per refresh interval. The value we chose, three hours, is reasonably aggressive. Most users will tolerate a delay of half a working day for things like zone data to propagate when they are waiting for their new workstation to become operational. If you provide one-day service for your site, you could consider raising this value to eight hours. If your zone data doesn't change very often or if all of your slaves are spread over long distances (as the root name servers are), consider a value that is even longer, say 24 hours.
retry
If the slave fails to reach the master name server after the refresh interval (the host could be down), it starts trying to connect every retry seconds. Normally, the retry interval is shorter than the refresh interval, but it doesn't have to be.
expire
If the slave fails to contact the master name server for expire seconds, the slave expires the zone. Expiring the zone means that the slave stops giving out answers about the zone because the zone data is too old to be useful. Essentially, this field says that at some point, the data is so old that giving out no data is better than giving out stale data. Expire times on the order of a week are common -- longer (up to a month) if you frequently have problems reaching your updating source. The expiration time should always be much larger than the retry and refresh intervals; if the expire time is smaller than the refresh interval, your slaves will expire the zone before trying to load new data.
negative caching TTL
TTL stands for time to live. This value applies to all negative responses from the name servers authoritative for the zone.
TIP: On versions of BIND before BIND 8.2, the last field in the SOA record is both the default time to live and the negative caching time to live for the zone.
Those of you who have read earlier versions of this book may have noticed the change in the format we used for the SOA record's numeric fields. Once upon a time, BIND only understood units of seconds for the four fields we just described. (Consequently, a whole generation of administrators know that there are 608400 seconds in a week.) Now, with all but the oldest BIND name servers (4.8.3), you can specify units besides seconds for these fields and as arguments to the TTL control statement, as we saw early in this chapter. For example, you can specify a three-hour refresh interval with 3h, 180m, or even 2h60m. You can also use d for days and w for weeks.
The right values for your SOA record depend upon the needs of your site. In general, longer times cause less load on your name servers and can delay the propagation of changes; shorter times increase the load on your name servers and speed up the propagation of changes. The values we use in this book should work well for most sites. RFC 1537 recommends the following values for top-level name servers:
Refresh 24 hours Retry 2 hours Expire 30 days Default TTL 4 days
There is one implementation feature you should be aware of. Older versions (pre-4.8.3) of BIND slaves stop answering queries during a zone load. As a result, BIND was modified to spread out the zone loads, reducing the periods of unavailability. So, even if you set a low refresh interval, your slaves may not check as often as you request. BIND attempts a certain number of zone loads and then waits 15 minutes before trying another batch.
Now that we've told you all about how slave name servers poll to keep their data up to date, BIND 8 and 9 change how zone data propagates! The polling feature is still there, but BIND 8 and 9 add a notification when zone data changes. If both your primary master server and your slaves run BIND 8 or 9, the primary master notifies the slave that a zone has changed within 15 minutes of loading a new copy of that zone. The notification causes the slave server to shorten the refresh interval and attempt to load the zone immediately. We'll discuss this more in Chapter 10, "Advanced Features".
Multiple Master Servers
Are there other ways to make your slave name server's configuration more robust? Yes -- you can specify up to 10 IP addresses of master servers. In a BIND 4 configuration file, just add them after the first IP address and before the backup filename. In a BIND 8 or 9 configuration file, add them after the first IP address and separate them with semicolons:
masters { 192.249.249.3; 192.249.249.4; };
The slave will query the master server at each IP address in the order listed until it gets a response. Through BIND 8.1.2, the slave would always transfer the zone from the first master name server to respond if that master had a higher serial number. The slave would try successive master servers only if the previous master didn't respond. From BIND 8.2 on, however, the slave actually queries all of the master name servers listed and transfers the zone from the one with the highest serial number. If multiple master servers tie for the highest serial number, the slave transfers the zone from the first of those masters in the list.
The original intent of this feature was to allow you to list all the IP addresses of the host running the primary master name server for the zone if that host were multihomed. But since there is no check to determine whether the contacted server is a primary master or a slave, you can list the IP addresses of hosts running slave servers for the zone if that makes sense for your setup. That way, if the first master server is down or unreachable, your slave can transfer the zone from another master name server.
Slave DNS and Plesk
Preface
There are several reasons why you might need at least two DNS servers for serving your sites:
- You purchased a domain name from a domain registrar. To delegate the domain, many registrars require the domain zone to be served by at least two name servers residing in different IP subnets.
- You have several hosting servers, and you have not grown enough to use the products like PPA or PA, but you want to use a single set of name servers for all the domains you host.
- You want to have your own name servers and not depend on third parties.
- You want the WHOIS records for your domains to list your name servers.
Usually you would set up a couple of name servers in the Master/Slave mode. Then you create domain zones on both servers, but administer resource records of the domain zones only on the master server. The secondary (slave) server automatically downloads the changes from the master. Thus, you always have two active name servers with the same set of domain zones and resource records.
The only trifle annoyance is that you have to create and delete each zone on both servers. This does not happen automatically. That’s why you create a domain zone on the master, and then you create this domain zone on the slave and specify the master server’s address. After that, when you add the domain resource records on the master, you can be sure that your slave server will automatically get them from the master.
For many years, integration of Plesk with a slave DNS server has not been obvious. A Plesk server is supposed to be the master. In Plesk, we have the slave and master modes for a domain zone and the list of IP addresses that can retrieve domain zones. But there is no mechanism for creation of new domain zones on the slave server. And it will never appear, because Plesk’s concept presumes automation of hosting operations on a single server. For integration of several servers that are dedicated to running individual services, Parallels offers PPA and PA.
Still there are a lot of Plesk users for whom PPA or PA are more than they actually need. They just want integration with a slave name server. Previously, to solve this problem, each Plesk administrator had to write their own scripts, purchase commercial ones, or manually created and deleted domain zones on the slave server.
Seemingly, there are no complications. Plesk has got its local name server – let it be the master, and there is a system of event triggers – let us associate our script execution with the events “DNS zone creation” and “DNS zone deletion”. The problem will be solved. Unfortunately, Plesk does not support such events.
Not only Plesk software engineers develop Plesk, but they also use the product they develop. That’s why we created an extension that allows Plesk users to integrate Plesk with an external slave name server running BIND9. You can download this extension here.
How it works
Plesk uses BIND as a local name server. It can be managed remotely with the native rndc utility. There’s no reason why we could not install BIND on a remote server and manage it with rndc. Plesk 11.5 introduced the “Custom DNS backend” mechanism. It can be used to connect an external DNS service, for example AWS Route53. You can learn more in our doc.
Briefly, this feature allows us to register a script with Plesk. The script will receive a DNS zone description in JSON format with instructions what to do to a zone upon creation, modification, and deletion of any DNS zone in Plesk. That’s all we need. While implementing this feature, we assumed that you would use an external DNS service instead of installing the BIND server with Plesk. However, you do not necessarily have to delete the local BIND. The script can operate concurrently with a local DNS service. This is the idea that our extension uses.
The extension works according to the following algorithm:# It registers a slave server in the extension settings.
- The slave server’s IP address is automatically added to the list of addresses allowed to transfer domain zones from the Plesk server.
- When you create, modify, or delete an active domain zone in Plesk, Plesk creates, modifies, or deletes the domain zone in the local DNS service.
- Then the script starts and receives the domain name and the command to create, modify, or delete.
- The script initiates the rndc command for each connected slave server.
- Slave servers synchronize domain zones with the ones on the Plesk server.
Thus, we get a simple and very reliable scheme of working with slave name servers. All issues with zone files format, connection, and service restart are handled by the DNS service. The administrator should set up a slave server to work with an external Plesk only once. After that you can go to the registrar and say that the Plesk server and the slave server are name servers for your domains. Thus, we resolved all the issues stated at the beginning of the article.
Technical details
To set up a slave name server, using the example of a server with Debian 7:
- Install BIND.
apt-get install bind9* Allow creating new zones with rndc. In the /etc/bind/named.conf.options file, in the options {} directive, type:
allow-new-zones yes;* Specify the IP address from which control instructions should be accepted and set BIND to listen on all accessible network interfaces. Specify rndc key which will used by Plesk. In the /etc/bind/named.conf.local file, type:
key "plesk-key" {
algorithm hmac-md5;
secret "vwOxonI4n4CVRUhKAOAAIA==";
};
controls {
inet * port 953 allow { <plesk_ip>; <another_plesk_ip>; 127.0.0.1; } keys {"rndc-key", "plesk-key"; };
};* That’s it, the slave name server is set up.
After that, install the extension on the Plesk server. In the extension settings, add the slave server and specify its IP address and the pass key. The extension will create a configuration file with the slave server settings for the rndc utility. From now on, Plesk will automatically transfer all created, modified, and deleted zones to the slave server by executing the following command for each slave server:
Creation
/usr/sbin/rndc -c slave.config addzone example.com '{ type slave; file "example.com"; masters { <plesk_ip>; }; };'
Modification
/usr/sbin/rndc -c slave.config refresh example.com
Deletion
/usr/sbin/rndc -c slave.config delzone example.com
Now, when you add a domain in Plesk, a DNS zone is automatically created on the slave server as well as on the master server. Extension is available for download direct by link Slave DNS manager.
Troubleshooting
DNS (Domain name system) may not be known to most people who use the Internet but it is the real invisible force driving the Internet without which everyone would be seeing numbers and IPs. The whole meaning of domain names exists today just because of DNS.
Introduction
The simplest way of explaining DNS in one line is to map domain name to IP address. I am not sure how many would know that when somebody types a domain name in IE/firefox, the browser forwards the DNS request asking for ip address from the resolver of ISP (ISP Provider) and the resolver contacts the root servers and then systematically retrieves the IP address within a matter of few milliseconds.
Understanding DNS and its working is one of the most difficult computer engineering subject and yet most experienced network administrators struggle in this topic when it comes to DNS zone file writing.
Before I proceed with this article, the following are the MOST IMPORTANT points you should remember as otherwise you wouldnt understand bit.
Points To Remember
- Whenever you specify A record it must contain IP address on the Right side. The A record is so important in DNS without which the meaning of mapping hostnames to IP would be absurd. So remember this!
- CNAME (Alias) must contain hostnames. No IPs here
- NS an MX records must contain host names. No IPs allowed.
- Why DOT? simply because it tells to start query from root servers (denoted by dot)
- MX records (for mail servers) should contain hostnames NOT IPs.
Common DNS Terms
Glue Records
Glue records are A records that are associated with NS records to provide "bootstrapping" information to the NS records nameserver. (see RFC 1912 section 2.3)
domain.com. IN NS ns1.domain.com.
domain.com. IN NS ns2.domain.com.
ns1 IN A 11.33.55.77 ns2 IN A 22.44.66.88
In the above example we are mapping each NS records to IP address (A record) thus binding nameservers to IP (that is glue them).
LAME Nameserver Delegation
A nameserver which gives non-authoritative answer is usually called 'LAME'. Every domain must have atleast 2 nameservers and if i ask each of them, and if they have domain zone information, I will get authoritative answer. If not it's a 'lame delegation'. Refer to RFC 1912 section 2.8.
An example of lame delegation is
domain.com IN NS ns1.domain.com
domain.com IN NS ns2.example-server.net
ns1.domain.com is configured to have zone information about domain but ns2.exserver.net was not configured properly and does not have any information about the domain. So ns1 will answer authoritatively wheras ns2 won't which will be 'lame' until it is set up properly.
To get more in depth understanding, let's use dig tool for example.com.
1. First we find the nameservers of example.com:
dig example.com NS
;; ANSWER SECTION:
example.com. 158240 IN NS a.iana-servers.net. example.com. 158240 IN NS b.iana-servers.net.
2. Since we have received 2 nameservers, we ask each of them whether they give authoritative answer. If it's authoritative 'aa' flag in the header will be set in the answer received ('aa' is authoritative answer).
> dig @b.iana-servers.net example.com NS
> dig @a.iana-servers.net example.com NS
;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60896 ;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION: ;example.com. IN NS
;; ANSWER SECTION: example.com. 172800 IN NS a.iana-servers.net. example.com. 172800 IN NS b.iana-servers.net.
Look in the flags.
flags: qr aa rd
Since 'aa' is set in the answer, then both the nameservers of example.com provide authoritative answer. If it is lame delegation you won't get the authoritative answer.
CAUTION
You should not use CNAME (alias) along with NS records and it often confuses most resolvers causing loops and often leads to 'lame' delegation.
domain.com. IN NS ns1.domain.com.
domain.com. IN NS ns2.domain.com. domain.com. In CNAME ns9.example-server.net
So never use CNAME along with NS records.
Stealth Nameservers
Stealth Nameservers (or hidden nameservers) are mismatched/conflicting nameservers which exist at root level against of nameservers in the domain.
To illustrate this, when I ask parent servers about your domain for NS records at root level I get
ns0.domain.com ns2.domain.com ns3.domain.com
but when I query nameservers of your domain for the NS records are not the same and comes like
ns0.domain.com ns2.domain.com ns.example-dns.net
Since ns.example-dns.net and ns3.domain.com is hidden both are a 'stealth nameservers'. Although there is nothing wrong in it, it is advisable not to have any stealth nameservers both at root level and in your dns server.
You can use dig command to lookup NS records at root server level.
dig +trace @K.root-servers.net example.com NS
and to ask one of the nameservers of the domain.
dig @ns0.domain.com example.com NS
Look for any NS mismatch between the two queries. If there is a nameserver missing at root level, add the missing nameserver to your domain registrar. If the nameserver missing at domain level, add the nameserver to the zone file of the domain and update all your secondary nameservers.
Open DNS Server
Running the dns server 'open' is a big security risk since it answers recursive queries both from inside and outside your network. It means anyone can query your server for IP address and your dns server will answer them.
To illustrate this, we have two nameservers running bind for domain example.com.
ns1.example.comns2.example.com
We ask ns1.example to resolve outside domain google.com and if we get IP address (A record) in the answer section, then it means it is an 'open dns server'.
dig @ns1.example.com google.com
dig @ns2.example.com google.com
;; global options: printcmd
;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 12107 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION: ;google.com. IN A
;; Query time: 32 msec
Since there is no ANSWER section or IP address both the nameservers does not constitute open dns server.
If you happen to run bind8 or later, all you have to do is set 'recursion no' within options to disable dns server answering recursive queries.
options {
.... recursion no; }
Zone Transfers (AXFR request)
Zone transfers are done by secondary nameservers to retrieve latest and updated zone information for domain from master or primary nameserver. Zone transfers should only be made available to secondary nameservers and not to the open world as it is a big security risk and may expose the internals of your network to the attacker.
To request a zone transfer for example.com we need to ask the master nameserver first. See the below example with dig.
dig @ns1.example.com example.com
If you see the output with full zone file, then you have to disable the zone transfer. In most cases you will see connection failed or REFUSED which means zone transfer is not allowed and its a good thing.
Common DNS Errors in Zone file Writing
No CNAME pointing to NS records
domain.com. IN NS ns1.domain.com.
domain.com. IN NS ns2.domain.com. domain.com. In CNAME ns9.example-server.net -----> WRONG
Placing CNAME along with NS the all of namservers will fail and will result in lame delegation. Don't do that!
Refer to RFC1912 2.4 and RFC2181 10.3.
DNS servers on IPs on same subnet (/24) or on same server
The whole purpose of DNS is for nameservers to be spread over different geographical locations so that if one dns fails the other would work. Although it is very common practice to run both nameservers on same server or subnet, it would not provide fault tolerance. If the server fails your nameservers will fail and your site wont load.
ns1 IN A 75.33.22.xx -----> same subnet /24
ns2 IN A 75.33.22.xx -----> same subnet /24
Proper GLUE
Always add glue to your NS records to the IP addresses using A record, failing which one of your nameservers will fail.
domain.com. IN NS ns1.domain.com.
domain.com. IN NS ns2.domain.com.
ns1 IN A 1.2.3.4 -----> GLUE ns2 IN A 2.4.6.9 -----> GLUE
Refer to RFC1912.
No duplicate MX records
domain.com. IN MX mail.domain.com.
domain.com. IN MX mail.domain.com ----> DUPLICATE
Allow Port 53 for both UDP and TCP connections
If you use firewall make sure you do not block port 53 for DNS tcp and udp requests. By default dns lookups use UDP protocol while zone transfers and notifications use TCP protocol of port 53.
Port 53 UDP = Dns Requests
Port 53 TCP = Zone transfers
CNAMEs cannot co-xist with MX hosts.
Do not specify CNAME or aliases pointing to MX records.
domain.com. IN MX 10 mail.domain.com.
mail IN CNAME domain.com. ----------> WRONG
Instead use A record to map directly to IP address. mail IN A 11.33.55.77 ---> CORRECT
Refer to RFC1912.
MX Records should not contain IP addresses
domain.com. IN 10 MX mail.domain.com. ----> CORRECT
domain.com. IN 20 MX 11.22.33.44 -----> WRONG
The correct way of doing this is glue the mx host to A record.
domain.com. IN MX 10 mail.domain.com. -----> CORRECT
mail IN A 11.33.55.77 ----------> CORRECT
NS records should NOT contain IP address
Always specify nameservers for your domain with NS records. It should be a name and not ip address.
domain.com. IN NS dns0.domain.com. -----> CORRECT
domain.com. IN NS 75.xx.xx.xx -----------> WRONG
REVERSE DNS FOR MAIL DELIVERY
For proper mail delivery, the following anti-spam methos are very important to make sure the email is delivered to users inbox. Most public email service providers yahoo, hotmail and gmail do use these parameters to flag email is spam or not.
(i) Setup Reverse IP for your mail server with PTR in DNS (needs Dedicated IP)
(ii) Setup SPF Record in your DNS (iii) Setup Domain Keys
I have seen on many occasions if you use shared hosting plan, most emails do land up in spam/bulk folder in the users inbox. So use a dedicated server.
Set up reverse IPs for Mailserver IPs
In order to setup reverse IP, first you will need to place a request to your hosting provider (since they own Ip address) and ask them to setup a reverse IP to your mail server. Once that is done you have to place a line using PTR in your domain zone file.
To test reverse ip lookup:
host <ip-address>
will show the output of reverse dns.
Set up SPF record
SPF record is setup using TXT record in your dns zone file. It looks like what is shown below. Visit http://openspf.org for more information about setup and configuration.
domain.com. IN TXT "v=spf1 a mx ip4:11.33.55.77 -all"
To query SPF record using dig:
dig domain.com TXT
Domain Keys
It basically contains 2 records (with and without selector) placed under TXT using underscore along with generated public key.
The ’sel’ is a selector and can be selector name.
Logging Clause
This section describes the logging clause which prior to BIND 9 needed to appear first in the named.conf file. This no longer the case and it may appear anywhere convenient. BIND uses syslogd before a valid logging clause is available so named.conf parse errors and other information will appear in /var/log/messages (depending on syslog.conf) prior to, or in the absence of, a valid logging clause. In the case of windows parse errors are written to the Event Log. Only one logging clause can be defined but multiple channels may be defined to stream logs.
= logging Clause Syntax =
BIND provides comprehensive logging features. Values in bold type below are keywords;
logging {
[ channel channel_name {
( file path name
[ versions ( number | unlimited ) ]
[ size size_spec ]
| syslog syslog_facility
| stderr
| null );
[ severity (critical | error | warning | notice |
info | debug [ level ] | dynamic ); ]
[ print-category yes | no; ]
[ print-severity yes | no; ]
[ print-time yes | no; ]
}; ]
[ category category_name {
channel_name ; [ channel_name ; ... ]
}; ]
...
};
The following notes describe the various fields and values:
| channel channel_name | BIND will accept multiple channel definitions in a single logging statement. 'channel_name' is normally written as a non-space name, for instance, my_channel but it can be written as a quoted string, for instance, "my channel". It is an arbitrary but unique name used to associate the category statement with this channel definition or it may take one of the standard (pre-defined) values below:
| ||||||||||||||||||||||||||||||||||||||||||||
| file | 'path_name' is a quoted string defining the absolute path to the logging file, for example, "/var/log/named/namedlog.log". From the grammar above 'file', 'syslog', 'stderr' and 'null' are mutually exclusive for a 'channel'. | ||||||||||||||||||||||||||||||||||||||||||||
| versions | 'versions' may take the parameter 'number' or 'unlimited' and defines the number of file versions that should be kept by BIND. Version files are created by BIND by appending .0, .1 etc to the file named defined by the file parameter. Files are 'rolled' (renamed or overwritten) so .0 will always contain the last log information prior to commencing the new log., .1 the next and so on. 'unlimited' currently implies 'versions 99'. Unless a size parameter is used new log versions will only be 'rolled' when BIND is restarted. If no versions statement is defined a single log file of unlimited size is used and on restart new data is appended to the defined file. This can get to be a very big file. | ||||||||||||||||||||||||||||||||||||||||||||
| size size_spec | 'size' allows you to define a limit to the file size created. A numeric only size_spec value is assumed to be the size in bytes, you may use the short forms k or K, m or M, g or G e.g. 25m = 25000000. size and versions are related in the following way: # If you specify a size value and NO versions parameter when the size limit is reached BIND will stop logging until the file size is reduced to below the threshold defined i.e. by deleting or truncating the file.
| ||||||||||||||||||||||||||||||||||||||||||||
| syslog syslog_facility | 'syslog' indicates that this channel will use syslogd logging features (as defined in syslog.conf). The syslog_facility is the facility definition for 'syslog' and may be found in syslog's man pages. From the grammar above 'file', 'syslog', 'stderr' and 'null' are mutually exclusive for a 'channel'. | ||||||||||||||||||||||||||||||||||||||||||||
| stderr | 'stderr' writes to the current standard out and would typically be only used for debug purposes. From the grammar above 'file', 'syslog', 'stderr' and 'null' are mutually exclusive for a 'channel'. | ||||||||||||||||||||||||||||||||||||||||||||
| null | 'null' writes to /dev/null - the bit bucket, nowhere. It does not produce a log. From the grammar above 'file', 'syslog', 'stderr' and 'null' are mutually exclusive for a 'channel'. | ||||||||||||||||||||||||||||||||||||||||||||
| severity | Controls the logging levels and may take the values defined. Logging will occur for any message equal to or higher than the level specified (=>) lower levels will not be logged.
| ||||||||||||||||||||||||||||||||||||||||||||
| print-time yes | no | Controls whether the date and time are written to the output channel (yes) or not (no). The default is 'no'. | ||||||||||||||||||||||||||||||||||||||||||||
| print-severity yes | no | Controls whether the severity level is written to the output channel (yes) or not (no). The default is 'no'. | ||||||||||||||||||||||||||||||||||||||||||||
| print-category yes | no | Controls whether the severity level is written to the output channel (yes) or not (no). The default is 'no'. | ||||||||||||||||||||||||||||||||||||||||||||
| category category_name | Controls what categories are logged to the various defined or default 'channel_names'. The category_name (a quoted string, for example, "default") may take one of the following values:
|
= Examples =
The first example shows a minimal logging configuration that will work and generate modest log volumes.
Logging{
channel simple_log {
file "/var/log/named/bind.log" versions 3 size 5m;
severity warning;
print-time yes;
print-severity yes;
print-category yes;
};
category default{
simple_log;
};
};
Reading BIND Debugging Output
Turning On Debugging Reading Debugging Output The Resolver Search Algorithm and Negative Caching (BIND 8) The Resolver Search Algorithm and Negative Caching (BIND 9) Tools
"O Tiger-lily!" said Alice, addressing herself to one that was waving gracefully about in the wind, "I wish you could talk!"
"We can talk," said the Tiger-lily, "when there's anybody worth talking to."
One of the tools in your troubleshooting toolchest is the name server's debugging output. As long as your name server has been compiled with DEBUG defined, you can get query-by-query reports of its internal operation. The messages you get are often quite cryptic; they were meant for someone who has the source code to follow. We'll explain some of the debugging output in this chapter. Our goal is to cover just enough for you to follow what the name server is doing; we aren't trying to supply an exhaustive compilation of debugging messages.
As you read through the explanations here, think back to material covered in earlier chapters. Seeing this information again, in another context, should help you understand more fully how a name server works.
Debugging Levels
The amount of information the name server provides depends on the debugging level. The lower the debugging level, the less information you get. Higher debugging levels give you more information, but they also fill up your disk faster.
After you've read a lot of debugging output, you'll develop a feel for how much information you'll need to solve any particular problem. Of course, if you can easily recreate the problem, you can start at level 1 and increase the debugging level until you have enough information. For the most basic problem -- why a name can't be looked up -- level 1 will often suffice, so you should start there.
What Information Is at Each Level?
Here's a list of the information that each debugging level produces for BIND 8 and BIND 9 name servers. The debugging information is cumulative; for example, level 2 includes all of level 1's debugging information. The data is divided into the following basic areas: starting up, updating the database, processing queries, and maintaining zones. We won't cover updating the name server's internal database -- problems almost always occur elsewhere. However, what the name server adds or deletes from its internal database can be a problem, as you'll see in Chapter 14, "Troubleshooting DNS and BIND".
BIND 8 and 9 have a whopping 99 debug levels, but most of the debugging messages are logged at just a few of those levels. We'll look at those now.
BIND 9 debugging levels
Level 1
Level 1 shows you basic name server operation: zone loading, maintenance (including SOA queries, zone transfers and zone expiration, and cache cleaning), NOTIFY messages, queries received, and high-level tasks dispatched (such as looking up addresses for a name server).
Level 2
Level 2 logs multicast requests.
Level 3
Level 3 shows you low-level task creation and operation. Unfortunately, most of these tasks don't have particularly descriptive names (requestmgr_detach ?) and the arguments they report are awfully cryptic. Level 3 also shows you journal activity, such as when the name server writes a record of a zone change to the zone's journal or when the name server applies a journal to a zone at startup. Operation of the DNSSEC validator and checking of TSIG signatures also come in at debug level 3.
Level 4
Level 4 logs when a master name server falls back to using AXFR because the transferred zone's journal isn't available.
Level 5
Level 5 logs which view was used while satisfying a particular request.
Level 6
A handful of outbound zone transfer messages are logged at level 6, including checks of the query that initiated the transfer.
Level 7
There are only a couple of new debugging messages at this level (logging of journal adds and deletes, and a count of how many bytes were returned by a zone transfer).
Level 8
Many dynamic update messages are logged at level 8: prerequisite checks, writing journal entries, and rollbacks. Several low-level zone transfer messages also appear here, including a log of resource records sent in a zone transfer.
Level 10
Level 10 reports a couple of messages about zone timer activity.
Level 20
Level 20 reports an update to a zone's refresh timer.
Level 90
Low-level operation of the BIND 9 task dispatcher is logged at level 90.
With BIND 8 and BIND 9, you can configure the name server to print out the debug level with the debug message. Just turn on the logging option print-severity as explained in Section 7.5, "Logging in BIND 8 and 9" in Chapter 7, "Maintaining BIND".
Keep in mind that this is debugging information -- it was used by the authors of BIND to debug the code, so it is not as readable as you might like. You can use it to figure out why the name server isn't doing what you think it should be or just to learn how the name server operates -- but don't expect nicely designed, carefully formatted output.
Reading Debugging Output
We'll cover five examples of debugging output. The first example shows the name server starting up. The next two examples show successful name lookups. The fourth example shows a secondary name server keeping its zone up to date. And in the last example, we switch from showing you name server behavior to showing you resolver behavior: the resolver search algorithm. After each trace (except the last one) we killed the name server and started it again so that each trace started with a fresh, nearly empty cache.
You might wonder why we've chosen to show normal name server behavior for all our examples; after all, this chapter is about debugging. We're showing you normal behavior because you have to know what normal operation is before you track down abnormal operation. Another reason is to help you understand the concepts (retransmissions, roundtrip times, etc.) we described in earlier chapters.
Name Server Startup (BIND 9, Debug Level 1)
Here's what a BIND 9 name server looks like starting up:
1) Sep 15 15:34:53.878 starting BIND 9.1.0 -d1 2) Sep 15 15:34:53.883 using 1 CPU 3) Sep 15 15:34:53.899 loading configuration from './named.conf' 4) Sep 15 15:34:53.920 the default for the 'auth-nxdomain' option is now 'no' 5) Sep 15 15:34:54.141 no IPv6 interfaces found 6) Sep 15 15:34:54.143 listening on IPv4 interface lo, 127.0.0.1#53 7) Sep 15 15:34:54.151 listening on IPv4 interface eth0, 192.249.249.3#53 8) Sep 15 15:34:54.163 command channel listening on 0.0.0.0#953 9) Sep 15 15:34:54.180 now using logging configuration from config file 10) Sep 15 15:34:54.181 dns_zone_load: zone 0.0.127.in-addr.arpa/IN: start 11) Sep 15 15:34:54.188 dns_zone_load: zone 0.0.127.in-addr.arpa/IN: loaded 12) Sep 15 15:34:54.189 dns_zone_load: zone 0.0.127.in-addr.arpa/IN: dns_journal _rollforward: no journal 13) Sep 15 15:34:54.190 dns_zone_maintenance: zone 0.0.127.in-addr.arpa/IN: enter 14) Sep 15 15:34:54.190 dns_zone_maintenance: zone version.bind/CHAOS: enter 15) Sep 15 15:34:54.190 running
The first difference you probably noticed between BIND 9's debugging output and BIND 8's is BIND 9's terseness. Remember that BIND 8 has been around for three years, and the authors have had plenty of time to add debugging messages to the code. BIND 9 is brand-spanking-new, so there aren't as many debugging messages yet.
You probably also noticed that BIND 9 includes a timestamp for each debugging message, which can be handy if you're trying to correlate messages to real-world events.
Lines 1 and 2 show the version of BIND we're running (9.1.0) and the configuration file it's reading. As with the previous example, we're using named.conf in the current directory. Line 3 tells us we're using only one CPU -- to be expected on a box with just one processor.
Line 4 gives us a simple warning that the default for the auth-nxdomain substatement (covered in Chapter 10, "Advanced Features") has changed. Line 5 reminds us that our host doesn't have any IP Version 6 network interfaces; if it did, BIND 9 could listen on those interfaces for queries.
Lines 6 and 7 show the name server listening on two network interfaces: lo, the loopback interface, and eth0, the Ethernet interface. BIND 9 displays the address and port in the format address#port, unlike BIND 8, which uses [address].port. Line 8 shows named listening on port 953, the default port, for control messages.
Lines 10-12 show the name server loading 0.0.127.in-addr.arpa. The start and loaded messages are self-explanatory. The no journal message indicates that no journal was present. (A journal, described in Chapter 10, "Advanced Features", is a record of dynamic updates the name server received for the zone.)
Finally, lines 13 and 14 show the name server doing maintenance on the 0.0.127.in-addr.arpa and version.bind zones. (version.bind is a built-in CHAOSNET zone that contains a single TXT record, attached to the domain name version.bind.) Zone maintenance is the process that schedules periodic tasks, such as SOA queries for slave and stub zones or NOTIFY messages.
A Successful Lookup (BIND 9, Debug Level 1)
We'll show you the debugging output produced by looking up the same domain name on a BIND 9 name server at debug level 1, but it's almost laughably short. Still, as we said, it's important to know what debugging output looks like under correct operation. Anyway, here goes:
Sep 16 17:20:57.193 client 192.249.249.3#1090: query: galt.cs.purdue.edu A Sep 16 17:20:57.194 createfetch: galt.cs.purdue.edu. A
The first line tells us that a client at IP address 192.249.249.3 (that is, the local host), running on port 1090, sent us a query for galt.cs.purdue.edu's address. The second line is logged by the portion of the name server that does name resolution to let us know what it's up to.
A Slave Name Server Checking Its Zone (BIND 9 Debug Level 1)
The equivalent debugging output from a BIND 9.1.0 name server at level 1 is, as usual, more concise. Here's what it looks like:
Sep 18 15:05:00.059 zone_timer: zone movie.edu/IN: enter Sep 18 15:05:00.059 dns_zone_maintenance: zone movie.edu/IN: enter Sep 18 15:05:00.059 queue_soa_query: zone movie.edu/IN: enter Sep 18 15:05:00.059 soa_query: zone movie.edu/IN: enter Sep 18 15:05:00.061 refresh_callback: zone movie.edu/IN: enter Sep 18 15:05:00.062 refresh_callback: zone movie.edu/IN: Serial: new 2000010923, old 2000010922 Sep 18 15:05:00.062 queue_xfrin: zone movie.edu/IN: enter Sep 18 15:05:00.070 zone_xfrdone: zone movie.edu/IN: success Sep 18 15:05:00.070 transfer of 'movie.edu' from 192.249.249.3#53: end of transfer Sep 18 15:05:01.089 zone_timer: zone movie.edu/IN: enter Sep 18 15:05:01.089 dns_zone_maintenance: zone movie.edu/IN: enter Sep 18 15:05:19.121 notify_done: zone movie.edu/IN: enter Sep 18 15:05:19.621 notify_done: zone movie.edu/IN: enter
The message at 15:05:00.059 shows the refresh timer popping, causing the name server to begin maintenance for the zone on the next line. First the name server queues a query for the SOA record for the IN class zone movie.edu (queue_soa_query at the same timestamp), which it sends.
At 15:05:00.062, the name server finds that the master name server has a higher serial number than it does (2000010923 to its 2000010922), so it queues an inbound zone transfer (queue_xfrin). All of eight milliseconds later (at 15:05:00.070) the transfer is done, and at 15:05:01.089 the name server resets the refresh timer (zone_timer).
The next three lines show the name server doing maintenance on movie.edu again. If, for example, some of movie.edu's name servers were outside the movie.edu zone, the name server would use this opportunity to look up their addresses (not just A, but also A6 and AAAA records!) so that it could include them in future responses. On the last two lines, our name server sends NOTIFY messages -- two, to be exact -- to the name servers listed in the NS records for movie.edu.
Turning On Debugging
Name server debugging can be started either from the command line or with control messages. If you need to see the startup information to diagnose your current problem, you'll have to use the command-line option. If you want to start debugging on a name server that is already running or if you want to turn off debugging, you'll have to use controls. The name server writes its debugging output to named.run. BIND 4 name servers create named.run in /usr/tmp (or /var/tmp), and BIND 8 and 9 name servers create it in the name server's working directory.
Debugging Command-Line Option
When troubleshooting, you sometimes need to see the sortlist, know which interface a file descriptor is bound to, or find out where in the initialization stage the name server was when it exited (if the syslog error message wasn't clear enough). To see this kind of debugging information, you'll have to start debugging with a command-line option; by the time you send a control message, it will be too late. The command-line option for debugging is -d level. When you use the command-line option to turn on debugging, a BIND 4 name server will not go into the background as it does normally; you'll have to add the & at the end of your command line to get your shell prompt back. Here's how to start a BIND 4 name server at debugging level 1:
# /etc/named -d 1 &
BIND 8 and 9 name servers go into the background even when you specify -d, so there's no need for the &.
Changing the Debugging Level with Control Messages
If you don't need to see the name server's initialization, start your name server without the debugging command-line option. You can later turn debugging on and off by using ndc to send the appropriate control message to the name server process. Here, we set debugging to level 3, then turn debugging off:
# ndc trace 3 # ndc notrace
And, as you might expect, if you turn on debugging from the command line, you can still use ndc to change the name server's debug level.
BIND 9.1.0's rndc doesn't implement the trace or notrace arguments yet (nor does the 9.1.0 named ), but a future version will. So if you're running BIND 9, use the -d command-line option.
Additional Possibilities
You can monitor your BIND9 server usage by installing the bindgraph package from the Universe (To enable Universe - see AddingRepositoriesHowto) and following configuration details as outlined in bindgraph's README documents
Further Information
Online Recources
- "ISC's BIND9 Manual" http://www.bind9.net/manuals
- TLDP's "DNS HOWTO" (For General Overview) http://www.tldp.org/HOWTO/DNS-HOWTO.html
- "Chroot BIND Howto" http://www.tldp.org/HOWTO/Chroot-BIND-HOWTO-4.html
- Debian BIND Wiki http://wiki.debian.org/Bind9
- BIND reference guide http://www.oit.uci.edu/dcslib/linux/rh-7.3/rhl-rg-en-7.3/ch-bind.html
Printed Resources
- "DNS & BIND" - Paul Albitz & Cricket Liu - 5th Edition - "O'Reilly Press" http://www.oreilly.com/catalog/dns5/index.html
- DNS & BIND Cookbook - Cricket Liu - 4th Edition - "O'Reilly Press"http://www.oreilly.com/
Controls clause
This section describes the controls clause in BIND 9.x. The controls clause is used to define access information and controls when using remote administration services, for example, the rndc utility. The controls clause takes a single inet statement type, though more than one inet statement may be defined. Full list of statements.
Controls {
inet inet_spec [inet_spec] ;
};
A controls clause is always defaulted and generates a TCP listen on port 953 (the default control port) of the loopback address for either or both of IPv4 and IPv6 (127.0.0.1 and/or ::1). If the remote administration will not be used, that is the rndc utility will not be used this control interface should be explicitly disabled by defining an empty controls clause as shown below:
controls {};
The primary access control method for remote administration, for example rndc in BIND 9, is via the use of keys defined within the inet statement (see below). To retain compatibility with previous versions of BIND or to run without a user generated key, a default key may be generated using the following command:
rndc-confgen -a
This command will create a file called rndc.key containing a default key clause with the name rndc-key in same directory as the named.conf file for the version of BIND being used and which is used for subsequent access to the control channel. If this command is not executed before BIND is loaded the following message will appear:
named [39248] none:0: open: /path/to/default/rndc.key: file not found
BIND will continue to run in this state but the control channel will not be operable. For full configuration of the inet statement and examples of its use in the controls clause see inet statements below.
inet
The inet statement defines a method to control access to the rndc (remote administration) utility. More than one inet statement may be included in a controls clause.
inet inet_spec [inet_spec] ..;
Each inet_spec parameter has the following format:
inet_spec = ( ip_addr | * ) [ port ip_port ] allow { address_match_list }
keys { key_list };
The ip_address parameter defines the IP address of the local server interface on which rndc connections will be accepted. The wildcard value ("*") will allow connection on any of the server's IP addresses including the loopback address. The optional ip_port parameter allows a specific port to be nominated for use by rndc connections.
The address_match_list defines the permitted hosts that can connect to the rndc channel. The key_list parameter contains a reference to one or more key clauses containing the list of permitted users who are allowed access. While address_match_lists can include a key parameter if one is present in the referenced address_match_list it is ignored, only keys defined in the key_list of the inet statement are permitted access.
The key_list can be omitted in which case the file rndc.key in the same directory as named.conf and which contains a default key clause with the name rndc-key will be used to provide default access. The rndc.key file is created by running the command:
rndc-confgen -a
The following example shows that a user on the loopback address can use the default key for access while all other users must use the rndc-remote key, in all cases localhost will use port 953 (the default) and external connection port 7766. An acl clause is used as the source of the address_match_list:
// named.conf fragment
acl "rndc-users" {
10.0.15.0/24;
!10.0.16.1/24; // negated
2001:db8:0:27::/64; // any address in subnet
};
....
key "rndc-remote" {
algorithm hmac-md5;
secret "OmItW1lOyLVUEuvv+Fme+Q==";
};
controls {
// local host - default key
inet 127.0.0.1 allow {localhost;};
inet * port 7766 allow {"rndc-users";} keys {"rndc-remote";};
};
Note: The keys clause above would normally be placed in a separate secure file and included into the named.conf file.
Problems, comments, suggestions, corrections (including broken links) or something to add? Please take the time from a busy life to 'mail us' (at top of screen), the webmaster (below) or [javascript:mailus('info-support','zytrax.com','Support%20Issue') info-support at zytrax]. You will have a warm inner glow for the rest of the day.
Bind9
Introduction
Putting a DNS server on a network allows for the replacement of IP addresses of individual machines by a name. As a result, it's even possible to associate multiple names to the same machine to update the different available services.
For example, www.example.com and pop.example.com, could both point to the primary server where the mail server and the business intranet reside, and the domain could be example.com. It's easy to remember that these two services are running on the same machine whose IP address is 192.168.0.1.
Now imagine that our network administrator decides for some reason or another to move the mail server to the machine 192.168.0.11. The only thing that has to be changed is the DNS server configuration file. You could always go and modify the host configuration for all the users, but that would be time consuming and inconvenient.
Network Layout
We get internet access through an xxxbox (192.168.1.1), two DNS servers provided by our ISP (80.10.249.2, 80.10.246.129). In fact, these two latter servers will ever be referred to in the configuration because the xxxbox will be in charge of resolving names if the packet destination isn't known. Consequently, I consider the xxxbox like a primary server outside of our domain.
The “sid” server (192.168.1.10) is connected to the xxxbox via its primary network card. It's also connected to the LAN (192.168.0.0/24) by its secondary network interface(192.168.0.1). It's on this that we are going to install the primary DNS server for our domain example.com (RFC 2606)
All the computers on the LAN are automatically assigned a single address by the DHCP service. The DHCP also provides the primary DNS server's address for our domain, and updatees the host names for the zone example.com so they can be associated with an ip address.
Server Management
Installation
The package bind9 will be used for installation.
# apt-get install bind9
and then if you want to also install the documentation (very useful):
# apt-get install bind9-doc
Configuration
After installation, you might want to get familiar with some of the configuration files. They are in the directory /etc/bind/
TSIG Signature
The purpose of this signature is to authenticate transactions with BIND. Thus, the DHCP server cannot update the example.com domain if it loses this key. Copy and paste an existing key
# cd /etc/bind/
# cat rndc.key
key "rndc-key" {
algorithm hmac-md5;
secret "QJc08cnP1xkoF4a/eSZZbw==";
};
# cp rndc.key ns-example-com_rndc-key
You can generate a new key with the following options:
- algorithm HMAC-MD5 - identifies 157 (required for a TSIG signature and only algorithm supported by BIND)
- length of 512 octets (multiple of 64 with a maximum length of 512 for the above algorithm)
- name : ns-example-com_rndc-key
dnssec-keygen -a HMAC-MD5 -b 512 -n USER ns-example-com_rndc-key Kns-example-com_rndc-key.+157+53334
The footprint associated with the key is 53334. We get two files, one with an extension key and the other with a private extension. This substitutes the key in the file ns-example-com_rndc-key with the one in one of these two files.
# cat Kns-example-com_rndc-key.+157+53334.private
Private-key-format: v1.2
Algorithm: 157 (HMAC_MD5)
Key: LZ5m+L/HAmtc9rs9OU2RGstsg+Ud0TMXOT+C4rK7+YNUo3vNxKx/197o2Z80t6gA34AEaAf3F+hEodV4K+SWvA===
Bits: AAA==
# cat ns-example-com_rndc-key
key "ns-example-com_rndc-key" {
algorithm hmac-md5;
secret "LZ5m+L/HAmtc9rs9OU2RGstsg+Ud0TMXOT+C4rK7+YNUo3vNxKx/197o2Z80t6gA34AEaAf3F+hEodV4K+SWvA==";
};
The file ns-example-com_rndc-key should not be made world readable for security reasons. This should be inserted into the bind configuration by an include because the bind configuration itself is world-readable. Also, it's a good idea to delete the key and private files generated before.
File /etc/bind/named.conf
This file is the main configuration file for the DNS file.
// Managing acls
acl internals { 127.0.0.0/8; 192.168.0.0/24; };
// Load options include "/etc/bind/named.conf.options";
// TSIG key used for the dynamic update include "/etc/bind/ns-example-com_rndc-key";
// Configure the communication channel for Administrative BIND9 with rndc
// By default, they key is in the rndc.key file and is used by rndc and bind9
// on the localhost
controls {
inet 127.0.0.1 port 953 allow { 127.0.0.1; };
};
// prime the server with knowledge of the root servers
zone "." {
type hint;
file "/etc/bind/db.root";
};
include "/etc/bind/named.conf.default-zones"; include "/etc/bind/named.conf.local";
Note : with Debian Jessie the 'zone "." {...}' part is inside the file "named.conf.default-zones". You don't need to add it in the file "named.conf".
File /etc/bind/named.conf.default-zones
Note: as of Debian 7 "Wheezy" bind9 ships with a file containing default forward, reverse, and broadcast zones.
// be authoritative for the localhost forward and reverse zones, and for
// broadcast zones as per RFC 1912
zone "localhost" {
type master;
file "/etc/bind/db.local";
};
zone "127.in-addr.arpa" {
type master;
file "/etc/bind/db.127";
};
zone "0.in-addr.arpa" {
type master;
file "/etc/bind/db.0";
};
zone "255.in-addr.arpa" {
type master;
file "/etc/bind/db.255";
};
File /etc/bind/named.conf.options
This file contains all the configuration options for the DNS server
options {
directory "/var/cache/bind";
// Exchange port between DNS servers
query-source address * port *;
// Transmit requests to 192.168.1.1 if
// this server doesn't know how to resolve them
forward only;
forwarders { 192.168.1.1; };
auth-nxdomain no; # conform to RFC1035
// From 9.9.5 ARM, disables interfaces scanning to prevent unwanted stop listening
interface-interval 0;
// Listen on local interfaces only(IPV4)
listen-on-v6 { none; };
listen-on { 127.0.0.1; 192.168.0.1; };
// Do not transfer the zone information to the secondary DNS
allow-transfer { none; };
// Accept requests for internal network only
allow-query { internals; };
// Allow recursive queries to the local hosts
allow-recursion { internals; };
// Do not make public version of BIND
version none;
};
The port associated with the query-source option must not in any case be frozen because it jeopardizes the DNS transactions in the case of a resolver. * Vulnerability Note VU#800113 http://www.kb.cert.org/vuls/id/800113
M. Rash wrote an interesting article about this and how to force the source port randomly via the iptables: Mitigating DNS Cache Poisoning Attacks with iptables
To reduce the delay timeout for UDP connections, and thus highlight the randomization, which by default is 30s by tuple, simply update the parameter net.netfilter.nf_conntrack_udp_timeout
# sysctl -w net.netfilter.nf_conntrack_udp_timeout=10
to get timeout of 10s.
File /etc/bind/named.conf.local
This file contains the local DNS server configuration, and this is where you declare the zones associated with this server's domain(s).
// Manage the file logs include "/etc/bind/named.conf.log";
// Domain Management example.com
// ------------------------------
// - The server is defined as the master on the domain.
// - There are no forwarders for this domain.
// - Entries in the domain can be added dynamically
// with the key ns-example-com_rndc-key
zone "example.com" {
type master;
file "/var/lib/bind/db.example.com";
//forwarders {};
// If we do not comment the forwarders "empty" clients of the local subnet in my case don't have access to the upstream DNS ?
//allow-update { key ns-example-com_rndc-key; };
allow-update { key rndc-key; };
//confusion between the file name to import (ns-example-com_rndc-key) and the key label (rndc-key) ?
};
zone "0.168.192.in-addr.arpa" {
type master;
file "/var/lib/bind/db.example.com.inv";
//see comment below (zone "example.com")
//forwarders {};
//allow-update { key ns-example-com_rndc-key; };
allow-update { key rndc-key; };
};
// Consider adding the 1918 zones here, if they are not used in your // organization include "/etc/bind/zones.rfc1918";
NOTE: if you create a local non-FQDN and call it .local it clashes with some other packages (which?). Edit /etc/nsswitch.conf and move dns right after the files on the host line makes .local domains work.
File /etc/bind/named.conf.log
With Debian Jessie, you need to create this file in /etc/bind
logging {
channel update_debug {
file "/var/log/update_debug.log" versions 3 size 100k;
severity debug;
print-severity yes;
print-time yes;
};
channel security_info {
file "/var/log/security_info.log" versions 1 size 100k;
severity info;
print-severity yes;
print-time yes;
};
channel bind_log {
file "/var/log/bind.log" versions 3 size 1m;
severity info;
print-category yes;
print-severity yes;
print-time yes;
};
category default { bind_log; };
category lame-servers { null; };
category update { update_debug; };
category update-security { update_debug; };
category security { security_info; };
};
Here we define different log methods for the different categories. The first category is, as its name indicates the default category that is usually assigned to syslog. All categories not mentioned, are similar to the default category. For a list of the different categories, see the bind9 administrator reference manual. In terms of blade-servers, it ignores all the logs associated with them. It may be necessary to create /var/log in the chroot later.
Resource Records (RR)
DNS is made up of several registrations, RR or Resource Records, defining the various domain information. The first is dedicated to name resolution, in our case, it is the file db.example.com. The second will be used for reverse name resolution, it is the file db.example.com.inv.
Files in var/cache/bind/
- RR for name reso (db.example.com file)
$TTL 3600
@ IN SOA sid.example.com. root.example.com. (
2007010401 ; Serial
3600 ; Refresh [1h]
600 ; Retry [10m]
86400 ; Expire [1d]
600 ) ; Negative Cache TTL [1h]
;
@ IN NS sid.example.com.
@ IN MX 10 sid.example.com.
sid IN A 192.168.0.1 etch IN A 192.168.0.2
pop IN CNAME sid www IN CNAME sid mail IN CNAME sid* RR for inverse name resol ( db.example.com.inv file)
@ IN SOA sid.example.com. root.example.com. (
2007010401 ; Serial
3600 ; Refresh [1h]
600 ; Retry [10m]
86400 ; Expire [1d]
600 ) ; Negative Cache TTL [1h]
;
@ IN NS sid.example.com.
1 IN PTR sid.example.com. 2 IN PTR etch.example.com.
Some Explanations :
$TTL : (Time To Live) expresses the duration (in seconds) validity, by default, of the information contained in the RRs. Once this time expires, it is necessary to recheck the data. Types :
- SOA : Show romanization
to define information about the area. In this case the name of the primary DNS server "sid.example.com." and the email address of technical contact (root.example.com.; the @ is replaced by a dot). It is composed of several fields:
- 1. Serial : is the whole non-signed 32 bits. This is the serial number to increment with each change of file. It allows the secondary server to reload the information they have. The general purpose is to format it this way YYYYMMDDXX, either for the first amendment 01/04/2007 -> 2007040101, for the second 2007040102.
- 2. Refresh : defines the data refresh period.
- 3. Retry : if an error occurs during the last refresh, it will be repeated at the end of time Retry.
- 4. Expires': the server is considered unavailable after the time expires.
- 5. Negative cache TTL': set the lifetime of a NXDOMAIN response from us.
- NS': information on behalf of nameservers for the domain.
- 'X.: information on the mail server. Many can be defined. Thus, it is possible to give them a priority, assigning a number. The lower the number, the higher the priority.
- A': associates a host name to an IPv4 address (32 bits)
- 'YYYY: associates a host name to an IPv6 address (128 bits)
- CNAME': identifies the canonical name of an alias (a name that points to another name)
- 'PTR: This is simply the inverse resolution (the opposite of type A).
The classes in the association determines the Internet class. Other classes are available (CH and HS). For more information please consult the RFC 1035
/etc/resolv.conf File
search example.com
It's no more complicated than that !
Chroot
The named daemon is started using the bind user by default.
This option is found in the bind service config file /etc/default/bind9 (NOTE: this is not valid for jessie who used systemd):
OPTIONS="-u bind"
The bind start script /etc/init.d/bind9 reads this config file when the service is started.
Starting bind as a non root user is good practice but to run the daemon in a chroot environment we also need specify the chroot directory. This is done using the same OPTIONS variable in /etc/default/bind9.
To begin, start by stopping the bind service:
/etc/init.d/bind9 stop
Then edit /etc/default/bind9 (not for jessie):
OPTIONS="-u bind -t /var/bind9/chroot"
For Jessie, create the file /etc/systemd/system/bind9.service with options "-t /var/bind9/chroot":
[Unit] Description=BIND Domain Name Server Documentation=man:named(8) After=network.target
[Service] ExecStart=/usr/sbin/named -f -u bind -t /var/bind9/chroot ExecReload=/usr/sbin/rndc reload ExecStop=/usr/sbin/rndc stop
[Install] WantedBy=multi-user.target
For Jessie, after creating the above unit file, update the symlink to the unit file with:
systemctl reenable bind9
Now create the chroot directory structure:
mkdir -p /var/bind9/chroot/{etc,dev,var/cache/bind,var/run/named}
Create the required device special files and set the correct permissions:
mknod /var/bind9/chroot/dev/null c 1 3
mknod /var/bind9/chroot/dev/random c 1 8
chmod 660 /var/bind9/chroot/dev/{null,random}
Move the current config directory into the new chroot directory:
mv /etc/bind /var/bind9/chroot/etc
Now create a symbolic link in /etc for compatibility:
ln -s /var/bind9/chroot/etc/bind /etc/bind
If you want to use the local timezone in the chroot (e.g. for syslog):
cp /etc/localtime /var/bind9/chroot/etc/
Change the ownership on the files you've just moved over and the rest of the newly created chroot directory structure:
chown bind:bind /var/bind9/chroot/etc/bind/rndc.key
chmod 775 /var/bind9/chroot/var/{cache/bind,run/named}
chgrp bind /var/bind9/chroot/var/{cache/bind,run/named}
Edit the PIDFILE variable in /etc/init.d/bind9 to the correct path:
PIDFILE=/var/bind9/chroot/var/run/named/named.pid
Finally tell rsyslog to listen to the bind logs in the correct place:
echo "\$AddUnixListenSocket /var/bind9/chroot/dev/log" > /etc/rsyslog.d/bind-chroot.conf
Restart rsyslog and start bind:
/etc/init.d/rsyslog restart; /etc/init.d/bind9 start
Client Manage
As I mentioned at the beginning, the assignment of IP addresses on the LAN is performed by the DHCP server. Thus, to set our DNS server to different clients, it is necessary to add the DHCP configuration file the following two lines:
option domain-name "example.com"
option domain-name-server sid.example.com
It must be added to the file (I think) the areas for which DHCP should automatically perform updates.
Syntax (everything after "=>" is my comments) :
zone [name.of.the.zone.] { * primary 127.0.0.1; => the primary DNS server is on the same machine as the DHCP
key rndc-key; => it's necessary to provide the security key (via an include) in the beginning of the DHCP server configuration file,
- this must be the same key that secures the allow-update for the zone in the named.conf.local of Bind9.
}
Examples de [name.of.the.zone.] (with the "." at the end) :
- example.com. : for the direct zone of this article,
- 0.168.192.in-addr.arpa. : for the inverse zone of this article.
For more information on the implementation of dynamic update of DNS records through DHCP is here
Testing tools
Dig Command
This can directly search the DNS server of your choice and get a lot of information in addition to name resolution and contrast resolution. $ dig nomade-frjo.stones.lan ; <<>> DiG 9.4.2 <<>> nomade-frjo.stones.lan ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15760 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2
;; QUESTION SECTION: ;nomade-frjo.stones.lan. IN A
;; ANSWER SECTION: nomade-frjo.stones.lan. 900 IN A 192.168.0.242
;; AUTHORITY SECTION: stones.lan. 604800 IN NS emerald.stones.lan. stones.lan. 604800 IN NS diamond.stones.lan.
;; ADDITIONAL SECTION: diamond.stones.lan. 604800 IN A 192.168.0.1 emerald.stones.lan. 604800 IN A 192.168.0.2
;; Query time: 20 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Fri Mar 28 20:53:09 2008 ;; MSG SIZE rcvd: 131
$ dig -x 192.168.0.242 ; <<>> DiG 9.4.2 <<>> -x 192.168.0.242 ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37702 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2
;; QUESTION SECTION: ;242.0.168.192.in-addr.arpa. IN PTR
;; ANSWER SECTION: 242.0.168.192.in-addr.arpa. 900 IN PTR nomade-frjo.stones.lan.
;; AUTHORITY SECTION: 0.168.192.in-addr.arpa. 604800 IN NS diamond.stones.lan. 0.168.192.in-addr.arpa. 604800 IN NS emerald.stones.lan.
;; ADDITIONAL SECTION: diamond.stones.lan. 604800 IN A 192.168.0.1 emerald.stones.lan. 604800 IN A 192.168.0.2
;; Query time: 19 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Fri Mar 28 20:53:31 2008 ;; MSG SIZE rcvd: 155
nslookup
- Kind of slow but still useful.
$ nslookup etch Server: 192.168.0.1 Address: 192.168.0.1#53 Name: etch.example.com Address: 192.168.0.2
$ nslookup 192.168.0.2 Server: 192.168.0.1 Address: 192.168.0.1#53 2.0.168.192.in-addr.arpa name = etch.example.com.* named-checkconf : Verifies the syntax of the configuration files for Bind9.
# named-checkconf -z zone localhost/IN: loaded serial 1 zone 127.in-addr.arpa/IN: loaded serial 1 zone 0.in-addr.arpa/IN: loaded serial 1 zone 255.in-addr.arpa/IN: loaded serial 1 zone estar.lan/IN: loaded serial 20080315 zone 0.168.192.in-addr.arpa/IN: loaded serial 20080315 zone 10.in-addr.arpa/IN: loaded serial 1 zone 16.172.in-addr.arpa/IN: loaded serial 1 zone 17.172.in-addr.arpa/IN: loaded serial 1 zone 18.172.in-addr.arpa/IN: loaded serial 1 zone 19.172.in-addr.arpa/IN: loaded serial 1 zone 20.172.in-addr.arpa/IN: loaded serial 1 zone 21.172.in-addr.arpa/IN: loaded serial 1 zone 22.172.in-addr.arpa/IN: loaded serial 1 zone 23.172.in-addr.arpa/IN: loaded serial 1 zone 24.172.in-addr.arpa/IN: loaded serial 1 zone 25.172.in-addr.arpa/IN: loaded serial 1 zone 26.172.in-addr.arpa/IN: loaded serial 1 zone 27.172.in-addr.arpa/IN: loaded serial 1 zone 28.172.in-addr.arpa/IN: loaded serial 1 zone 29.172.in-addr.arpa/IN: loaded serial 1 zone 30.172.in-addr.arpa/IN: loaded serial 1 zone 31.172.in-addr.arpa/IN: loaded serial 1 zone 168.192.in-addr.arpa/IN: loaded serial 1* named-checkzone : Verifies the validity of zone files before resetting the configuration.
# named-checkzone example.com /var/lib/bind/db.example.com
zone example.com/IN: loaded serial 20080315 OK # named-checkzone 0.168.192.in-addr.arpa /var/lib/bind/db.example.com.inv zone 0.168.192.in-addr.arpa/IN: loaded serial 20080315 OK
Links and Resources
- rfc1035 - Implementation ans specifications
- rfc1591 - Domain Name System Structure and Delegation
- rfc2606 - Reserved Top Level DNS Names
- http://www.bind9.net/manual/bind/9.3.2/Bv9ARM - Bind 9 Administrator Manual
- Services Whois :
BIND9 - Slave-Server
Einleitung
A nameserver running BIND can be configured to serve each zone as either a master or a slave:
- A slave obtains its copy of the zone data by means of a zone transfer from another nameserver.
- A master obtains zone data from some other source, allowing it to operate independently of other nameservers.
Every zone should have at least two nameservers. Typical practice is to have one master, and one or two slaves which take their zone data from that master.
Tested on
- Debian (Lenny)
- Ubuntu (Lucid, Maverick)
Scenario
- Suppose that the zone example.com has two nameservers, ns0.example.com (198.51.100.1) and ns1.example.com (203.0.113.1).
- Of these, ns0 is already configured as a master. You wish to configure ns1 as a slave, taking its zone data from ns0.
- Both nameservers are running BIND version 9.
File locations
On Debian-based systems, zone declarations should be placed in the file /etc/bind/named.conf.local and options in the file /etc/bind/named.conf.options.
You should not modify /etc/bind/named.conf.
Slave zone files should be placed in /var/lib/bind (not /etc/bind) so that named has permission to write to them. Log messages are written to /var/log/daemon.log.
Vorgehen
There are three points to address if ns1 is to act as a slave to ns0:# ns1 must be configured to act as a slave nameserver for the zone.
- ns1 must be told when to perform a zone transfer. The preferred method for ns0 to send it a notification whenever a transfer is needed.
- ns0 must be configured to allow zone transfers to ns1.
For most purposes the default configuration of BIND would satisfy points 2 and 3, however it is good practice to configure it explicitly if you intend to rely on its behaviour.
Add slave zone declaration to ns1
The named configuration file must include a zone declaration for each zone to be served. Here is a suitable declaration for the zone example.com on ns1:
zone "example.com" {
type slave;
masters { 198.51.100.1; };
file "/var/lib/bind/db.example.com";
};
Setting the type to slave specifies that the zone data is obtained from another nameserver.
The masters statement contains a list of nameservers from which zone data can be obtained.
These need not be masters in the sense defined above: it is possible (and sometimes necessary) for a slave to obtain zone data from another slave.
Masters must be specified as IP addresses, not as domain names, however it is possible to define a ‘masters list’ containing the required addresses which can then be referred to symbolically (see below).
Zone files are optional for slave nameservers, but strongly recommended otherwise the slave will lose all knowledge of the zone content whenever it is restarted.
It will not then be able to start serving the zone again until it has performed a zone transfer, and if the master is unavailable for any reason then the period of downtime could be substantial.
Enable notifications from ns0
There are two ways to control when zone transfers take place:
- by polling at regular intervals, or
- by having the master notify the slave when the zone has changed.
The latter method is preferred as it is both quicker and more efficient.
BIND sends notifications by default, however it is good practice to enable them explicitly if they are an important part of the configuration. This can be done for individual zones:
zone "example.com" {
type master;
file "/var/lib/bind/db.example.com";
notify yes;
// …
};
or as the default for all zones:
options {
notify yes;
// …
};
The setting for a zone takes precedence, therefore if you use the latter method then you should check that it has not been overridden.
The master needs to know which nameservers to notify. By default it notifies the ones that have NS records, which for most purposes is sufficient.
Nameservers that do not have NS records can be notified by adding an also-notify statement. As previously this can be done either for an individual zone:
zone "example.com" {
type master;
notify yes;
also-notify { 203.0.113.1; };
file "/var/lib/bind/db.example.com";
};
or as the default for all zones:
options {
notify yes;
also-notify { 203.0.113.1; };
// …
};
Allow zone transfers on ns0
By default BIND allows zone transfers from anywhere. Opinion is divided as to whether this is good practice, and it is not unusual for a more restrictive policy to be imposed.
The servers that are allowed to perform transfers are specified in an allow-transfer statement. As with notifications this can be done either for an individual zone:
zone "example.com" {
type master;
notify yes;
allow-transfer { 203.0.113.1; };
file "/var/lib/bind/db.example.com";
};
or as the default for all zones:
options {
notify yes;
allow-transfer { 203.0.113.1; };
// …
};
If you are content for zone transfers to be unrestricted then you can make this explicit using an address of any:
options {
notify yes;
allow-transfer { any; };
// …
};
Reload ns0
If the configuration of ns0 has been changed in any way then it should be reloaded. * Cause a system service to reload its configurationhttp://www.microhowto.info/howto/cause_a_system_service_to_reload_its_configuration.html.
Reload ns1
The configuration of ns1 will have changed, so it will certainly need to be reloaded. This should be the last thing that you do (after reloading ns0 if necessary). * Cause a system service to reload its configurationhttp://www.microhowto.info/howto/cause_a_system_service_to_reload_its_configuration.html.
Testing
Is ns1 serving the zone?
You can test whether ns1 is operational by using the dig command to request the statement of authority record for the zone in question:
dig @203.0.113.1 -t SOA example.com +norecurs
The +norecurs flag at the end of the command instructs dig to perform a non-recursive query. The answer should be similar to the following:
;; ANSWER SECTION: example.com. 86400 IN SOA example.com. hostmaster.example.com. 41 28800 7200 604800 86400
Receiving the correct answer indicates that ns1 is functioning as a nameserver, but not necessarily that it is a slave for example.com: the answer could have been cached from a previous recursive query.
To tell the difference you should inspect the flags that are displayed near the start of the response:
;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42311 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2
The aa flag is the significant one. If ns1 is operating as a slave then the aa flag will be present, meaning that the answer is authoritative.
Check notifications
The initial zone transfer is not dependent on notifications, but subsequent ones are (unless you intend to rely on polling). To test whether they are working you will need to modify the zone on ns0 and check whether the change is replicated on ns1. The least invasive change you can make is to increment the serial number.
Edit the zone file on ns0 and locate the SOA record. This should look similar to:
@ IN SOA example.com. hostmaster.example.com. (
41
8H
2H
1W
1D)
The serial number in this record is 41, therefore you should increment it to 42:
@ IN SOA example.com. hostmaster.example.com. (
42
8H
2H
1W
1D)
Now reload the configuration of named on ns0 (see Cause a system service to reload its configuration). ns0 should notify ns1 that it has a copy of the zone with a serial number of 42.
The copy of the zone held by ns1 has an older serial number, 41, so when it receives the notification it should request a zone transfer.
You can determine whether this has happened by re-requesting the SOA record:
dig @203.0.113.1 -t SOA example.com +norecurs
If the serial number has changed to 42 then a zone transfer has occurred, which probably means that notifications are working:
;; ANSWER SECTION: example.com. 86400 IN SOA example.com. hostmaster.example.com. 42 28800 7200 604800 86400
For additional confidence that a notification caused the transfer you can either repeat the test or inspect the logs.
Troubleshooting
If the tests described above indicate that ns1 is not functioning as intended then you should attempt to answer the following questions:# Is named is running on ns0 as an authoritative nameserver for example.com?
- Is named is running on ns1?
- Has ns1 successfully performed an initial zone transfer, and if not why?
- Does ns0 notify ns1 when the zone serial number changes?
- Does ns1 perform further zone transfers when notified by ns0?
- Questions 1 to 3 are relevant when ns1 is not working as a nameserver at all. Questions 4 and 5 are relevant when it is working, but not responding to updates.
Is named running on ns0?
Before looking at ns1 it would be prudent to check that ns0 is working.
A good way to do this is to perform a remote query from ns0 to ns1 concerning the zone you are attempting to serve:
dig @198.51.100.1 -t SOA example.com
This should give an answer similar to the following:
;; ANSWER SECTION: example.com. 86400 IN SOA example.com. hostmaster.example.com. 41 28800 7200 604800 86400
The aa flag should be set, indicating that this is an authoritative response:
;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13518 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2
If either of these are missing then that would indicate ns0 is running as a nameserver, but is not authoritative for example.com.
The absence of any response at all could indicate that there is no nameserver running on ns0, or that there is a problem with network connectivity.
Whatever the reason, it will need to be addressed before the slave nameserver on ns1 can be properly tested.
Is named running on ns1?
You can check whether named is running using the ps command:
ps -C named
This should give a response of the form:
PID TTY TIME CMD 11409 ? 00:00:00 named
If no process is listed then you should try restarting named, then check again using ps. If it does not start then this may indicate that:
- there is a syntax error in one of the configuration files, or
- another process is listening on port 53.
The first of these is the more likely explanation. The log should contain enough information to identify the cause.
Did ns1 performed initial zone transfer?
You can check whether an initial zone transfer has occurred by looking for the zone file. This is the argument to the file statement in the zone declaration:
zone "example.com" {
type slave;
masters { 198.51.100.1; };
file "/var/lib/bind/db.example.com";
};
The file should have been created by named, and have content equivalent to (but probably not identical to) the master zone file on ns0.
If it has not been written then this could be because:
- ns1 has not requested a zone transfer, or
- ns1 sent the request to the wrong nameserver, or
- ns1 cannot communicate with ns1, or
- ns0 refused to transfer the zone, or
- ns1 received the zone data, but was unable to write the file.
You can check the first four points by viewing DNS traffic to and from ns1 using tcpdump:
tcpdump -n "host ns1.example.com and (udp port 53 or tcp port 53)"
You should see an initial query for the SOA record (normally UDP), followed by the zone transfer (always TCP).
If ns0 refused to transfer the zone then this should be recorded in the log on ns0, for example:
client 203.0.113.1#42541: zone transfer 'example.com/AXFR/IN' denied
If the transfer occurred but the file could not be written then this should be recorded in the log on ns1, for example:
dumping master file: /etc/bind/tmp-nIOVHD85JX: open: permission denied
See below for further consideration of these errors.
Dose ns0 notifies ns1?
You can check whether ns0 is notifying ns1 by using tcpdump to view the traffic:
tcpdump -n "host ns1.example.com and (udp port 53 or tcp port 53)"
A notification should look similar to:
198.51.100.1.3278 > 203.0.113.1.53: 62737 notify [b2&3=0x2400] [1a] SOA? example.com. (95) 203.0.113.1.53 > 198.51.100.1.3278: 62737 notify* 0/0/0 (29)
Notifications should also be logged by the sender:
zone example.com/IN: sending notifies (serial 42)
and by the receiver:
client 198.51.100.1#3278: received notify for zone 'example.com'
If notifications are not being sent or logged then you should check that they are enabled for the zone in question, and that ns1 is either:
- listed as a nameserver using an NS record in the master zone file, or
- listed in a also-notify statement in the master zone declaration.
Is ns1 performing zone transfers?
Subsequent zone transfers can be viewed in the same way as the initial transfer, but may be considerably smaller if you have enabled the use of incremental transfers.
The most likely reason for the slave not requesting a transfer when it has received a notification is if it already has a copy of the zone with the same or a more recent serial number.
In that case you should advance the serial number of the master zone file until it is greater than that of the slave zone file.
Fehlermeldungen
Zone transfer denied
An error of the form:
client 203.0.113.1#42541: zone transfer 'example.com/AXFR/IN' denied
on ns0 indicates that zone transfers have been restricted to a specific list of nameservers and that ns1 is not one of them. You should look for a relevant allow-transfer statement in the configuration of ns0 and add ns1 to the list.
Dumping master file: permission denied
An error of the form:
dumping master file: /etc/bind/tmp-nIOVHD85JX: open: permission denied
on ns1 indicates that named has successfully performed a zone transfer, but was unable to write the result to a zone file because it did not have permission to write to the relevant directory.
In this particular case it has been incorrectly configured to write the zone file to /etc/bind.
You should not attempt to fix this by granting write access to that directory: there are good security reasons why named should only have read access to its configuration.
Instead you should write the zone file to some other location. On Debian-based systems, the appropriate location is /var/lib/bind.
Variationen
Use a masters list
If it is necessary to refer to the same master nameserver(s) repeatedly then it is good practice to define a ‘masters list’ containing the relevant IP address(es) so that they can be referred to symbolically.
For example:
masters ns0 { 198.51.100.1; };
zone "example.com" {
type slave;
masters { ns0; };
notify no;
file "/var/lib/bind/zone.example.com";
};
zone "example.net" {
type slave;
masters { ns0; };
notify no;
file "/var/lib/bind/zone.example.net";
};
Doing this reduces the risk of specifying the wrong IP address, and simplifies the task of changing the address should this ever be necessary.