BIND9/Installation: Unterschied zwischen den Versionen
Keine Bearbeitungszusammenfassung |
K Textersetzung - „== Syntax ==“ durch „== Aufruf ==“ |
||
(13 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt) | |||
Zeile 1: | Zeile 1: | ||
'''topic''' | '''topic''' - Beschreibung | ||
== Beschreibung == | == Beschreibung == | ||
== Installation == | == Installation == | ||
== Anwendungen == | == Anwendungen == | ||
=== | === Problembehebung === | ||
== | == Aufruf == | ||
=== Optionen === | === Optionen === | ||
=== Parameter === | === Parameter === | ||
=== | === Umgebung === | ||
=== | === Rückgabewert === | ||
== Konfiguration == | == Konfiguration == | ||
=== Dateien === | === Dateien === | ||
Zeile 16: | Zeile 16: | ||
=== Dokumentation === | === Dokumentation === | ||
==== RFC ==== | ==== RFC ==== | ||
==== Man- | ==== Man-Page ==== | ||
==== Info-Pages ==== | ==== Info-Pages ==== | ||
=== Links === | === Links === | ||
==== Projekt ==== | ==== Projekt ==== | ||
==== Weblinks ==== | ==== Weblinks ==== | ||
= Planung = | = Planung = | ||
Zeile 289: | Zeile 266: | ||
* Tatsächlich ist es sogar vorgeschrieben, dass eine öffentlich zugängliche Domain von mindestens zwei Servern bedient werden muss. | * Tatsächlich ist es sogar vorgeschrieben, dass eine öffentlich zugängliche Domain von mindestens zwei Servern bedient werden muss. | ||
* Oft sind es sogar fünf oder mehr. In einem privaten Netz kommt man dagegen in der Regel mit einem aus. | * Oft sind es sogar fünf oder mehr. In einem privaten Netz kommt man dagegen in der Regel mit einem aus. | ||
* Damit man die verschiedenen Server aber nicht alle einzeln konfigurieren muss, und sich bei routinemäßigen Veränderungen der Zonen Fehler bzw. Abweichungen zwischen den Zonendaten einschleichen, gibt es Zonentransfers. | * Damit man die verschiedenen Server aber nicht alle einzeln konfigurieren muss, und sich bei routinemäßigen Veränderungen der Zonen Fehler bzw. Abweichungen zwischen den Zonendaten einschleichen, gibt es Zonentransfers. | ||
* Dafür werden die Daten dann immer nur auf einem primären Nameserver angepasst und dieser transferiert die aktuellen Zonendaten dann an einen oder mehrere sekundäre Server weiter, so dass die Daten immer konsistent bleiben. | * Dafür werden die Daten dann immer nur auf einem primären Nameserver angepasst und dieser transferiert die aktuellen Zonendaten dann an einen oder mehrere sekundäre Server weiter, so dass die Daten immer konsistent bleiben. | ||
* Für einen Client macht es keinen Unterschied, ob er mit einem primären oder einem sekundären Server kommunizieret. | * Für einen Client macht es keinen Unterschied, ob er mit einem primären oder einem sekundären Server kommunizieret. | ||
Zeile 545: | Zeile 522: | ||
# https://de.wikipedia.org/wiki/Domain_Name_System | # https://de.wikipedia.org/wiki/Domain_Name_System | ||
[[Kategorie: | [[Kategorie:BIND9]] |
Aktuelle Version vom 12. November 2024, 18:44 Uhr
topic - Beschreibung
Beschreibung
Installation
Anwendungen
Problembehebung
Aufruf
Optionen
Parameter
Umgebung
Rückgabewert
Konfiguration
Dateien
Sicherheit
Siehe auch
Dokumentation
RFC
Man-Page
Info-Pages
Links
Projekt
Weblinks
Planung
- Zu Beginn machen wir uns kurz Gedanken, wie die Domäne, der Servername und die IP-Adresse lauten sollen.
- Weiter sollten wir uns überlegen, welchen Dienst wir hierfür einsetzen möchten.
Primary DNS-Server Domain: raum102.itw Servername: ns1.raum102.itw IP-Address: 10.0.0.3 Alias: nameserver1
Als DNS-Dienst wird BIND9 verwendet.
Vorbedingungen
Bevor wir den eigentlichen DNS Dienst installieren, müssen wir noch einige Vorkehrungen treffen.
Statische IP setzen
- Zum root User wechseln
$ su -
- Schnittstellenbezeichnung herausfinden
# ip a
- interfaces Datei bearbeiten
# vi /etc/network/interfaces
Das resolvconf Paket muss installiert sein, wenn man die Namesserver in die /etc/network/interfaces eintragen will! Wir tragen die Nameserver allerdings in die /etc/resolv.conf ein und brauchen das Paket somit nicht. Wir müssen allerdings sicherstellen, dass wir eine IP-Adresse nutzen, die im Adressbereich liegt den unser Router auch kennt. Als Nameserver nutzen wir zu Beginn am besten 8.8.8.8.
# In dieser Datei werden die Schnittstellen bekannt gemacht und # konfiguriert. (weitere Informationen enthält die Manpage) # Sollte man die Schnittstellen in jeweils eigenen Dateien angelegt # haben, werden diese hiermit eingebunden source /etc/network/interfaces.d/* # LOOPBACK INTERFACE (localhost) --> nicht verändern auto lo iface lo inet loopback # DNS INTERFACE # Bereitstellung beim Hochfahren auto enp2s0 # Konfiguration der statischen Adressinformationen iface enp2s0 inet static address 10.0.0.3/8 gateway 10.0.0.1 # Bekanntmachung der Routen bei jedem Start (somit persistent) post-up ip route add 10.10.0.0/16 via 10.0.0.1 post-up ip route add 10.20.0.0/16 via 10.0.0.1 post-up ip route add 10.30.0.0/16 via 10.0.0.1
- 4. resolv.conf Datei bearbeiten
# vi /etc/resolv.conf
# Der zu nutzende Nameserver nameserver 8.8.8.8
- 5. Jetzt den Dienst neu starten
# systemctl restart networking.service
- 6. Mit ~# ip a und ~# ip r überprüfen ob unsere Einträge greifen.
Packetliste und Packete updaten
# apt update && apt upgrade
Beispiel
Wir haben für den Schulungsraum 102 einen eigenen DNS-Server aufgesetzt um eine Namensauflösung aller Router, Server und Clients zu ermöglichen.
Die Domain lautet hier raum102.itw. Wie wir dies realisiert haben erläutern wir im weiteren Verlauf.
Konventionen
Zu Beginn machen wir uns kurz Gedanken wie die Domäne, der Servername und die IP-Adresse lauten sollen.
Weiter sollten wir uns überlegen, welchen Dienst wir hierfür einsetzen möchten.
Primary DNS-Server Domain: raum102.itw Servername: ns1.raum102.itw IP-Address: 10.0.0.3 Alias: nameserver1
Als DNS-Dienst wollen wir bind9 verwenden.
Vorraussetzungen
Betriebssystem aktualisieren
# apt update && apt upgrade
Statische IP setzen
# vi /etc/network/interfaces
# vi /etc/resolv.conf
bind9 installieren
# apt install -y bind9 bind9utils bind9-doc dnsutils
Zonendateien anlegen
Resource Records kurz erklärt
SOA - enthält z.B Seriennummer, Gultigkeitsdauer ... @ IN SOA ns1.raum102.itw. root.raum102.itw. ( 2019092301 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Negative Cache TTL
SOA bedeutet Start of Authority (dt. Beginn der Zuständigkeit) und ist wichtiger Bestandteil einer Zonendatei im DNS. Seriel wird bei jeder Änderung inkrementiert (vorzugsweise JJJJMMTTVV; dient als Hinweis, wann die Zone zuletzt aktualisiert wurde. Refresh Sekundenabstand, in dem sekundäre Nameserver die Seriennummer vom primären Master abfragen sollen, um Änderungen der Zone festzustellen. 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. 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. TTL gibt in Sekunden an, wie lange dieser RR in einem Cache gültig sein darf.
NS - Delegierung der Nameserver untereinander IN NS ns1.raum102.itw.
A - weist einem Namen eine IPv4-Adresse zu ;IP address of Name Server ns1 IN A 10.0.0.3 ;A - Record HostName To Ip Address nfs IN A 10.0.0.140 bup IN A 10.0.0.141 r1 IN A 10.0.0.1 r2 IN A 10.0.0.2
AAAA - weist einem Namen eine IPv6-Adresse zu ;wird hier nicht verwendet
CNAME - verweist von einem Namen auf einen anderen Namen (Alias) ;CNAME record nameserver1 IN CNAME ns1.raum102.itw. fileserver IN CNAME nfs.raum102.itw. backupserver IN CNAME bup.raum102.itw. router01 IN CNAME r1.raum102.itw. router02 IN CNAME r2.raum102.itw.
MX - weist einem Namen einen Mailserver zu (SMTP) ;wird hier nicht verwendet
PTR - weist einer IP-Adresse einen Namen zu (Reverse Lookup) ;Reverse lookup for Name Server 3 IN PTR ns1.raum102.itw. ;PTR Record IP address to HostName 140 IN PTR nfs.raum102.itw. 141 IN PTR bup.raum102.itw. 1 IN PTR r1.raum102.itw. 2 IN PTR r2.raum102.itw.
TXT - kann einem Namen einen frei definierbaren Text zuweisen (Abwehr von Spam) ;wird hier nicht verwendet
Forward lookup Zone anlegen
# vi /etc/bind/fwd.raum102.itw ; ; BIND forward zone file for raum102.itw ; $TTL 604800 @ IN SOA ns1.raum102.itw. root.raum102.itw. ( 2019092301 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Negative Cache TTL ;@ IN NS localhost. ;@ IN A 127.0.0.1 ;@ IN AAAA ::1 ;Name Server Information IN NS ns1.raum102.itw. ;IP address of Name Server ns1 IN A 10.0.0.3 ;A - Record HostName To Ip Address nfs IN A 10.0.0.140 bup IN A 10.0.0.141 r1 IN A 10.0.0.1 r2 IN A 10.0.0.2 ;CNAME record nameserver1 IN CNAME ns1.raum102.itw. fileserver IN CNAME nfs.raum102.itw. backupserver IN CNAME bup.raum102.itw. router01 IN CNAME r1.raum102.itw. router02 IN CNAME r2.raum102.itw.
Reverse lookup Zone anlegen
# vi /etc/bind/rev.raum102.itw ; ; BIND reverse zone file for raum102.itw ; $TTL 604800 @ IN SOA ns1.raum102.itw. root.raum102.itw. ( 2019092301 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Negative Cache TTL ;Name Server Information IN NS ns1.raum102.itw. ;Reverse lookup for Name Server 3 IN PTR ns1.raum102.itw. ;PTR Record IP address to HostName 140 IN PTR nfs.raum102.itw. 141 IN PTR bup.raum102.itw. 1 IN PTR r1.raum102.itw. 2 IN PTR r2.raum102.itw.
Zonendateien einbinden
# vi /etc/bind/named.conf.local zone "raum102.itw" IN { //domain name (forward zone) type master; //primary DNS file "/etc/bind/fwd.raum102.itw"; //forward zone file allow-update { none; }; //none, because its primary DNS }; zone "0.0.10.in-addr.arpa" IN { //reverse zone type master; //primary DNS file "/etc/bind/rev.raum102.itw"; //reverse zone file allow-update { none; }; //none, because its primary DNS };
Konfiguration eines sekundären DNS-Servers
- Um Ausfallsicherheit zu gewährleisten, kann es sinnvoll sein, mehrere DNS-Server zu betreiben.
- Tatsächlich ist es sogar vorgeschrieben, dass eine öffentlich zugängliche Domain von mindestens zwei Servern bedient werden muss.
- Oft sind es sogar fünf oder mehr. In einem privaten Netz kommt man dagegen in der Regel mit einem aus.
- Damit man die verschiedenen Server aber nicht alle einzeln konfigurieren muss, und sich bei routinemäßigen Veränderungen der Zonen Fehler bzw. Abweichungen zwischen den Zonendaten einschleichen, gibt es Zonentransfers.
- Dafür werden die Daten dann immer nur auf einem primären Nameserver angepasst und dieser transferiert die aktuellen Zonendaten dann an einen oder mehrere sekundäre Server weiter, so dass die Daten immer konsistent bleiben.
- Für einen Client macht es keinen Unterschied, ob er mit einem primären oder einem sekundären Server kommunizieret.
Änderungen auf dem primären Server
- Als erstes muss man dem primären Server beibringen, an welche Rechner er die Zonendaten überhaupt übertragen darf.
- Das passiert in der Datei /etc/bind/named.conf.options, wo man irgendwo im durch geschweifte Klammern eingefassten options-Block Folgendes einträgt:
allow-transfer { 192.168.0.200; }; notify yes;
allow-transfer gibt dabei an, welchen Hosts ein Zonentransfer erlaubt werden soll. Die Angabe mehrerer IP-Adressen hintereinander ist möglich, es sollte jedoch unbedingt darauf geachtet werden, dass kein Semikolon fehlt. Die Direktive notify yes gibt an, dass der primäre Server seine Stellvertreter von selbst darauf aufmerksam macht, sobald aktualisierte Zonendateien verfügbar sind.
- Nach den Änderungen muss der Dienst neu gestartet werden
- Die Unterscheidung zwischen alten und neuen Daten erfolgt ausschließlich über die Seriennummer im SOA-Header der Zone.
- Wenn man beim Editieren vergisst, diese zu erhöhen, findet kein Zonentransfer statt und die Slaves arbeiten mit den veralteten Daten weiter.
Einrichtung des sekundären Servers
- Als erstes muss in der Datei named.conf.options eingetragen werden, von welchem Host die Benachrichtigungen kommen werden:
allow-notify { 192.168.0.10; };
- Dann müssen in named.conf.local die Zonen eingetragen werden, für die der Server als Slave agieren soll, und wer sein Meister ist:
zone "domainname" { type slave; masters { 192.168.0.10; }; file "back/domainname.bak"; };
zone "0.168.192.in-addr.arpa" { type slave; masters { 192.168.0.10; }; file "back/0.168.192.bak"; };
- Die File-Direktiven zeigen in diesem Fall nicht auf existierende Zonendateien, sondern auf den Ort, wo der Server die erhaltenen Zonendaten ablegen soll.
- In diesem Fall im Verzeichnis back im Bind-Homeverzeichnis /var/cache/bind. Da dieses noch nicht existiert, muss es erst passend angelegt werden:
$ sudo mkdir /var/cache/bind/back $ sudo chown bind /var/cache/bind/back
- Eigene Zonendateien besitzt ein sekundärer Nameserver nicht.
- Natürlich muss der Dienst auch hier nach der Änderung neu gestartet werden. Getestet werden kann er dann genau wie ein primärer Server.
Syntax der named.conf.* und der Zonendateien überprüfen
# named-checkzone raum102.itw /etc/bind/fwd.raum102.itw zone raum102.itw/IN: loaded serial 20 OK # named-checkzone 0.0.10-in-addr.arpa /etc/bind/rev.raum102.itw zone 0.0.10-in-addr.arpa/IN: loaded serial 20 OK
bind9 Installation abschließen
# systemctl restart bind9 # systemctl enable bind9 # systemctl status bind9 # vi /etc/resolv.conf --> nameserver 10.0.0.3 # service networking restart
Namensauflösung testen
# dig google.de
; <<>> DiG 9.11.5-P4-5.1-Debian <<>> google.de
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3983
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 9
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: bea27b6c0abfa5c4d5c979555d8b180addb5f0df1c69bfd0 (good)
;; QUESTION SECTION:
;google.de. IN A
;; ANSWER SECTION:
google.de. 300 IN A 172.217.17.35
;; AUTHORITY SECTION:
google.de. 83363 IN NS ns1.google.com.
google.de. 83363 IN NS ns2.google.com.
google.de. 83363 IN NS ns3.google.com.
google.de. 83363 IN NS ns4.google.com.
;; ADDITIONAL SECTION:
ns1.google.com. 168448 IN A 216.239.32.10
ns2.google.com. 168448 IN A 216.239.34.10
ns3.google.com. 168448 IN A 216.239.36.10
ns4.google.com. 168448 IN A 216.239.38.10
ns1.google.com. 168448 IN AAAA 2001:4860:4802:32::a
ns2.google.com. 168448 IN AAAA 2001:4860:4802:34::a
ns3.google.com. 168448 IN AAAA 2001:4860:4802:36::a
ns4.google.com. 168448 IN AAAA 2001:4860:4802:38::a
;; Query time: 20 msec
;; SERVER: 10.0.0.3#53(10.0.0.3)
;; WHEN: Mi Sep 25 09:32:26 CEST 2019
;; MSG SIZE rcvd: 340
bind9 installieren
# apt install -y bind9 bind9utils bind9-doc dnsutils
In /etc/bind/ liegen nun die Konfigurationsdateien für bind9 hier werden wir auch unsere sogenannten Zonendateien ablegen.
Zonendateien anlegen
Damit der DNS Server ordnungsgemäss arbeiten kann benötigt dieser entsprechende Zonendateien.
Forward lookup Zone anlegen
# vi /etc/bind/fwd.raum102.itw
- /etc/bind/fwd.raum102.itw
; ; BIND forward zone file for raum102.itw ; $TTL 604800 @ IN SOA ns1.raum102.itw. root.raum102.itw. ( 20 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Negative Cache TTL ;@ IN NS localhost. ;@ IN A 127.0.0.1 ;@ IN AAAA ::1 ;Name Server Information IN NS ns1.raum102.itw. ;IP address of Name Server ns1 IN A 10.0.0.3 ;A - Record HostName To Ip Address nfs IN A 10.0.0.140 bup IN A 10.0.0.141 r1 IN A 10.0.0.1 r2 IN A 10.0.0.2 ;CNAME record nameserver1 IN CNAME ns1.raum102.itw. fileserver IN CNAME nfs.raum102.itw. backupserver IN CNAME bup.raum102.itw. router01 IN CNAME r1.raum102.itw. router02 IN CNAME r2.raum102.itw.
Reverse lookup Zone anlegen
# vi /etc/bind/rev.raum102.itw
- /etc/bind/rev.raum102.itw
; ; BIND reverse zone file for raum102.itw ; $TTL 604800 @ IN SOA raum102.itw. root.raum102.itw. ( 20 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Negative Cache TTL ;Name Server Information IN NS ns1.raum102.itw. ;Reverse lookup for Name Server 3 IN PTR ns1.raum102.itw. ;PTR Record IP address to HostName 140 IN PTR nfs.raum102.itw. 141 IN PTR bup.raum102.itw. 1 IN PTR r1.raum102.itw. 2 IN PTR r2.raum102.itw.
Zonendateien einbinden
# vi /etc/bind/named.conf.local
- /etc/bind/named.conf.local
zone "raum102.itw" IN { //domain name (forward zone) type master; //primary DNS file "/etc/bind/fwd.raum102.itw"; //forward zone file allow-update { none; }; //none, because its primary DNS }; zone "0.0.10.in-addr.arpa" IN { //reverse zone type master; //primary DNS file "/etc/bind/rev.raum102.itw"; //reverse zone file allow-update { none; }; //none, because its primary DNS };
Syntax der named.conf.* und der Zonendateien überprüfen
Mit dem Befehl named-checkconf wird die Syntax aller named.conf.* Dateien geprüft.
Um die Zonendateien zu überprüfen verwenden wir named-checkzone
# named-checkzone raum102.itw /etc/bind/fwd.raum102.itw zone raum102.itw/IN: loaded serial 20 OK
# named-checkzone 0.0.10-in-addr.arpa /etc/bind/rev.raum102.itw zone 0.0.10-in-addr.arpa/IN: loaded serial 20 OK
bind9 Installation abschließen
- 1. Service neu starten
# systemctl restart bind9
- 2. Bei jedem Systemstart laden
# systemctl enable bind9
- 3. Status anzeigen lassen
# systemctl status bind9
● bind9.service - BIND Domain Name Server
Loaded: loaded (/lib/systemd/system/bind9.service; enabled; vendor preset: enabled)
Active: active (running) since Fri 2019-09-20 13:28:34 CEST; 1s ago
Docs: man:named(8)
Process: 1886 ExecStart=/usr/sbin/named $OPTIONS (code=exited, status=0/SUCCESS)
Main PID: 1887 (named)
Tasks: 5 (limit: 4478)
Memory: 12.2M
CGroup: /system.slice/bind9.service
└─1887 /usr/sbin/named -u bind
- 4. resolv.conf Datei bearbeiten
# vi /etc/resolv.conf
/etc/resolv.conf
# Der zu nutzende Nameserver nameserver 10.0.0.3
- 5. Jetzt den Dienst neu starten
# service networking restart
- 6. Mit ~# ip a und ~# ip r überprüfen, ob unsere Einträge greifen.