• This forum has a zero tolerance policy regarding spam. If you register here to publish advertising, your user account will be deleted without further questions.

[HowTo] Bind9 Secondary DNS

byteheads.de

New Member
In dieser Anleitung möchte ich in einfachen Schritten erklären wie man einen ISP-ähnlichen Sekundären DNS Server mit Bind9 aufsetzt. Weiter setzt diese Anleitung auf dem Howto Bind9 - Primary DNS Service auf.

Ich gehe in meinem Beispiel von folgenden Vorraussetzungen aus:

- Virtual Private Server von Hosteurope
- Debian GNU/Linux 4.0r1 (Etch)
- Bind9 (9.3.4-2etch1)
- DNSutils (9.3.4-2etch1)
- Domain Reseller-Account, in meinem Falle Providerdomain

Zuerst sollte die Bind9 Konfigurationsdatei in /etc/bind/named.conf angepasst werden. Der "Options" Teil wurde wie folgt angepasst:

Code:
options {
directory "/etc/bind/slave";
# pid-file "/var/run/bind/named.pid";
notify no;
#allow-notify { IP; };
allow-transfer { MASTER-IP; Andere-IP; };
forwarders { Pri.-DNS-IP };
forward first;
listen-on port 53 { 127.0.0.1; Eigene-IP; };
listen-on-v6 { none; };
allow-query { any;};
auth-nxdomain no; # conform to RFC1035
// version "My version is so secret that I even dont know what Im running on";
// Wer seine Bind Version "verstecken" will, kann die beide // vor version entfernen.
};

Erklärung der Statements:

directory {...}
Zeigt den Pfad auf in dem später die Slave - Zonefiles liegen sollen.

notify [yes] [no]
Damit wird bestimmt ob der Master eine Benachrichtigung an den/die Slave Server senden soll wenn ein Zonefile geupdatet wurde. (Mehr Info´s unter Internet Systems Consortium, Inc.)

allow-transfer { IP }
Hier wird definiert welche Hosts Zonentransfers von diesem Server erhalten dürfen. (Mehr Info´s unter Internet Systems Consortium, Inc.)

forward first
Hier (auskommentiert) würde der DNS-Server zuerst jede DNS Abfrage an einen anderen (in forwarders definierten) DNS-Server weiterleiten und erst dann versuchen die Frage selbst zu beantworten wenn die oder der forwarder nicht antworten kann.

forwarders { [IP] … }
Einstellung um die Forwarders zu definieren.

listen-on port [PORT] { [IP] … }
Das ist die Einstellung auf welchem Port Bind lauscht. Standart ist hier Port 53. Der Bereich [IP] muss in diesem Fall localhost, also 127.0.0.1, sowie die IP - Adresse des Servers enthalten. (Mehr Info´s unter Internet Systems Consortium, Inc.)

listen-on-v6 [PORT] { [IPv6] … }
Ist in diesem Fall deaktiviert, da dieser DNS keine IPv6 Unterstützung haben soll. (Mehr Info´s unter Internet Systems Consortium, Inc.)

allow-query { [IP] … }
Dies ist die Einstellungsmöglichkeit welche Hosts gewöhnliche DNS abfragen machen dürfen. Ich habe hier "any" eingetragen, so kann quasi jeder diesen DNS abfragen. (Mehr Info´s unter Internet Systems Consortium, Inc.)

Soviel zum "Options" Teil der Konfiguration. Ein weiteres Kriterium ist das Logging. Gerade bei der Fehlersuche ist es von großem Vorteil über ein Umfangreiches Log zu verfügen. Um die Standartmässigen Logs ein wenig zu erweitern habe ich in /etc/bind/named.conf weitere Anpassungen vorgenommen:

Code:
logging {
channel bind9log {
 file "/var/log/named/bind9.log" versions 3 size 10m;
 severity dynamic;
 print-time yes;
 print-severity yes;
 print-category yes;
};
channel security {
 file "/var/log/named/security" versions 2 size 5m;
 severity dynamic;
 print-time yes;
 print-severity yes;
 print-category yes;
};
 category default {bind9log;};
 category security {security;};
 category lame-servers {null;};
};

Zuvor muss allerdings das Verzeichnis /var/log/ named angelegt werden und im Idealfall mit chown bind /var/log/named die entsprechende Berechtigung gesetzt werden. Nun hat man eine Informationsgrundlage die das Troubleshooting erheblich erleichtern kann.

Die Zonen die von vorneherein bei dem Bind9 Paket von Debain enthalten sind, bleiben unverändert:

Code:
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";};

Nachdem dieser teil der Konfiguration abgeschlossen ist, geht es mit der Erstellung der Slave-Zonen weiter. Dies ist wesentlich einfacher zu handhaben wie beim Primary DNS. Wie folgt, wird ein Eintrag in der Datei named.conf vorgenommen:

Code:
zone "byteheads-ma.de" {
    type slave;
    file "www.byteheads-ma.de";
    masters {
      MASTER-IP;
    };
};

Zone "Domainname" definiert hier den Namen der zu sichernden Zone. Wichtig ist es hier beim Type 'slave' anzugeben, so weiss Bind dass es sich hier nicht um eine Master-Zone handelt (worauf wir ja hinauswollen). Per file ="filename" definieren wir den Dateinamen der Zone, die dann im Verzeichnis wie im Options-Teil (directory) definiert, abgespeichert wird.

Zum Schluss muss natürlich noch angegeben werden, wer der Master-DNS für diese Zone ist. Dies definiert man per masters {IP}.

Hat man den Primary DNS entsprechend konfiguriert, kann man schon jetzt den DNS Service mit /etc/init.d/bind9 restart neustarten. Jetzt sollte der Slave-Server beim Master nach der entsprechend eingerichteten Zone anfragen und sich eine Kopie des Original-Zonefile ziehen. Im Logfile würde das ungefähr so aussehen:

Code:
06-Oct-2007 16:25:07.140 general: info: zone domain.tld/IN: Transfer started.
06-Oct-2007 16:25:07.141 xfer-in: info: transfer of 'domain.tld/IN' from MASTER-IP#53: connected using SLAVE-IP
06-Oct-2007 16:25:07.142 general: info: zone domain.tld/IN: transferred serial 2007100601
06-Oct-2007 16:25:07.142 xfer-in: info: transfer of 'domain.tld/IN' from MASTER-IP#53: end of transfer

Hier können wir genau erkennen was passiert ist: Der Transfer war erfolgreich.

Zum Thema Troubleshooting und Überprüfung der Einstellungen, bin ich im HowTo "Bind9 - Primary DNS Service" eingegangen.

##############Ende############

Viel Erfolg/Spass damit, über Feedback und Kritik freue ich mich :)
 
Last edited by a moderator:
Code:
forwarders { HE-Master-IP; HE-Backup-IP; MASTER-IP; };
Wozu das? Es sollte doch nur ein authorative Nameserver werden, oder?

Code:
# allow-recursion { 127.0.0.1; SLAVE-IP; MASTER-IP;};
recursion yes;
Wozu das? Normalerweise will man das ja gerade nicht haben! Standardwert für allow-recursion ist übrigens any...

Code:
 category resolver {bind9log;};
 category default {bind9log;};
 category queries {bind9log;};
 category client {bind9log;};
 category config {bind9log;};
 category notify {bind9log;};
 category unmatched {bind9log;};
 category dispatch {bind9log;};
 category dnssec {bind9log;};
 category database {bind9log;};
 category security {security;};
 category lame-servers {null;};
Oder kürzer:
Code:
 category default {bind9log;};
 category security {security;};
 category lame-servers {null;};
 
Recursion

recursion yes;
und
# allow-recursion { 127.0.0.1; SLAVE-IP; MASTER-IP;};

Wurde aus dem Options-Teil (named.conf) entnommen. Dies wird an dieser Stelle wie Roger Wilco bemerkt hat, wirklich nicht benötigt/gewünscht.

Wozu das? Normalerweise will man das ja gerade nicht haben! Standardwert für allow-recursion ist übrigens any...

Das ist nicht ganz korrekt. Wenn allow-recursion nicht definiert ist, wird über allow-query-cache und dann allow-query entschieden. Sind diese auch nicht definiert,
ergibt es einen Default Wert von 'localnets; localhost;'. Siehe ISC.


Forwarders

Hier habe ich folgendes geändert:

Options:

Code:
forwarders { Pri.-DNS-IP };
forward first;

Der Slave DNS soll bei Anfragen zuerst auf den Primary DNS forwarden. Nur wenn dieser
ausfällt, wird der Slave die Anfrage selbst beantworten.
Da der Primary in jedem Fall auf dem aktuellsten Stand ist, halte ich das für die optimale Lösung.

Logging

Code:
logging {
channel bind9log {
 file "/var/log/named/bind9.log" versions 3 size 10m;
 severity dynamic;
 print-time yes;
 print-severity yes;
 print-category yes;
};
channel security {
 file "/var/log/named/security" versions 2 size 5m;
 severity dynamic;
 print-time yes;
 print-severity yes;
 print-category yes;
};
 category default {bind9log;};
 category security {security;};
 category lame-servers {null;};
};

Wie Roger Wilco korrekt bemerkt hat, kann man die Bind Kategorien zum Logging zusammenfassen. Die Kategorie 'default' beherbergt alle anderen Kategorien, falls nicht anders definiert.

Default beinhaltet nun also:

- general
- client
- config
- database
- dnssec
- network
- notify
- queries
- resolver
- update
- xfer-in
- xfer-out

Die Kanäle 'security' und 'lame-servers' laufen separat in eigene Kanäle.
 
Das ist nicht ganz korrekt. Wenn allow-recursion nicht definiert ist, wird über allow-query-cache und dann allow-query entschieden. Sind diese auch nicht definiert,
ergibt es einen Default Wert von 'localnets; localhost;'. Siehe ISC.
Nö. Das Verhalten ist erst seit BIND 9.4.2b1 so, du benutzt BIND 9.3.4. Siehe ISC.

Der Slave DNS soll bei Anfragen zuerst auf den Primary DNS forwarden. Nur wenn dieser
ausfällt, wird der Slave die Anfrage selbst beantworten.
DNS kennt so etwas wie Primary und Secondary NS nicht. Nur Master und Slaves. Du erzeugst damit also nur unnötig Traffic und Last auf dem Master Nameserver.

Da der Primary in jedem Fall auf dem aktuellsten Stand ist, halte ich das für die optimale Lösung.
Dafür hast du AXFR und IXFR.

Die genannten Punkt treffen übrigens auch auf dein anderes, fast identisches Howto zu.
 
Primary, Secondary / Master, Slave - Wie man es auch nennen mag, ist es doch so, dass beim Ausfall des Masters/Primary der Secondary/Slave befragt wird. Oder täusche ich mich da?
 
Ja, denn es gibt (anders als bei den MX-Records) keine Priorität. Alle im Zone-File (SOA = Start Of Authority) genannten Nameserver sind authorisiert, Anfragen bezüglich einer Domain zu beantworten -- was die sagen stimmt!

Daher müssen alle diese Nameserver immer auf dem aktuellen Stand sein. Das wird dadurch erreicht, dass man das Zone-File auf dem Master bearbeitet (hier ist also die Unterscheidung wichtig!). Nachdem der Master das neue Zone-File eingelesen hat schickt er ein Notify an alle Slaves, die daraufhin einen Zone-Transfer durchführen und somit das aktualisierte Zone-File vom Master laden (die Notwendigkeit zum Neuladen erkennen sie daran, dass die Serialnumber erhöht worden ist). Anschließend ist es egal, ob man den Master oder einen der Slaves fragt -- die antworten immer richtig. Durch mehrere Nameserver lässt sich so die Last auf den einzelnen Nameserver deutlich verringern (überlege Dir mal, wie viele Anfragen beispielsweise die Server für die Root-Zone '.' jede Minute beantworten müssen....)

Viele Grüße,
LinuxAdmin
 
let sleeping dogs lie...

Hi,
ich will hier keine schlafenden Hunde wecken aber der Thread ist Nummer 1 bei google bezüglich "Secondary bind9 howto".

Also kleine Frage: Wieso steht in der config:
Code:
allow-transfer { MASTER-IP; Andere-IP; };

also wieso die Master IP? Nach meinem Verständnis will man doch keine zone transfers vom slave auf den master, oder?
 
Hallo zusammen,
ich habe da mal eine frage.

und zwar:
kann ich meinen Nameserver irgendwie sagen das die alle 1 - 2 stunden aktualisieren sollen?

Das würde mir helfen, weil irgendwie machen die das nur einmal am tag...
und ich habe derzeit viele einträge zumachen da ich eine Kleine Community aufmachen möchte.


Lieben Gruß,
QuasselNet

PS.: Vielen Dank im Voraus für die schnelle hilfe
 
ich mach das mit notify:

Code:
zone "mydomain.li" {
        type master;
        file "master/mydomain.li";
        allow-update { none;};
        notify yes;
        allow-transfer {
          (v4 vom slave);      (v6 vom slave);        
        };
};

Sofern alle Nameserver die die Zone erhalten sollen, auch als NS für die Zone eingetragen sind, und du nach jeder Änderung die Serial erhöhst, geschieht die Synchronisation sofort.
 
Back
Top