Zum Inhalt springen

BIND/Slave: Unterschied zwischen den Versionen

Aus Foxwiki
Versionsgeschichte interaktiv durchsuchen
VisuellWikitext
Die Seite wurde neu angelegt: „== 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 slave…“
 
 
(47 dazwischenliegende Versionen von 2 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
== BIND9 - Slave-Server ==
'''BIND/Slave''' - Konfiguration eines [[DNS]]-Servers
=== 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.
== Einleitung ==
Ein Nameserver mit BIND kann so konfiguriert werden, dass jede Zone entweder als Master- oder als Slave-Zone bereitgestellt wird
* Ein Slave erhält seine Kopie der Zonendaten per Zonenübertragung von einem anderen Nameserver
* Ein Master bezieht die Zonendaten aus einer unabhängigen Quelle und ist daher nicht auf andere Nameserver angewiesen


==== Tested on ====
Für jede Zone wird der Betrieb von mindestens zwei Nameservern empfohlen
* Debian (Lenny)
* Typischerweise existiert ein Master sowie ein oder zwei Slaves, die ihre Zonendaten vom Master übernehmen
* Ubuntu (Lucid, Maverick)


==== Scenario ====
=== Szenario ===
* Suppose that the zone <tt>example.com</tt> has two nameservers, <tt>ns0.example.com</tt> (198.51.100.1) and <tt>ns1.example.com</tt> (203.0.113.1).
{| class="wikitable options big"
* Of these, <tt>ns0</tt> is already configured as a master. You wish to configure <tt>ns1</tt> as a slave, taking its zone data from <tt>ns0</tt>.
|-
* Both nameservers are running BIND version&nbsp;9.
! !! Name !! Beschreibung
|-
| Zone || example.com || mit zwei Nameservern
|-
| Master || master.example.com || 192.168.0.100
|-
| Slave || slave.example.com || 192.168.0.200
|}


==== File locations ====
* Master für ''example.com'' konfiguriert
On Debian-based systems, zone declarations should be placed in the file <tt>/etc/bind/named.conf.local</tt> and options in the file <tt>/etc/bind/named.conf.options</tt>.
* Slave konfigurieren, Zonendaten von Master beziehen


You should not modify <tt>/etc/bind/named.conf</tt>.
=== Dateispeicherorte ===
Debian-basiert
{| class="wikitable options big"
! Zweck !! Pfad
|-
| Zonendeklarationen || '''''/etc/bind/named.conf.local'''''
|-
| Globale Optionen || '''''/etc/bind/named.conf.options'''''
|-
| Hauptdatei von BIND (nicht ändern) || '''''/etc/bind/named.conf'''''
|-
| Slave-Zonendateien (schreibbar für ''named'') || '''''/var/lib/bind'''''
|-
| Protokollmeldungen || '''''/var/log/daemon.log'''''
|}


Slave zone files should be placed in <tt>/var/lib/bind</tt> (not <tt>/etc/bind</tt>) so that <tt>named</tt> has permission to write to them. Log messages are written to <tt>/var/log/daemon.log</tt>.
== Vorgehen ==
Für den Betrieb von ''slave'' als Slave von ''master'' sind drei Aspekte relevant
# ''slave'' wird als Slave-Nameserver für die Zone konfiguriert
# ''slave'' muss erkennen können, wann eine Zonenübertragung erforderlich ist. Bevorzugt sendet ''master'' hierzu eine NOTIFY-Benachrichtigung
# ''master'' wird so konfiguriert, dass Zonenübertragungen (AXFR/IXFR) nach ''slave'' zulässig sind


=== Vorgehen ===
=== Zone-Deklaration ===
There are three points to address if <tt>ns1</tt> is to act as a slave to <tt>ns0</tt>:# <tt>ns1</tt> must be configured to act as a slave nameserver for the zone.
; Slave-Zone-Deklaration
# <tt>ns1</tt> must be told when to perform a zone transfer. The preferred method for <tt>ns0</tt> to send it a notification whenever a transfer is needed.
In der ''named''-Konfiguration ist für jede bereitgestellte Zone eine Zonendeklaration erforderlich
# <tt>ns0</tt> must be configured to allow zone transfers to <tt>ns1</tt>.
* Für ''slave'' als Slave für die Zone ''example.com'' kann beispielsweise folgende Deklaration verwendet werden


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.
<syntaxhighlight lang="bash" copy line>
zone "example.com" {
  type slave;
  masters { 192.168.0.100; };
  file "/var/lib/bind/db.example.com";
};
</syntaxhighlight>


==== Add slave zone declaration to ns1 ====
{| class="wikitable options big"
The <tt>named</tt> configuration file must include a zone declaration for each zone to be served. Here is a suitable declaration for the zone <tt>example.com</tt> on <tt>ns1</tt>:
! Parameter
! Beschreibung
|-
| type slave;
| Legt fest, dass die Zonendaten von einem anderen Nameserver per Zonenübertragung bezogen werden
|-
| masters { 192.168.0.100; };
| Definiert eine Liste von Nameservern, von denen Zonendaten bezogen werden können
* Ein Slave kann seine Daten auch von einem anderen Slave übernehmen.<br>Werden IP-Adressen und nicht Domainnamen angegeben
|-
| file "/var/lib/bind/db.example.com";
| Gibt den Speicherort der lokalen Kopie der Zonendaten auf ''slave'' an
* Die Zonendatei für den Slave-Nameserver ist nicht obligatorisch, aber ohne sie verliert der untergeordnete Server beim Neustart den Inhalt der Zone
|}


zone "example.com" {
; Hinweis
  type slave;
Es ist auch möglich, die Liste „masters“ im Voraus festzulegen.
  masters { 198.51.100.1; };
  file "/var/lib/bind/db.example.com";
};


Setting the <tt>type</tt> to <tt>slave</tt> specifies that the zone data is obtained from another nameserver.


The <tt>masters</tt> statement contains a list of nameservers from which zone data can be obtained.
<syntaxhighlight lang="bash" copy line>
masters masterslist {
    192.168.0.100;  # master1.example.com
    192.168.0.101;  # master2.example.net
};
</syntaxhighlight>


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.
Danach muss diese Liste in der Anweisung ''masters'' bekannt gegeben werden
<syntaxhighlight lang="bash" copy line>
zone "example.com" {
  type slave;
  masters { masterslist; };
  file "/var/lib/bind/db.example.com";
};
</syntaxhighlight>


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).
=== Benachrichtigungen ===
; Benachrichtigungen von master aktivieren
; Zone-Übertragungsintervall
Zeitpunkte für Zonenübertragungen lassen sich im Wesentlichen auf zwei Arten steuern
* regelmäßiges Abfragen (Polling) durch den Slave
* Benachrichtigung des Slave durch den Master, sobald sich die Zone geändert hat (NOTIFY)


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.
Die Benachrichtigung durch den Master ist in der Praxis schneller und ressourcenschonender


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.
; Einstellung NOTIFY
BIND sendet standardmäßig NOTIFY-Benachrichtigungen
* Wenn NOTIFY ein wesentlicher Bestandteil der Konfiguration ist, wird eine explizite Aktivierung empfohlen
* Dies kann zonenweise erfolgen


==== Enable notifications from ns0 ====
<syntaxhighlight lang="bash" copy line>
There are two ways to control when zone transfers take place:
zone "example.com" {
* by polling at regular intervals, or
  type master;
* by having the master notify the slave when the zone has changed.
  file "/var/lib/bind/db.example.com";
  notify yes;
  // …
};
</syntaxhighlight>


The latter method is preferred as it is both quicker and more efficient.
: oder global für alle Zonen


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:
<syntaxhighlight lang="bash" copy line>
options {
  notify yes;
  // …
};
</syntaxhighlight>


zone "example.com" {
; Einstellungen innerhalb einer Zonendeklaration haben Vorrang vor globalen Vorgaben in der Sektion ''options''
  type master;
  file "/var/lib/bind/db.example.com";
  notify yes;
  // …
};


or as the default for all zones:
Damit NOTIFY sinnvoll arbeitet, muss der Master wissen, welche Nameserver benachrichtigt werden sollen
* Standardmäßig benachrichtigt BIND diejenigen Nameserver, für die ''NS''-Resource-Records existieren
* Für zusätzliche Empfänger wird die Direktive ''also-notify'' verwendet
* Diese kann für eine einzelne Zone gesetzt werden


options {
<syntaxhighlight lang="bash" copy line>
  notify yes;
zone "example.com" {
  // …
  type master;
};
  notify yes;
  also-notify { 192.168.0.200; };
  file "/var/lib/bind/db.example.com";
};
</syntaxhighlight>


The setting for a zone takes precedence, therefore if you use the latter method then you should check that it has not been overridden.
oder global


The master needs to know which nameservers to notify. By default it notifies the ones that have <tt>NS</tt> records, which for most purposes is sufficient.
<syntaxhighlight lang="bash" copy line>
options {
  notify yes;
  also-notify { 192.168.0.200; };
  // …
};
</syntaxhighlight>


Nameservers that do not have <tt>NS</tt> records can be notified by adding an <tt>also-notify</tt> statement. As previously this can be done either for an individual zone:
Wichtige Punkte im Überblick
* ''notify yes;'' aktiviert NOTIFY-Benachrichtigungen
* ''also-notify { …; };'' ergänzt die Standardliste der Empfänger, die über ''NS''-Resource-Records definiert ist
* ''also-notify'' eignet sich insbesondere für Nameserver, die nicht im öffentlichen ''NS''-Satz der Zone aufgeführt werden sollen (z. B. versteckte Master oder zusätzliche Slaves)


zone "example.com" {
=== Zonenübertragungen ===
  type master;
; Zonenübertragungen auf master erlauben
  notify yes;
Standardmäßig erlaubt BIND Zonenübertragungen von beliebigen Adressen
  also-notify { 203.0.113.1; };
* Es wird empfohlen, strengere Richtlinien anzuwenden
  file "/var/lib/bind/db.example.com";
};


or as the default for all zones:
Die zugelassenen Empfänger werden mit der Direktive '''''allow-transfer''''' definiert


options {
; Einzelne Zone
  notify yes;
<syntaxhighlight lang="bash" copy line>
  also-notify { 203.0.113.1; };
zone "example.com" {
  // …
  type master;
};
  notify yes;
  allow-transfer { 192.168.0.200; };
  file "/var/lib/bind/db.example.com";
};
</syntaxhighlight>


==== Allow zone transfers on ns0  ====
; Global
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.
Für alle Zonen
<syntaxhighlight lang="bash" highlight="" copy line>
options {
  notify yes;
  allow-transfer { 192.168.0.200; };
  // …
};
</syntaxhighlight>


The servers that are allowed to perform transfers are specified in an <tt>allow-transfer</tt> statement. As with notifications this can be done either for an individual zone:
Die Angabe ''allow-transfer { 192.168.0.200; };'' beschränkt Zonenübertragungen auf den Nameserver mit der IP-Adresse 192.168.0.200


zone "example.com" {
Wenn Zonenübertragungen nicht eingeschränkt werden sollen, kann dies explizit mit dem Schlüsselwort ''any'' ausgedrückt werden
  type master;
  notify yes;
  allow-transfer { 203.0.113.1; };
  file "/var/lib/bind/db.example.com";
};


or as the default for all zones:
<syntaxhighlight lang="bash" highlight="" copy line>
 
options {
options {
  notify yes;
  notify yes;
  allow-transfer { any; };
  allow-transfer { 203.0.113.1; };
  // …
  // …
};
};
</syntaxhighlight>
 
If you are content for zone transfers to be unrestricted then you can make this explicit using an address of <tt>any</tt>:
 
options {
  notify yes;
  allow-transfer { any; };
  // …
};
 
==== Reload ns0 ====
If the configuration of <tt>ns0</tt> has been changed in any way then it should be reloaded. * [http://www.microhowto.info/howto/cause_a_system_service_to_reload_its_configuration.html Cause a system service to reload its configuration]http://www.microhowto.info/howto/cause_a_system_service_to_reload_its_configuration.html.
 
==== Reload ns1 ====
The configuration of <tt>ns1</tt> will have changed, so it will certainly need to be reloaded. This should be the last thing that you do (after reloading <tt>ns0</tt> if necessary). * [http://www.microhowto.info/howto/cause_a_system_service_to_reload_its_configuration.html Cause a system service to reload its configuration]http://www.microhowto.info/howto/cause_a_system_service_to_reload_its_configuration.html.
 
=== Testing ===
==== Is ns1 serving the zone? ====
You can test whether <tt>ns1</tt> is operational by using the <tt>dig</tt> command to request the statement of authority record for the zone in question:
 
dig @203.0.113.1 -t SOA example.com +norecurs
 
The <tt>+norecurs</tt> flag at the end of the command instructs <tt>dig</tt> to perform a non-recursive query. The answer should be similar to the following:
 
<nowiki>;; ANSWER SECTION:</nowiki>
example.com.            86400  IN      SOA    example.com. hostmaster.example.com. 41 28800 7200 604800 86400
 
Receiving the correct answer indicates that <tt>ns1</tt> is functioning as a nameserver, but not necessarily that it is a slave for <tt>example.com</tt>: the answer could have been cached from a previous recursive query.
 
To tell the difference you should inspect the flags that are displayed near the start of the response:
 
<nowiki>;; Got answer:</nowiki>
<nowiki>;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42311</nowiki>
<nowiki>;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2</nowiki>
 
The <tt>aa</tt> flag is the significant one. If <tt>ns1</tt> is operating as a slave then the <tt>aa</tt> flag will be present, meaning that the answer is authoritative.


==== Check notifications  ====
In diesem Fall sind Zonenübertragungen für beliebige Clients zulässig
The initial zone transfer is not dependent on notifications, but subsequent ones are (unless you intend to rely on polling). To test whether they are working you will need to modify the zone on <tt>ns0</tt> and check whether the change is replicated on <tt>ns1</tt>. The least invasive change you can make is to increment the serial number.
* Ob dies sinnvoll ist, hängt von den Sicherheitsanforderungen der jeweiligen Umgebung ab


Edit the zone file on <tt>ns0</tt> and locate the SOA record. This should look similar to:
=== Neustart der Dienste ===
Sie müssen den Bind-Dienst auf master und slave nacheinander mit dem folgenden Befehl neu starten


@      IN      SOA    example.com. hostmaster.example.com. (
<syntaxhighlight lang="bash" highlight="1" copy line>
                        41
rndc reload
                        8H
</syntaxhighlight>
                        2H
                        1W
                        1D)


The serial number in this record is 41, therefore you should increment it to 42:
== Test ==
=== Slave-Server ===
Die Funktionsfähigkeit von ''slave'' lässt sich über eine SOA-Abfrage mit ''dig'' prüfen


@       IN      SOA    example.com. hostmaster.example.com. (
<syntaxhighlight lang="bash" highlight="1" copy line>
                        42
dig @192.168.0.200 -t SOA example.com +norecurs
                        8H
</syntaxhighlight>
                        2H
                        1W
                        1D)


Now reload the configuration of <tt>named</tt> on <tt>ns0</tt> (see [http://www.microhowto.info/howto/cause_a_system_service_to_reload_its_configuration.html Cause a system service to reload its configuration]). <tt>ns0</tt> should notify <tt>ns1</tt> that it has a copy of the zone with a serial number of 42.
Der Parameter ''+norecurs'' erzwingt eine nicht-rekursive Abfrage
* Eine korrekte SOA-Antwort zeigt, dass der Server als autoritativer Nameserver antwortet
* Das allein bestätigt jedoch nicht den Slave-Status, da die Daten aus einem Cache stammen können


The copy of the zone held by <tt>ns1</tt> has an older serial number, 41, so when it receives the notification it should request a zone transfer.
Zur Unterscheidung müssen die Flags im Header analysiert werden


You can determine whether this has happened by re-requesting the SOA record:
<syntaxhighlight lang="console" line>
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2
</syntaxhighlight>


dig @203.0.113.1 -t SOA example.com +norecurs
Das relevante Flag ist ''aa''
* Ist es gesetzt, stammt die Antwort aus der autoritativen Zone von ''slave''
* Ein gesetztes ''aa'' zeigt damit in der Regel an, dass der Slave die Zone geladen hat


If the serial number has changed to 42 then a zone transfer has occurred, which probably means that notifications are working:
=== Benachrichtigungen ===
Die erste Zonenübertragung erfolgt unabhängig von Benachrichtigungen, spätere Übertragungen benötigen jedoch funktionierendes NOTIFY (sofern kein Polling verwendet wird)


<nowiki>;; ANSWER SECTION:</nowiki>
Für einen Test wird auf ''master'' die Seriennummer im SOA-Eintrag erhöht
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.
<syntaxhighlight lang="ini" line>
@  IN  SOA example.com. hostmaster.example.com. (
        41
        8H
        2H
        1W
        1D )
</syntaxhighlight>


=== Troubleshooting ===
Die Seriennummer wird beispielsweise auf 42 gesetzt
If the tests described above indicate that <tt>ns1</tt> is not functioning as intended then you should attempt to answer the following questions:# Is <tt>named</tt> is running on <tt>ns0</tt> as an authoritative nameserver for <tt>example.com</tt>?
# Is <tt>named</tt> is running on <tt>ns1</tt>?
# Has <tt>ns1</tt> successfully performed an initial zone transfer, and if not why?
# Does <tt>ns0</tt> notify <tt>ns1</tt> when the zone serial number changes?
# Does <tt>ns1</tt> perform further zone transfers when notified by <tt>ns0</tt>?
# Questions 1 to 3 are relevant when <tt>ns1</tt> is not working as a nameserver at all. Questions 4 and 5 are relevant when it is working, but not responding to updates.


==== Is named running on ns0? ====
<syntaxhighlight lang="ini" line>
Before looking at <tt>ns1</tt> it would be prudent to check that <tt>ns0</tt> is working.
@  IN  SOA example.com. hostmaster.example.com. (
        42
        8H
        2H
        1W
        1D )
</syntaxhighlight>


A good way to do this is to perform a remote query from <tt>ns0</tt> to <tt>ns1</tt> concerning the zone you are attempting to serve:
Anschließend wird die Konfiguration von ''named'' auf ''master'' neu geladen
* Nach dem Reload sendet ''master'' eine Benachrichtigung an ''slave''
* Da die lokale Kopie auf ''slave'' noch die ältere Seriennummer besitzt, sollte eine erneute Zonenübertragung ausgelöst werden


dig @198.51.100.1 -t SOA example.com
Die erfolgreiche Replikation lässt sich erneut durch eine SOA-Abfrage prüfen


This should give an answer similar to the following:
<syntaxhighlight lang="bash" highlight="1" copy line>
dig @192.168.0.200 -t SOA example.com +norecurs
</syntaxhighlight>


<nowiki>;; ANSWER SECTION:</nowiki>
Erscheint die Seriennummer 42, wurde die Zone übertragen
example.com.            86400  IN      SOA    example.com. hostmaster.example.com. 41 28800 7200 604800 86400


The <tt>aa</tt> flag should be set, indicating that this is an authoritative response:
<syntaxhighlight lang="console" line>
ANSWER SECTION
example.com. 86400 IN SOA example.com. hostmaster.example.com. 42 28800 7200 604800 86400
</syntaxhighlight>


<nowiki>;; Got answer:</nowiki>
* Für zusätzliche Sicherheit kann der Test mehrfach wiederholt werden
<nowiki>;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13518</nowiki>
* Alternativ lässt sich der Ablauf über die Serverprotokolle nachvollziehen
<nowiki>;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2</nowiki>


If either of these are missing then that would indicate <tt>ns0</tt> is running as a nameserver, but is not authoritative for <tt>example.com</tt>.
<noinclude>


The absence of any response at all could indicate that there is no nameserver running on <tt>ns0</tt>, or that there is a problem with network connectivity.
= Anhang =
== Siehe auch ==
<div style="column-count:2">
<categorytree hideroot=on mode="pages">{{BASEPAGENAME}}</categorytree>
</div>
----
{{Special:PrefixIndex/{{BASEPAGENAME}}/}}


Whatever the reason, it will need to be addressed before the slave nameserver on <tt>ns1</tt> can be properly tested.
== Dokumentation ==
<!--
; Man-Page
# [https://manpages.debian.org/stable/procps/pgrep.1.de.html prep(1)]


==== Is named running on ns1? ====
; Info-Pages
You can check whether <tt>named</tt> is running using the <tt>ps</tt> command:
-->


ps -C named
== Links ==
=== Projekt ===
=== Weblinks ===


This should give a response of the form:


  PID TTY          TIME CMD
[[Kategorie:BIND]]
11409 ?        00:00:00 named
 
If no process is listed then you should try restarting <tt>named</tt>, then check again using <tt>ps</tt>. If it does not start then this may indicate that:
* there is a syntax error in one of the configuration files, or
* another process is listening on port 53.
 
The first of these is the more likely explanation. The log should contain enough information to identify the cause.
 
==== Did ns1 performed initial zone transfer? ====
You can check whether an initial zone transfer has occurred by looking for the zone file. This is the argument to the <tt>file</tt> statement in the zone declaration:
 
zone "example.com" {
  type slave;
  masters { 198.51.100.1; };
  file "/var/lib/bind/db.example.com";
};
 
The file should have been created by <tt>named</tt>, and have content equivalent to (but probably not identical to) the master zone file on <tt>ns0</tt>.
 
===== If it has not been written then this could be because: =====
* <tt>ns1</tt> has not requested a zone transfer, or
* <tt>ns1</tt> sent the request to the wrong nameserver, or
* <tt>ns1</tt> cannot communicate with <tt>ns1</tt>, or
* <tt>ns0</tt> refused to transfer the zone, or
* <tt>ns1</tt> received the zone data, but was unable to write the file.
 
You can check the first four points by viewing DNS traffic to and from <tt>ns1</tt> using <tt>tcpdump</tt>:
 
tcpdump -n "host ns1.example.com and (udp port 53 or tcp port 53)"
 
You should see an initial query for the SOA record (normally UDP), followed by the zone transfer (always TCP).
 
If <tt>ns0</tt> refused to transfer the zone then this should be recorded in the log on <tt>ns0</tt>, for example:
 
client 203.0.113.1#42541: zone transfer 'example.com/AXFR/IN' denied
 
If the transfer occurred but the file could not be written then this should be recorded in the log on <tt>ns1</tt>, for example:
 
dumping master file: /etc/bind/tmp-nIOVHD85JX: open: permission denied
 
See below for further consideration of these errors.
 
==== Dose ns0 notifies ns1? ====
You can check whether <tt>ns0</tt> is notifying <tt>ns1</tt> by using <tt>tcpdump</tt> to view the traffic:
 
tcpdump -n "host ns1.example.com and (udp port 53 or tcp port 53)"
 
A notification should look similar to:
 
198.51.100.1.3278 > 203.0.113.1.53: 62737 notify [b2&3=0x2400] [1a] SOA? example.com. (95)
203.0.113.1.53 > 198.51.100.1.3278: 62737 notify* 0/0/0 (29)
 
Notifications should also be logged by the sender:
 
zone example.com/IN: sending notifies (serial 42)
 
and by the receiver:
 
client 198.51.100.1#3278: received notify for zone 'example.com'
 
If notifications are not being sent or logged then you should check that they are enabled for the zone in question, and that <tt>ns1</tt> is either:
* listed as a nameserver using an <tt>NS</tt> record in the master zone file, or
* listed in a <tt>also-notify</tt> statement in the master zone declaration.
 
==== Is ns1 performing zone transfers? ====
Subsequent zone transfers can be viewed in the same way as the initial transfer, but may be considerably smaller if you have enabled the use of incremental transfers.
 
The most likely reason for the slave not requesting a transfer when it has received a notification is if it already has a copy of the zone with the same or a more recent serial number.
 
In that case you should advance the serial number of the master zone file until it is greater than that of the slave zone file.
 
=== Fehlermeldungen ===
==== Zone transfer denied ====
An error of the form:
 
client 203.0.113.1#42541: zone transfer 'example.com/AXFR/IN' denied
 
on <tt>ns0</tt> indicates that zone transfers have been restricted to a specific list of nameservers and that <tt>ns1</tt> is not one of them. You should look for a relevant <tt>allow-transfer</tt> statement in the configuration of <tt>ns0</tt> and add <tt>ns1</tt> to the list.
 
==== Dumping master file: permission denied ====
An error of the form:
 
dumping master file: /etc/bind/tmp-nIOVHD85JX: open: permission denied
 
on <tt>ns1</tt> indicates that <tt>named</tt> has successfully performed a zone transfer, but was unable to write the result to a zone file because it did not have permission to write to the relevant directory.
 
In this particular case it has been incorrectly configured to write the zone file to <tt>/etc/bind</tt>.
 
You should not attempt to fix this by granting write access to that directory: there are good security reasons why <tt>named</tt> should only have read access to its configuration.
 
Instead you should write the zone file to some other location. On Debian-based systems, the appropriate location is <tt>/var/lib/bind</tt>.
 
=== Variationen ===
==== Use a masters list ====
If it is necessary to refer to the same master nameserver(s) repeatedly then it is good practice to define a ‘masters list’ containing the relevant IP address(es) so that they can be referred to symbolically.
 
For example:
 
masters ns0 { 198.51.100.1; };
 
zone "example.com" {
        type slave;
        masters { ns0; };
        notify no;
        file "/var/lib/bind/zone.example.com";
};
 
zone "example.net" {
        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.
</noinclude>

Aktuelle Version vom 21. November 2025, 10:59 Uhr

BIND/Slave - Konfiguration eines DNS-Servers

Einleitung

Ein Nameserver mit BIND kann so konfiguriert werden, dass jede Zone entweder als Master- oder als Slave-Zone bereitgestellt wird

  • Ein Slave erhält seine Kopie der Zonendaten per Zonenübertragung von einem anderen Nameserver
  • Ein Master bezieht die Zonendaten aus einer unabhängigen Quelle und ist daher nicht auf andere Nameserver angewiesen

Für jede Zone wird der Betrieb von mindestens zwei Nameservern empfohlen

  • Typischerweise existiert ein Master sowie ein oder zwei Slaves, die ihre Zonendaten vom Master übernehmen

Szenario

Name Beschreibung
Zone example.com mit zwei Nameservern
Master master.example.com 192.168.0.100
Slave slave.example.com 192.168.0.200
  • Master für example.com konfiguriert
  • Slave konfigurieren, Zonendaten von Master beziehen

Dateispeicherorte

Debian-basiert

Zweck Pfad
Zonendeklarationen /etc/bind/named.conf.local
Globale Optionen /etc/bind/named.conf.options
Hauptdatei von BIND (nicht ändern) /etc/bind/named.conf
Slave-Zonendateien (schreibbar für named) /var/lib/bind
Protokollmeldungen /var/log/daemon.log

Vorgehen

Für den Betrieb von slave als Slave von master sind drei Aspekte relevant

  1. slave wird als Slave-Nameserver für die Zone konfiguriert
  2. slave muss erkennen können, wann eine Zonenübertragung erforderlich ist. Bevorzugt sendet master hierzu eine NOTIFY-Benachrichtigung
  3. master wird so konfiguriert, dass Zonenübertragungen (AXFR/IXFR) nach slave zulässig sind

Zone-Deklaration

Slave-Zone-Deklaration

In der named-Konfiguration ist für jede bereitgestellte Zone eine Zonendeklaration erforderlich

  • Für slave als Slave für die Zone example.com kann beispielsweise folgende Deklaration verwendet werden
zone "example.com" {
  type slave;
  masters { 192.168.0.100; };
  file "/var/lib/bind/db.example.com";
};
Parameter Beschreibung
type slave; Legt fest, dass die Zonendaten von einem anderen Nameserver per Zonenübertragung bezogen werden
masters { 192.168.0.100; }; Definiert eine Liste von Nameservern, von denen Zonendaten bezogen werden können
  • Ein Slave kann seine Daten auch von einem anderen Slave übernehmen.
    Werden IP-Adressen und nicht Domainnamen angegeben
file "/var/lib/bind/db.example.com"; Gibt den Speicherort der lokalen Kopie der Zonendaten auf slave an
  • Die Zonendatei für den Slave-Nameserver ist nicht obligatorisch, aber ohne sie verliert der untergeordnete Server beim Neustart den Inhalt der Zone
Hinweis

Es ist auch möglich, die Liste „masters“ im Voraus festzulegen. 


masters masterslist {
    192.168.0.100;  # master1.example.com
    192.168.0.101;  # master2.example.net
};

Danach muss diese Liste in der Anweisung masters bekannt gegeben werden 

zone "example.com" {
  type slave;
  masters { masterslist; };
  file "/var/lib/bind/db.example.com";
};

Benachrichtigungen

Benachrichtigungen von master aktivieren
Zone-Übertragungsintervall

Zeitpunkte für Zonenübertragungen lassen sich im Wesentlichen auf zwei Arten steuern

  • regelmäßiges Abfragen (Polling) durch den Slave
  • Benachrichtigung des Slave durch den Master, sobald sich die Zone geändert hat (NOTIFY)

Die Benachrichtigung durch den Master ist in der Praxis schneller und ressourcenschonender

Einstellung NOTIFY

BIND sendet standardmäßig NOTIFY-Benachrichtigungen

  • Wenn NOTIFY ein wesentlicher Bestandteil der Konfiguration ist, wird eine explizite Aktivierung empfohlen
  • Dies kann zonenweise erfolgen
zone "example.com" {
  type master;
  file "/var/lib/bind/db.example.com";
  notify yes;
  // …
};
oder global für alle Zonen
options {
  notify yes;
  // …
};
Einstellungen innerhalb einer Zonendeklaration haben Vorrang vor globalen Vorgaben in der Sektion options

Damit NOTIFY sinnvoll arbeitet, muss der Master wissen, welche Nameserver benachrichtigt werden sollen

  • Standardmäßig benachrichtigt BIND diejenigen Nameserver, für die NS-Resource-Records existieren
  • Für zusätzliche Empfänger wird die Direktive also-notify verwendet
  • Diese kann für eine einzelne Zone gesetzt werden
zone "example.com" {
  type master;
  notify yes;
  also-notify { 192.168.0.200; };
  file "/var/lib/bind/db.example.com";
};

oder global 

options {
  notify yes;
  also-notify { 192.168.0.200; };
  // …
};

Wichtige Punkte im Überblick

  • notify yes; aktiviert NOTIFY-Benachrichtigungen
  • also-notify { …; }; ergänzt die Standardliste der Empfänger, die über NS-Resource-Records definiert ist
  • also-notify eignet sich insbesondere für Nameserver, die nicht im öffentlichen NS-Satz der Zone aufgeführt werden sollen (z. B. versteckte Master oder zusätzliche Slaves)

Zonenübertragungen

Zonenübertragungen auf master erlauben

Standardmäßig erlaubt BIND Zonenübertragungen von beliebigen Adressen

  • Es wird empfohlen, strengere Richtlinien anzuwenden

Die zugelassenen Empfänger werden mit der Direktive allow-transfer definiert

Einzelne Zone
zone "example.com" {
  type master;
  notify yes;
  allow-transfer { 192.168.0.200; };
  file "/var/lib/bind/db.example.com";
};
Global

Für alle Zonen 

options {
  notify yes;
  allow-transfer { 192.168.0.200; };
  // …
};

Die Angabe allow-transfer { 192.168.0.200; }; beschränkt Zonenübertragungen auf den Nameserver mit der IP-Adresse 192.168.0.200

Wenn Zonenübertragungen nicht eingeschränkt werden sollen, kann dies explizit mit dem Schlüsselwort any ausgedrückt werden 

options {
  notify yes;
  allow-transfer { any; };
  // …
};

In diesem Fall sind Zonenübertragungen für beliebige Clients zulässig

  • Ob dies sinnvoll ist, hängt von den Sicherheitsanforderungen der jeweiligen Umgebung ab

Neustart der Dienste

Sie müssen den Bind-Dienst auf master und slave nacheinander mit dem folgenden Befehl neu starten 

rndc reload

Test

Slave-Server

Die Funktionsfähigkeit von slave lässt sich über eine SOA-Abfrage mit dig prüfen 

dig @192.168.0.200 -t SOA example.com +norecurs

Der Parameter +norecurs erzwingt eine nicht-rekursive Abfrage

  • Eine korrekte SOA-Antwort zeigt, dass der Server als autoritativer Nameserver antwortet
  • Das allein bestätigt jedoch nicht den Slave-Status, da die Daten aus einem Cache stammen können

Zur Unterscheidung müssen die Flags im Header analysiert werden 

;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2

Das relevante Flag ist aa

  • Ist es gesetzt, stammt die Antwort aus der autoritativen Zone von slave
  • Ein gesetztes aa zeigt damit in der Regel an, dass der Slave die Zone geladen hat

Benachrichtigungen

Die erste Zonenübertragung erfolgt unabhängig von Benachrichtigungen, spätere Übertragungen benötigen jedoch funktionierendes NOTIFY (sofern kein Polling verwendet wird)

Für einen Test wird auf master die Seriennummer im SOA-Eintrag erhöht 

@   IN  SOA example.com. hostmaster.example.com. (
        41
        8H
        2H
        1W
        1D )

Die Seriennummer wird beispielsweise auf 42 gesetzt 

@   IN  SOA example.com. hostmaster.example.com. (
        42
        8H
        2H
        1W
        1D )

Anschließend wird die Konfiguration von named auf master neu geladen

  • Nach dem Reload sendet master eine Benachrichtigung an slave
  • Da die lokale Kopie auf slave noch die ältere Seriennummer besitzt, sollte eine erneute Zonenübertragung ausgelöst werden

Die erfolgreiche Replikation lässt sich erneut durch eine SOA-Abfrage prüfen 

dig @192.168.0.200 -t SOA example.com +norecurs

Erscheint die Seriennummer 42, wurde die Zone übertragen 

ANSWER SECTION
example.com. 86400 IN SOA example.com. hostmaster.example.com. 42 28800 7200 604800 86400
  • Für zusätzliche Sicherheit kann der Test mehrfach wiederholt werden
  • Alternativ lässt sich der Ablauf über die Serverprotokolle nachvollziehen


Anhang

Siehe auch


Dokumentation

Links

Projekt

Weblinks


Abgerufen von „https://wiki.foxtom.de/index.php?title=BIND/Slave&oldid=158439“