Bind9 mit Replikation, DDNS
Beide VMs sind mit Ubuntu 16.04 LTS ausgestattet und haben folgende wesentliche Eigenschaften:
Master-Server
Hostname: uhu.dom1.site
IP-Adresse: 10.20.30.3
Slave-Server:
Hostname: uhu2.dom1.site
IP-Adresse: 10.20.30.4
HINWEIS: Hier wird man am besten erst einmal mit sudo -i dauerhaft
root.
DNS-Server mit bind9
Forwarders
Zur Erinnerung: Für die Weiterleitung ins Internet benötigen wir einen vorgeschalteten DNS-Server. Dies kann allgemein bei allen Servern geschehen. Dazu wurde die Direktive forwarders { 10.20.30.100; 144.76.34.109; }; aktiviert und angepasst:
options {
directory "/var/cache/bind";
// If there is a firewall between you and nameservers you want
// to talk to, you may need to fix the firewall to allow multiple
// ports to talk. See http://www.kb.cert.org/vuls/id/800113
// If your ISP provided one or more IP addresses for stable
// nameservers, you probably want to use them as forwarders.
// Uncomment the following block, and insert the addresses replacing
// the all-0's placeholder.
forwarders {
10.20.30.100;
144.76.34.109;
};
//========================================================================
// If BIND logs error messages about the root key being expired,
// you will need to update your keys. See https://www.isc.org/bind-keys
//========================================================================
dnssec-validation auto;
auth-nxdomain no; # conform to RFC1035
listen-on-v6 { any; };
};
Master-Konfiguration
Hier ist besonders die Zeile notify yes; von Belang. Wir haben sie hinzugefügt, um den Slave bei Erhöhung der serial-Angabe informieren zu können, dass er sich die Daten replizieren muss:
=> cat /etc/bind/named.conf.local
zone "dom1.site" {
type master;
notify yes;
file "/etc/bind/db.dom1.site";
};
zone "30.20.10.in-addr.arpa" {
type master;
notify yes;
file "/etc/bind/db.10.20.30";
};
AUFGABE: Bitte die Sicherheit mit allow-transfer verbesseren! Siehe dazu Seite 319.
Im entsprechenden Zonenfile ist es wichtig, den zweiten Nameserver, der als Slave fungieren soll, auch als solchen mit aufzunehmen. Dies wird durch die Zeile @ IN NS uhu2.dom1.site. realisiert, die hinzugefügt werden muss. Vergisst man dies, kann sich zwar der Slave die Daten bei einem systemctl restart bind9 selber ziehen, wird aber nicht vom Master mittels seiner notify-Nachrichten über Änderugen informiert:
=> cat /etc/bind/db.dom1.site
;
; BIND data file for local loopback interface
;
$TTL 604800
@ IN SOA uhu.dom1.site. root.uhu.dom1.site. (
90 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
; Dies ist der eigene, lokale Master-Nameserver:
@ IN NS uhu.dom1.site.
; HINZUGEFÜGT: Dies ist der andere, entfernte Slave-Nameserver:
@ IN NS uhu2.dom1.site.
uhu IN A 10.20.30.3
uhu IN AAAA ::1
; Weitere Einträge (ähnlich der /etc/hosts, allerdings ZUERST die Hostnamen, DANN die IPs!)
uhu2 IN A 10.20.30.4
xphost IN A 10.20.30.126
xphost2 IN A 10.20.30.127
AUFGABE: Bitte auch die reversen Zonenfiles anpassen!
Slave-Konfiguration
Hier ist zuerst einmal wichtig, anzugeben, wer der Master ist, von dem dann die Daten kopiert werden sollen. Das legen wir mit der Anweisung masters { 10.20.30.3; }; fest:
⇒ cat /etc/bind/named.conf.local
zone "dom1.site" {
type slave;
masters { 10.20.30.3; };
file "/etc/bind/db.dom1.site";
};
zone "30.20.10.in-addr.arpa" {
type slave;
masters { 10.20.30.3; };
file "/etc/bind/db.10.20.30";
};
Dann brauchen wir auch wieder das Zonenfile. Anders als beim Master, wo wir den Slave mittels NS-Record eintragen mussten, sind für die Replikation keine besonderen Einstellungen erforderlich:
=> cat /etc/bind/db.dom1.site
;
; BIND data file for local loopback interface
;
$TTL 604800
@ IN SOA uhu2.dom1.site. root.uhu2.dom1.site. (
2 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS uhu2.dom1.site.
uhu2 IN A 10.20.30.4
uhu2 IN AAAA ::1
; Weitere Einträge sind hier auf dem Slave nicht erforderlich,
; da er sich die Datensätze repliziert.
Testing
Auf beiden Maschinen:
tail -f /var/log/syslogAuf dem Master
Datensatz hinzufügen
Seriennummer erhöhen
Config neu laden:
rndc reload
Sicherheit
AUF DEM MASTER:
Um nur dem Slave-Server mit der Adresse 10.20.30.4 Zonentransfers zu erlauben (AXFR = Asynchronous Full Transfer Zone oder Asynchronous Xfer Full Range), verwenden wir allow-transfer:
zone "dom1.site" {
type master;
notify yes;
allow-transfer { 10.20.30.4; };
file "/etc/bind/db.dom1.site";
};
zone "30.20.10.in-addr.arpa" {
type master;
notify yes;
file "/etc/bind/db.10.20.30";
};
Weiterhin kann man das ganz normale Abfragen der Datenbank (nslookup) reglementieren, in der Zonendefinition verwenden wir dazu so etwas:
allow-query { 127.0.0.1; 10.20.30.0/24; };
DHCP und DNS verbinden (DDNS)
ZIEL Einrichtung von dynamischen DNS (DDNS) unter Debian / Ubuntu
Siehe auch
https://debian-administration.org/article/343/Configuring_Dynamic_DNS__DHCP_on_Debian_Stable
http://blogging.dragon.org.uk/dns-with-bind9-and-dhcp-on-ubuntu-14-04/
Vorbereitung
DHCP- und DNS-Server sollten jeweils eingerichtet sein:
DHCP-Server: Deklaration eines Subnets mit gültigem Range
DNS-Server: Bereitstellung einer eigenen Zone für die Domäne „dom1.site“, gern auch mit gültigen „forwarders“
Der Servername lautet im Beispiel „uhu“
HINWEIS: Die folgende Verzeichnisrecht-Anpassung von /etc/bind/ ist wegen rndc freeze und rndc thaw (siehe unten) unter Debian erforderlich, wenn der bind-Daemon seine Journaldateien in diesem Verzeichnis ablegen können soll:
=> chmod g+w /etc/bind
Besser ist aber im Fall von DDNS, die Zonen unter /var/lib/bind zu verwalten, zumal wir bei Ubuntu wegen AppArmor dazu gezwungen werden. Die Dateirechte sehen dort im übrigen so aus:
=> ls -ld /etc/bind
drwxr-sr-x 2 root bind 4096 Okt 30 11:17 /etc/bind
Wenn man also plant, die Zonendateien unter /var/lib/bind abzulegen, ist hier kein Handlungsbedarf.
Datei /etc/bind/named.conf
Unterhalb von include „/etc/bind/named.conf.options“; ist folgendes einzufügen:
controls {
inet 127.0.0.1 allow {localhost; } keys { "rndc-key"; };
};
Datei /etc/bind/named.conf.local
Wie eben erläutert, macht es Sinn, die Zonendateien an einen anderen Ort zu legen.
In jedem Zonenblock müssen wir nun den Pfad zu den Zonendateien mit Hilfe der „file“-Anweisung auf /var/lib/bind verbiegen, so dass diese Angaben dann z.B. so lauten könnten:
...
file "/var/lib/bind/db.dom1.site";
...
file "/var/lib/bind/db.10.20.30";
...
Weiterhin sind in jeden Zonenblock nach der „file“-Anweisung diese Direktiven erforderlich:
allow-update { key "rndc-key"; };
notify yes;
Und schließlich muss am Ende der Datei noch folgendes angefügt werden:
include "/etc/bind/rndc.key";
Falls die Zonendateien nicht bereits unter /var/lib/bind erstellt wurden, verschieben wir sie jetzt an diesen Ort:
=> mv /etc/bind/db.dom1.site /etc/bind/db.10.20.30 /var/lib/bind/
Datei /etc/dhcp/dhcpd.conf
Zuerst muss die Zeile ddns-update-style none; auskommentiert werden (Raute-Zeichen voranstellen):
#ddns-update-style none;
Danach fügt man gleich darunter folgendes ein, wobei server-identifier (= Servername) und ddns-domainname (= Domainname wie im DNS festgelegt) anzupassen sind:
server-identifier uhu;
ddns-updates on;
ddns-update-style interim;
ddns-domainname "dom1.site.";
ddns-rev-domainname "in-addr.arpa.";
ignore client-updates;
# This is the key so that DHCP can authenticate it's self to BIND9
include "/etc/bind/rndc.key";
# This is the communication zone
zone dom1.site. {
primary 127.0.0.1;
key rndc-key;
}
Bei Ubuntu: Leserechte für rndc.key via AppArmor einräumen
Bei Ubuntu Server 16.04 LTS sind per Default die Sicherheitspolicies von AppArmor aktiv. Da sich /usr/sbin/named im enforce-Modus befindet, wird damit auch der Zugriff auf die Datei rndc.key blockiert.
Daher müssen wir AppArmors Konfigurationsdatei für den dhcpd ändern. Wie hier gezeigt, muss die Zeile /etc/dhcp/ddns-keys/** r, auskommentiert werden, danach ist eine neue Zeile hinzuzufügen, die der Datei /etc/bind/rndc.key explizit Leserechte verleiht:
=> vi /etc/apparmor.d/usr.sbin.dhcpd
#/etc/dhcp/ddns-keys/** r,
/etc/bind/rndc.key r,
Nun müssen nur noch die Dateirechte angepasst und die AppArmor-Policies neu eingelesen werden:
=> chown root:bind /etc/bind/rndc.key
=> chmod 640 /etc/bind/rndc.key
=> /etc/init.d/apparmor reload
Testings
Serverseitig
Beide Server müssen sich nun ohne größere Fehlermeldungen neu starten lassen:
=> /etc/init.d/bind9 restart
=> /etc/init.d/isc-dhcp-server restart
Existiert bereits ein manuell hinzugefügter Eintrag z.B. für „xpbox“ in der Zonendatenbank, findet keine dynamische Erzeugung eines RRs statt, auch wenn dem Host eine neue IP-Adresse via DHCP zugewiesen wird.
ACHTUNG: Wenn der Daemon im dynamischen Modus arbeitet (erkennbar am Vorhandensein der *.jnl-Dateien im Verzeichnis /etc/bind), darf der Zonenverwalter nicht einfach die Zonenfiles ändern!! Erst nach dem Ausführen von
=> rndc freeze
kann er dies tun. Nach Beenden des Editierens und einem rndc reload, kann die dynamische Arbeitsweise wieder mit
=> rndc thaw
gestartet werden, dabei entstehen wieder die Journaldateien.
Clientseitig
Bei Verwendung von TinyCore Linux als Testsystem für den DHCP-Client, kann man auf einfache Weise die IP-Adresse mit
=> udhcpc -R
freigeben (release).
Das Neubeziehen der IP-Informationen lässt sich problemlos mit der Option -F <HOSTNAME> machen, wobei testweise ein anderer FQDN gesendet und in die Zonendatenbank geschrieben wird:
=> udhcpc -F myTinyLinuxHost
Praktische Umsetzung auf dem Master-Nameserver (Ubuntu 16.04)
HINWEIS: Wir betrachten hier nur die für DDNS erforderlichen Einstellungen. Bei Replikation mit einem Slave-Server ist in der Zonendefinition zur Verbesserung der Sicherheit die Einschränkung der Zonentransfers empfehlenswert (Default: allow-transfer { any; };).
Konfigurationsdateien des Nameservers
=> grep -v '//' /etc/bind/named.conf
include "/etc/bind/named.conf.options";
controls {
inet 127.0.0.1 allow {localhost; } keys { "rndc-key"; };
};
include "/etc/bind/named.conf.local";
include "/etc/bind/named.conf.default-zones";
=> grep -v '//' /etc/bind/named.conf.options
zone "dom1.site" {
type master;
notify yes;
allow-update { key "rndc-key"; };
file "/var/lib/bind/db.dom1.site";
};
zone "30.20.10.in-addr.arpa" {
type master;
notify yes;
allow-update { key "rndc-key"; };
file "/var/lib/bind/db.10.20.30";
};
include "/etc/bind/rndc.key";
=> cat /var/lib/bind/db.dom1.site
$TTL 604800
@ IN SOA uhu.dom1.site. root.uhu.dom1.site. (
91 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS uhu.dom1.site.
@ IN NS uhu2.dom1.site.
uhu IN A 10.20.30.3
uhu IN AAAA ::1
; Weitere Einträge (ähnlich der /etc/hosts, allerdings ZUERST die Hostnamen, DANN die IPs!)
uhu2 IN A 10.20.30.4
xphost IN A 10.20.30.6
=> cat /var/lib/bind/db.10.20.30
$TTL 604800
@ IN SOA uhu.dom1.site. root.uhu.dom1.site. (
91 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS uhu.dom1.site.
3 IN PTR uhu.dom1.site.
4 IN PTR uhu2.dom1.site.
; Weitere...
4 IN PTR uhu2.dom1.site.
6 IN PTR xphost.dom1.site.
Konfigurationsdateien des DHCP-Servers
Nach der Installation mittels apt-get install isc-dhcp-server
legt man am besten gleich erst einmal das Listening-Interface fest:
=> tail -1 /etc/default/isc-dhcp-server
INTERFACES="enp0s3"
Dann ist die Hauptkonfigurationsdatei dran:
=> grep -v '^#' /etc/dhcp/dhcpd.conf
ddns-update-style interim;
server-identifier uhu;
ddns-updates on;
ddns-domainname "dom1.site.";
ddns-rev-domainname "in-addr.arpa.";
ignore client-updates;
include "/etc/bind/rndc.key";
zone dom1.site. {
primary 127.0.0.1;
key rndc-key;
}
option domain-name "dom1.site";
option domain-name-servers 10.20.30.3, 10.20.30.4;
default-lease-time 600;
max-lease-time 7200;
log-facility local7;
subnet 10.20.30.0 netmask 255.255.255.0 {
range 10.20.30.10 10.20.30.20;
option routers 10.20.30.1;
}