byteheads.de
New Member
In dieser Anleitung möchte ich in einfachen Schritten erklären wie man einen ISP-ähnlichen DNS Server mit Bind9 aufsetzt.
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:
Erklärung der Einstellungen:
allow-transfer { IP }
Hier wird definiert welche Hosts Zonentransfers von diesem Server erhalten dürfen. Mehr Info´s unter Internet Systems Consortium, Inc.)
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.)
notify [yes] [no]
Damit wird bestimmt ob der Master (in diesem Falle dieser Server) eine benachrichtigung an den/die Slave Server senden soll wenn ein Zonefile geupdatet wurde. (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 oben erklärten Forwarders zu definieren.
allow-recursion { [IP] … }
Dies wird definiert um Hosts anzugeben denen rekursive DNS Afragen auf diesem Server gestattet sind.
Soviel zum "Options" Teil der Konfiguration.
Ein weiteres und besonders wichtiges Kriterium (meiner Meinung nach) ist das Logging. Gerade bei der Fehlersuche ist es von grossem 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:
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 wird.
Der nächste Punkt dreht sich um die Einrichtung der Zonen. Die Zonen, die von vorneherein in dem Bind9 Paket von Debian enthalten sind, bleiben unverändert:
Jetzt geht es mit der Erstellung der ersten Zone inklusive dem Zonefile weiter. In der Datei /etc/bind/named.conf wird am Ende folgender Eintrag hinzugefügt:
Im folgenden erläutere ich noch die relevanten Statements.
zone "[Zonenname]"
Definiert den Namen der Zone, hier wird der Domainname eingegeben.
type [master] [slave]
Hier teilen wir dem DNS Server mit ob er Master oder Slave für diese Zone ist. Da wir hier einen Primary DNS aufsetzen möchten, wird der Type auf Master gesetzt.
file "[Pfad zum Zonefile/Zonefilename]"
Zeigt wo das Zonefile liegt.
allow-query { [IP] … }
Dies ist die Einstellungsmöglichkeit welche Hosts gewöhnliche DNS abfragen machen dürfen, wie bei dem Beispiel in der named.conf.
Analog zu dieser Einstellung muss natürlich auch noch das entsprechende Zonefile www.domain1.tld im Ordner /etc/bind angelegt werden. Der Inhalt dieser Datei kann in etwa so aussehen:
Das ist das Zonefile für die erste primäre Zone, deren Domainname für die Verwendung des oder der Nameserver sowie der Mailexchanger verwendet werden soll. Diese Konfiguration ist darauf ausgelegt später folgende Host-Adressen zu verwenden:
Primärer DNS-Server: ns1.domain1.tld
Sekundärer DNS-Server: ns2.DNS Host.tld
Primärer Mailexchanger: mx1.MX Host.de
Sekundärer Mailexchanger: mx2.BackupMX Host.de
Da jeder ganz individuelle Wünsche an seine DNS-Konfiguration der jeweiligen Domains hat, ist dies hier nur ein Standartbeispiel auf dem man aufbauen kann.
Zuerst gebe ich ein paar Erklärungen zu diesem Beispiel ab, damit wird es weniger versierten DNS-Admins etwas leichter fallen, das Zonefile an eigene Bedürfnisse anzupassen.
Mit IN NS werden die Nameserver Einträge definiert. Hier habe ich einmal ns1.domain1.tld und ns2.DNS Host.tld. NS1 wird dieser Server sein, und NS2 ist der sekundäre, Slave DNS-Server. Hat man nur einen Server zur Verfügung kann man natürlich auch von anderen Providern angebotene Slaves benutzen. Bei Providerdomain / Schlundtech wäre dies dann der Server ns10.schlundtech.de.
Die IN MX Einträge definieren die MailExchanger. Im Idealfall hat man einen Mailserver und einen zusätzlichen Backupmailserver, falls der primäre ausfällt. Die Hierarchie, hier mit 10 und 20 aufgelistet, zeigt an welcher der Server die höchste Priorität hat. Hier ist es so dass die 10 den höchsten Stellenwert hat, und damit diesen Server als (primären) Mailserver anspricht.
Im zweiten Teil des Zonefiles habe ich via IN A Aliase gesetzt. Schliesslich muss ja bekannt sein welche IP NS1, NS2, MX1, MX2 etc. hat.
Nachdem die obenstehenden Konfigurationen abgeschlossen sind, ist es an der Zeit den DNS-Service zu testen.
Zuerst wird der DNS-Server neu gestartet. Im Logfile /var/log/named/bind9.log sollte man zuerst nachsehen ob es zu Warnungen oder Fehlern gekommen ist. Ein einwandfreier Start sollte ungefähr so aussehen:
Keine Fehler oder Warnungen? Okay, dann kann es weitergehen. Bevor wir beim Domainprovider die neuen Nameserver bekannt machen, soll sichergestellt werden dass dies auch beim ersten Versuch erfolgreich durchgeführt werden kann. Dies erspart zumindest in den Anfängen viel Ärger und Frust.
In Bind9 integriert, gibt es zwei Tools die uns helfen die aktuelle Konfiguration auf Fehler zu prüfen. Zum Einen wäre das Programm "named-checkconf" für die Prüfung der Datei named.conf vorhanden. Nachdem es ausgeführt wurde erscheint im Idealfall gar nichts. Das bedeutet dass named.conf zumindest syntaktisch korrekt ist. Das andere Tool nennt sich named-checkzone. Wie folgt kann man seine Zonefiles damit überprüfen:
named-checkzone domainX.tld /ect/bind/Zonefilename
Syntax: named-checkzone [Domainname] [Entspr. Zonefile]
Wenn fehlerfrei konfiguriert wurde, ergibt die Ausgabe in etwa:
zone domainX.tld/IN: loaded serial 2007100614
OK
Weiter möchten wir herausfinden ob die Zonefiles auch vom Inhalt her so funktionieren, wie man es sich wünscht:
Das Tool "dig" findet hier zuerst Verwendung:
dig @Primärer Nameserver domainX.tld any
sollte die selbe Ausgabe wie (sofern repliziert und eingerichtet)
dig @Sekundärer Nameserver domainX.tld any
ergeben. Selbstredend ist der Status: NOERROR. Diesen Vorgang wiederholt man nun für jede Domain die man im Server eingebunden hat. Sind beide Ausgaben gleich, kann man dazu übergehen die Zonen checken zu lassen. Denic bietet dazu ein Tool auf deren Internetseite an (Zone Check).
Verläuft die Prüfung Erfolgreich ist man soweit beim Provider (z.B. Providerdomain) Domains entsprechend einrichten zu lassen. In meinem Beispiel habe ich den primären sowie sekundären Nameserver inkl. IP in eigener Verwaltung. Daher kann ich das Flag "Keine Einrichtung vornehmen" setzen, da ich dies selbst Erledigt habe. Nutzt man allerdings den Slave-Nameserver von z.B. Schlundtech (ns10.schlundtech.de) setzt man das Flag "Einrichtung auf sekundärem Server vornehmen". Einige Minuten nach dem Vorgang ist in der Domain-History erkenntlich ob der Vorgang erfolgreich war.
#############ENDE############
Über ein Feedback wäre ich dankbar
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 "/var/cache/bind";
notify yes;
allow-transfer { IP des Sek. DNS; };
listen-on port 53 { 127.0.0.1; Eigene IP; };
listen-on-v6 { none; };
allow-query { any;};
auth-nxdomain no; # conform to RFC1035
#pid-file "/var/run/bind/named.pid";
#forwarders { Forwarder IP; };
#forward first;
#allow-recursion { 127.0.0.1; Recursion IP;};
// 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 Einstellungen:
allow-transfer { IP }
Hier wird definiert welche Hosts Zonentransfers von diesem Server erhalten dürfen. Mehr Info´s unter Internet Systems Consortium, Inc.)
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.)
notify [yes] [no]
Damit wird bestimmt ob der Master (in diesem Falle dieser Server) eine benachrichtigung an den/die Slave Server senden soll wenn ein Zonefile geupdatet wurde. (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 oben erklärten Forwarders zu definieren.
allow-recursion { [IP] … }
Dies wird definiert um Hosts anzugeben denen rekursive DNS Afragen auf diesem Server gestattet sind.
Soviel zum "Options" Teil der Konfiguration.
Ein weiteres und besonders wichtiges Kriterium (meiner Meinung nach) ist das Logging. Gerade bei der Fehlersuche ist es von grossem 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;
// syslog info;
// severity debug;
severity dynamic;
print-time yes;
print-severity yes;
print-category yes;
};
channel security {
file "/var/log/named/security" versions 2 size 5m;
// syslog warn;
// severity warn;
severity dynamic;
print-time yes;
print-severity yes;
print-category yes;
};
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;};
};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 wird.
Der nächste Punkt dreht sich um die Einrichtung der Zonen. Die Zonen, die von vorneherein in dem Bind9 Paket von Debian 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";};Jetzt geht es mit der Erstellung der ersten Zone inklusive dem Zonefile weiter. In der Datei /etc/bind/named.conf wird am Ende folgender Eintrag hinzugefügt:
Code:
zone "domain1.tld" in {
type master;
file "/etc/bind/www.domain1.tld";
allow-query { any; };
};Im folgenden erläutere ich noch die relevanten Statements.
zone "[Zonenname]"
Definiert den Namen der Zone, hier wird der Domainname eingegeben.
type [master] [slave]
Hier teilen wir dem DNS Server mit ob er Master oder Slave für diese Zone ist. Da wir hier einen Primary DNS aufsetzen möchten, wird der Type auf Master gesetzt.
file "[Pfad zum Zonefile/Zonefilename]"
Zeigt wo das Zonefile liegt.
allow-query { [IP] … }
Dies ist die Einstellungsmöglichkeit welche Hosts gewöhnliche DNS abfragen machen dürfen, wie bei dem Beispiel in der named.conf.
Analog zu dieser Einstellung muss natürlich auch noch das entsprechende Zonefile www.domain1.tld im Ordner /etc/bind angelegt werden. Der Inhalt dieser Datei kann in etwa so aussehen:
Code:
$TTL 1W
@ IN SOA ns1.domain1.tld. mail.domain.tld. (
2007100801 ; serial
28800 ; refresh (8 Stunden)
7200 ; retry (2 Stunden)
604800 ; expire (1 Woche)
39600 ; minimum (11 Stunden)
)
domain1.tld. IN NS ns1.nameserver1.tld.
domain1.tld. IN NS ns2.nameserver2.tld.
domain1.tld. IN MX 10 mx1.mailserver1.tld.
domain1.tld. IN MX 20 mx2.mailserver2.tld.
domain1.tld. IN A IP auf die die Domain zeigen soll
www CNAME domain1.tld.
ns1 IN A IP Primary DNS
ns2 IN A IP Secondary DNS
mx1 IN A IP des Mailexchanger
mx2 IN A IP des BackupmailexchangerDas ist das Zonefile für die erste primäre Zone, deren Domainname für die Verwendung des oder der Nameserver sowie der Mailexchanger verwendet werden soll. Diese Konfiguration ist darauf ausgelegt später folgende Host-Adressen zu verwenden:
Primärer DNS-Server: ns1.domain1.tld
Sekundärer DNS-Server: ns2.DNS Host.tld
Primärer Mailexchanger: mx1.MX Host.de
Sekundärer Mailexchanger: mx2.BackupMX Host.de
Da jeder ganz individuelle Wünsche an seine DNS-Konfiguration der jeweiligen Domains hat, ist dies hier nur ein Standartbeispiel auf dem man aufbauen kann.
Zuerst gebe ich ein paar Erklärungen zu diesem Beispiel ab, damit wird es weniger versierten DNS-Admins etwas leichter fallen, das Zonefile an eigene Bedürfnisse anzupassen.
Mit IN NS werden die Nameserver Einträge definiert. Hier habe ich einmal ns1.domain1.tld und ns2.DNS Host.tld. NS1 wird dieser Server sein, und NS2 ist der sekundäre, Slave DNS-Server. Hat man nur einen Server zur Verfügung kann man natürlich auch von anderen Providern angebotene Slaves benutzen. Bei Providerdomain / Schlundtech wäre dies dann der Server ns10.schlundtech.de.
Die IN MX Einträge definieren die MailExchanger. Im Idealfall hat man einen Mailserver und einen zusätzlichen Backupmailserver, falls der primäre ausfällt. Die Hierarchie, hier mit 10 und 20 aufgelistet, zeigt an welcher der Server die höchste Priorität hat. Hier ist es so dass die 10 den höchsten Stellenwert hat, und damit diesen Server als (primären) Mailserver anspricht.
Im zweiten Teil des Zonefiles habe ich via IN A Aliase gesetzt. Schliesslich muss ja bekannt sein welche IP NS1, NS2, MX1, MX2 etc. hat.
Nachdem die obenstehenden Konfigurationen abgeschlossen sind, ist es an der Zeit den DNS-Service zu testen.
Zuerst wird der DNS-Server neu gestartet. Im Logfile /var/log/named/bind9.log sollte man zuerst nachsehen ob es zu Warnungen oder Fehlern gekommen ist. Ein einwandfreier Start sollte ungefähr so aussehen:
Code:
09-Oct-2007 10:37:07.646 general: info: shutting down: flushing changes
09-Oct-2007 10:37:07.646 general: notice: stopping command channel on 127.0.0.1#953
09-Oct-2007 10:37:07.649 network: info: no longer listening on 127.0.0.1#53
09-Oct-2007 10:37:07.649 network: info: no longer listening on Eigene IP#53
09-Oct-2007 10:37:07.654 general: notice: exiting
09-Oct-2007 10:37:10.293 general: info: zone domain1.tld/IN: loaded serial 2007100802
09-Oct-2007 10:37:10.294 general: info: zone domain2.tld/IN: loaded serial 2007100801
09-Oct-2007 10:37:10.302 general: notice: running
09-Oct-2007 10:37:10.303 notify: info: zone domain1.tld/IN: sending notifies (serial 2007100802)
09-Oct-2007 10:37:10.303 notify: info: zone domain2.tld/IN: sending notifies (serial 2007100801)
.......Keine Fehler oder Warnungen? Okay, dann kann es weitergehen. Bevor wir beim Domainprovider die neuen Nameserver bekannt machen, soll sichergestellt werden dass dies auch beim ersten Versuch erfolgreich durchgeführt werden kann. Dies erspart zumindest in den Anfängen viel Ärger und Frust.
In Bind9 integriert, gibt es zwei Tools die uns helfen die aktuelle Konfiguration auf Fehler zu prüfen. Zum Einen wäre das Programm "named-checkconf" für die Prüfung der Datei named.conf vorhanden. Nachdem es ausgeführt wurde erscheint im Idealfall gar nichts. Das bedeutet dass named.conf zumindest syntaktisch korrekt ist. Das andere Tool nennt sich named-checkzone. Wie folgt kann man seine Zonefiles damit überprüfen:
named-checkzone domainX.tld /ect/bind/Zonefilename
Syntax: named-checkzone [Domainname] [Entspr. Zonefile]
Wenn fehlerfrei konfiguriert wurde, ergibt die Ausgabe in etwa:
zone domainX.tld/IN: loaded serial 2007100614
OK
Weiter möchten wir herausfinden ob die Zonefiles auch vom Inhalt her so funktionieren, wie man es sich wünscht:
Das Tool "dig" findet hier zuerst Verwendung:
dig @Primärer Nameserver domainX.tld any
sollte die selbe Ausgabe wie (sofern repliziert und eingerichtet)
dig @Sekundärer Nameserver domainX.tld any
ergeben. Selbstredend ist der Status: NOERROR. Diesen Vorgang wiederholt man nun für jede Domain die man im Server eingebunden hat. Sind beide Ausgaben gleich, kann man dazu übergehen die Zonen checken zu lassen. Denic bietet dazu ein Tool auf deren Internetseite an (Zone Check).
Verläuft die Prüfung Erfolgreich ist man soweit beim Provider (z.B. Providerdomain) Domains entsprechend einrichten zu lassen. In meinem Beispiel habe ich den primären sowie sekundären Nameserver inkl. IP in eigener Verwaltung. Daher kann ich das Flag "Keine Einrichtung vornehmen" setzen, da ich dies selbst Erledigt habe. Nutzt man allerdings den Slave-Nameserver von z.B. Schlundtech (ns10.schlundtech.de) setzt man das Flag "Einrichtung auf sekundärem Server vornehmen". Einige Minuten nach dem Vorgang ist in der Domain-History erkenntlich ob der Vorgang erfolgreich war.
#############ENDE############
Über ein Feedback wäre ich dankbar
Last edited by a moderator: