Inhaltsverzeichnis
DNS unbound ArchLinux
DNS unbound ist ein validierender, rekursiver und caching (zwischenspeichernder) DNS-Resolver. unbound ist schnell und schlank konzipiert und verfügt über moderne Funktionen, die auf offenen Standards basieren.
Ab hier werden zur Ausführung nachfolgender Befehle root-Rechte benötigt. Um der Benutzer root zu werden, melden Sie sich bitte als root-Benutzer am System an, oder wechseln mit nachfolgendem Befehl zum Benutzer root:
$ su - Password:
Zielsetzung
Nachfolgend soll ein im lokalen Netzwerk unbound als DNS-Resolver VOR einem im lokalen Netzwerk laufendem ISC (Internet System Consortium) BIND DNS-Server agieren.
+--------------+ +--------------+
| unbound | | BIND |
---> lokales Netzwerk --> | 192.168.0.20 | <-> | 127.0.0.1 |
| resolver | | tachtler.net |
| DNSSec | | DNSSec |
+--------------+ +--------------+
|
+--> Internet für NICHT (*.)tachtler.net/0.168.192.in-addr.arpa -->
Problem: Autoritative DNS-Server
 WICHTIG |
|---|
| Ein autoritativer DNS-Server antwortet niemals mit dem ad-Flag, sondern nur mit dem aa-Flag! Dies ist absichtlich so, da der autoritative DNS-Server nicht seine eigenen DNS-Records überprüfen muss, da dieser direkten Zugriff auf die Quelle hat und sich selbst vertraut ! |
| WICHTIG |
Lösung: DNS-Resolver
Der ISC (Internet System Consortium) BIND DNS-Server hält eigene lokale Zonen, und liefert DNSSec gesicherte Antworten aus.
Der unbound als DNS-Resolver soll nun ebenfalls DNSSec gesicherte Antworten ausliefern, welche jedoch das ad-Flag gesetzt haben!
Ziel ist es eine lokale Antwort –>
rechner10.intra.tachtler.net IN A 192.168.0.10
zu erhalten, welche via
- DNSSec abgesichert ist und
- bei der die (DNS) Chain-of-Trust (Vetrauenskette)
im lokalen Netzwerk überprüfbar ist, was durch
- das
ad-Flag
in der Antwort bestätigt wird.
(Siehe nachfolgendes Beispiel)
# dig @192.168.0.20 rechner10.intra.tachtler.net +dnssec +multi ; <<>> DiG 9.16.23 <<>> @192.168.0.20 rechner10.intra.tachtler.net +dnssec +multi ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8214 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 1232 ;; QUESTION SECTION: ;rechner10.intra.tachtler.net. IN A ;; ANSWER SECTION: rechner10.intra.tachtler.net. 10505 IN A 192.168.0.10 rechner10.intra.tachtler.net. 10505 IN RRSIG A 15 4 10800 ( 20211217203021 20211130133211 10887 intra.tachtler.net. Ds49XZOZ1p87ygjVtBYPk5qZED3MmbVybLoKIc8o4KPW P4xhS3R1Z9rAWBjHMi2XGxqIn7BB403SUh1quM03CA== ) ;; Query time: 0 msec ;; SERVER: 192.168.0.20#53(192.168.0.20) ;; WHEN: Tue Nov 30 15:38:06 CET 2021 ;; MSG SIZE rcvd: 187
HINWEIS - Nachfolgend muss das ad-Flag in der Antwort enthalten sein, siehe nachfolgende Zeile:
;; flags: qr rd raad;QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
Überblick
Im nachfolgenden soll die Konfiguration eines DNS-Resolvers welcher als interner agierender DNS-Server für ein privates Netzwerk mit zwei Zonen durchgeführt werden. Nachfolgende Zonen werden dabei ausgeliefert:
- Intranet - Domain: intra.tachtler.net - IP-Adressbereich: private Adressen
- Internet - Domain: tachtler.net - IP-Adressbereich: öffentliche Adresse
Installation
Zur Installation eines DNS-Servers wird nachfolgendes Paket benötigt:
installiert werden.
Um DNS-Abfragen optimiert gegen den DNS-Server durchführen zu können, kann das Paket
installiert werden.
Mit nachfolgendem Befehl, wird das Pakete unbound installiert:
# pacman --noconfirm -S unbound
Mit nachfolgendem Befehl kann überprüft werden, welche Inhalte mit den Paket unbound installiert wurden:
# pacman -Qil unbound
Dienst/Deamon-Start einrichten
Um einen DNS-Resolver, welcher als Dienst/Deamon als Hintergrundprozess läuft, auch nach einem Neustart des Servers zur Verfügung zu haben, soll der Dienst/Daemon mit dem Server mit gestartet werden, was mit nachfolgendem Befehl realisiert werden kann:
# systemctl enable unbound.service Created symlink /etc/systemd/system/multi-user.target.wants/unbound.service → /usr/lib/systemd/system/unbound.service.
Eine Überprüfung, ob beim Neustart des Server der unbound-Dienst/Deamon wirklich mit gestartet wird, kann mit nachfolgendem Befehl erfolgen und sollte eine Anzeige, wie ebenfalls nachfolgend dargestellt ausgeben:
# systemctl list-unit-files --type=service | grep -e ^unbound.service unbound.service enabled disabled
bzw.
# systemctl is-enabled unbound.service enabled
iptables/ip6tables Regeln
Damit der DNS-Server auch erreichbar ist und nicht die Weitergabe der DNS Informationen vom Paketfilter iptables und ip6tables blockiert wird, muss nachfolgende Regel zum iptables bzw. ip6tables-Regelwerk hinzugefügt werden.
Um die aktuellen iptables-Regeln erweitern zu können, sollten diese erst einmal aufgelistet werden, was mit nachfolgendem Befehl durchgeführt werden kann:
# iptables -nvL --line-numbers Chain INPUT (policy DROP 0 packets, 0 bytes) num pkts bytes target prot opt in out source destination 1 6 398 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED 2 0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 3 0 0 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0 4 0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:22 5 0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 5 prefix "REC-INP Defend " 6 0 0 REJECT tcp -- * * 0.0.0.0/0 0.0.0.0/0 reject-with tcp-reset 7 0 0 REJECT udp -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable 8 0 0 REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-proto-unreachable Chain FORWARD (policy DROP 0 packets, 0 bytes) num pkts bytes target prot opt in out source destination 1 0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 5 prefix "REC-FWD Defend " 2 0 0 REJECT tcp -- * * 0.0.0.0/0 0.0.0.0/0 reject-with tcp-reset 3 0 0 REJECT udp -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable 4 0 0 REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-proto-unreachable Chain OUTPUT (policy ACCEPT 8 packets, 478 bytes) num pkts bytes target prot opt in out source destination
Nachfolgende Befehle, fügen folgende iptables-Regeln dem iptables-Regelwerk nach der Position 4 hinzu, ohne das der Paketfilter angehalten werden muss:
-A INPUT -p tcp --dport 53 -j ACCEPT
-A INPUT -p udp --dport 53 -j ACCEPT
und hier die Befehle:
# iptables -I INPUT 5 -p tcp --dport 53 -j ACCEPT # iptables -I INPUT 6 -p udp --dport 53 -j ACCEPT
Ein erneute Abfrage des iptables-Regelwerts, sollte dann nachfolgend dargestellte Ausgabe ergeben, was mit folgendem Befehl durchgeführt werden kann:
# iptables -nvL --line-numbers Chain INPUT (policy DROP 0 packets, 0 bytes) num pkts bytes target prot opt in out source destination 1 29 15634 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED 2 0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 3 0 0 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0 4 0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:22 5 0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:53 6 0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:53 7 0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 5 prefix "REC-INP Defend " 8 0 0 REJECT tcp -- * * 0.0.0.0/0 0.0.0.0/0 reject-with tcp-reset 9 0 0 REJECT udp -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable 10 0 0 REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-proto-unreachable Chain FORWARD (policy DROP 0 packets, 0 bytes) num pkts bytes target prot opt in out source destination 1 0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 5 prefix "REC-FWD Defend " 2 0 0 REJECT tcp -- * * 0.0.0.0/0 0.0.0.0/0 reject-with tcp-reset 3 0 0 REJECT udp -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable 4 0 0 REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-proto-unreachable Chain OUTPUT (policy ACCEPT 38 packets, 4765 bytes) num pkts bytes target prot opt in out source destination Die neuen Zeilen sind an **Position 5 (INPUT)** und **Postition 6 (INPUT)** zu sehen, hier nachfolgend zur Verdeutlichung noch einmal dargestellt (**nur relevanter Ausschnitt**): <code> ... 5 0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:53 ... 1 0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:53 ...
Um diese iptables-Regel dauerhaft, auch nach einem Neustart des Server, weiterhin im iptables-Regelwerk zu speichern, muss nachfolgend dargestellter Befehl abschließend noch ausgeführt werden:
# /usr/sbin/iptables-save > /etc/iptables/iptables.rules
Nachfolgender Befehl kann dazu verwendet werden, um zu überprüfen, ob das iptables-Regelwerk auch korrekt gespeichert wurde:
# cat /etc/iptables/iptables.rules # Generated by iptables-save v1.8.7 on Mon Jul 12 16:38:03 2021 *mangle :PREROUTING ACCEPT [179:83438] :INPUT ACCEPT [179:83438] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [221:105831] :POSTROUTING ACCEPT [222:105904] COMMIT # Completed on Mon Jul 12 16:38:03 2021 # Generated by iptables-save v1.8.7 on Mon Jul 12 16:38:03 2021 *filter :INPUT DROP [0:0] :FORWARD DROP [0:0] :OUTPUT ACCEPT [221:105831] -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A INPUT -p icmp -j ACCEPT -A INPUT -i lo -j ACCEPT -A INPUT -p tcp -m tcp --dport 22 -j ACCEPT -A INPUT -p tcp -m tcp --dport 53 -j ACCEPT -A INPUT -p udp -m udp --dport 53 -j ACCEPT -A INPUT -j LOG --log-prefix "REC-INP Defend " --log-level 5 -A INPUT -p tcp -j REJECT --reject-with tcp-reset -A INPUT -p udp -j REJECT --reject-with icmp-port-unreachable -A INPUT -j REJECT --reject-with icmp-proto-unreachable -A FORWARD -j LOG --log-prefix "REC-FWD Defend " --log-level 5 -A FORWARD -p tcp -j REJECT --reject-with tcp-reset -A FORWARD -p udp -j REJECT --reject-with icmp-port-unreachable -A FORWARD -j REJECT --reject-with icmp-proto-unreachable COMMIT # Completed on Mon Jul 12 16:38:03 2021 # Generated by iptables-save v1.8.7 on Mon Jul 12 16:38:03 2021 *nat :PREROUTING ACCEPT [0:0] :INPUT ACCEPT [0:0] :OUTPUT ACCEPT [33:2171] :POSTROUTING ACCEPT [33:2171] COMMIT # Completed on Mon Jul 12 16:38:03 2021
Um die aktuellen ip6tables-Regeln erweitern zu können, sollten diese erst einmal aufgelistet werden, was mit nachfolgendem Befehl durchgeführt werden kann:
# ip6tables -nvL --line-numbers Chain INPUT (policy DROP 0 packets, 0 bytes) num pkts bytes target prot opt in out source destination 1 0 0 ACCEPT all * * ::/0 ::/0 ctstate RELATED,ESTABLISHED 2 0 0 ACCEPT icmp * * ::/0 ::/0 3 0 0 ACCEPT all lo * ::/0 ::/0 4 0 0 ACCEPT tcp * * ::/0 ::/0 tcp dpt:22 5 0 0 LOG all * * ::/0 ::/0 LOG flags 0 level 5 prefix "REC-INP Defend " 6 0 0 REJECT tcp * * ::/0 ::/0 reject-with tcp-reset 7 0 0 REJECT udp * * ::/0 ::/0 reject-with icmp6-port-unreachable 8 0 0 REJECT all * * ::/0 ::/0 reject-with icmp6-addr-unreachable Chain FORWARD (policy DROP 0 packets, 0 bytes) num pkts bytes target prot opt in out source destination 1 0 0 LOG all * * ::/0 ::/0 LOG flags 0 level 5 prefix "REC-FWD Defend " 2 0 0 REJECT tcp * * ::/0 ::/0 reject-with tcp-reset 3 0 0 REJECT udp * * ::/0 ::/0 reject-with icmp6-port-unreachable 4 0 0 REJECT all * * ::/0 ::/0 reject-with icmp6-addr-unreachable Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes) num pkts bytes target prot opt in out source destination
Nachfolgende Befehle, fügen folgende ip6tables-Regeln dem ip6tables-Regelwerk nach der Position 4 hinzu, ohne das der Paketfilter angehalten werden muss:
-A INPUT -p tcp --dport 53 -j ACCEPT
-A INPUT -p udp --dport 53 -j ACCEPT
und hier die Befehle:
# ip6tables -I INPUT 5 -p tcp --dport 53 -j ACCEPT # ip6tables -I INPUT 6 -p udp --dport 53 -j ACCEPT
Ein erneute Abfrage des ip6tables-Regelwerts, sollte dann nachfolgend dargestellte Ausgabe ergeben, was mit folgendem Befehl durchgeführt werden kann:
# ip6tables -nvL --line-numbers Chain INPUT (policy DROP 0 packets, 0 bytes) num pkts bytes target prot opt in out source destination 1 0 0 ACCEPT all * * ::/0 ::/0 ctstate RELATED,ESTABLISHED 2 0 0 ACCEPT icmp * * ::/0 ::/0 3 0 0 ACCEPT all lo * ::/0 ::/0 4 0 0 ACCEPT tcp * * ::/0 ::/0 tcp dpt:22 5 0 0 ACCEPT udp * * ::/0 ::/0 tcp dpt:53 6 0 0 ACCEPT udp * * ::/0 ::/0 udp dpt:53 7 0 0 LOG all * * ::/0 ::/0 LOG flags 0 level 5 prefix "REC-INP Defend " 8 0 0 REJECT tcp * * ::/0 ::/0 reject-with tcp-reset 9 0 0 REJECT udp * * ::/0 ::/0 reject-with icmp6-port-unreachable 10 0 0 REJECT all * * ::/0 ::/0 reject-with icmp6-addr-unreachable Chain FORWARD (policy DROP 0 packets, 0 bytes) num pkts bytes target prot opt in out source destination 1 0 0 LOG all * * ::/0 ::/0 LOG flags 0 level 5 prefix "REC-FWD Defend " 2 0 0 REJECT tcp * * ::/0 ::/0 reject-with tcp-reset 3 0 0 REJECT udp * * ::/0 ::/0 reject-with icmp6-port-unreachable 4 0 0 REJECT all * * ::/0 ::/0 reject-with icmp6-addr-unreachable Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes) num pkts bytes target prot opt in out source destination
Die neuen Zeilen sind an Position 5 (INPUT) und Postition 6 (INTPUT) zu sehen, hier nachfolgend zur Verdeutlichung noch einmal dargestellt (nur relevanter Ausschnitt):
... 5 0 0 ACCEPT tcp * * ::/0 ::/0 tcp dpt:53 ... 1 0 0 ACCEPT udp * * ::/0 ::/0 udp dpt:53 ...
Um diese ip6tables-Regel dauerhaft, auch nach einem Neustart des Server, weiterhin im ip6tables-Regelwerk zu speichern, muss nachfolgend dargestellter Befehl abschließend noch ausgeführt werden:
# /usr/sbin/ip6tables-save > /etc/iptables/ip6tables.rules
Nachfolgender Befehl kann dazu verwendet werden, um zu überprüfen, ob das ip6tables-Regelwerk auch korrekt gespeichert wurde:
# cat /etc/iptables/ip6tables.rules # Generated by ip6tables-save v1.8.7 on Mon Jul 12 16:48:38 2021 *mangle :PREROUTING ACCEPT [0:0] :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [0:0] :POSTROUTING ACCEPT [0:0] COMMIT # Completed on Mon Jul 12 16:48:38 2021 # Generated by ip6tables-save v1.8.7 on Mon Jul 12 16:48:38 2021 *filter :INPUT DROP [0:0] :FORWARD DROP [0:0] :OUTPUT ACCEPT [0:0] -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A INPUT -p icmp -j ACCEPT -A INPUT -i lo -j ACCEPT -A INPUT -p tcp -m tcp --dport 22 -j ACCEPT -A INPUT -p tcp -m tcp --dport 53 -j ACCEPT -A INPUT -p udp -m udp --dport 53 -j ACCEPT -A INPUT -j LOG --log-prefix "REC-INP Defend " --log-level 5 -A INPUT -p tcp -j REJECT --reject-with tcp-reset -A INPUT -p udp -j REJECT --reject-with icmp6-port-unreachable -A INPUT -j REJECT --reject-with icmp6-addr-unreachable -A FORWARD -j LOG --log-prefix "REC-FWD Defend " --log-level 5 -A FORWARD -p tcp -j REJECT --reject-with tcp-reset -A FORWARD -p udp -j REJECT --reject-with icmp6-port-unreachable -A FORWARD -j REJECT --reject-with icmp6-addr-unreachable COMMIT # Completed on Mon Jul 12 16:48:38 2021 # Generated by ip6tables-save v1.8.7 on Mon Jul 12 16:48:38 2021 *nat :PREROUTING ACCEPT [0:0] :INPUT ACCEPT [0:0] :OUTPUT ACCEPT [0:0] :POSTROUTING ACCEPT [0:0] COMMIT # Completed on Mon Jul 12 16:48:38 2021
Basis-Konfiguration
Bevor mit der eigentliches Basis-Konfiguration begonnen werden kann sind noch nachfolgende Vorarbeiten durchzuführen.
/etc/unbound/keys
In nachfolgendem Verzeichnis
/etc/unbound/keys
welches mit nachfolgendem Befehl erstellt werden kann
# mkdir /etc/unbound/keys
benötigt der Benutzer unter dem der unbound läuft, die entsprechenden Besitzrechte und Dateirechte, was mit nachfolgenden Befehl durchgeführt werden kann:
Besitzrechte:
# chown unbound:unbound /etc/unbound/keys
Dateirechte:
# chmod 764 /etc/unbound/keys
HINWEIS - Dies ist erforderlich, damit der unbound evtl. zusätzliche KSK (Key signing Keys), welche sich ggf. in diesem Verzeichnis befinden, entsprechend der Verwendung von unbound um konvertieren kann!
Anschliessend sollen nun weitere KSK's (Key Signing Keys) z.B. aus nachfolgender ISC (Internet System Consortium) BIND Installation mit nachfolgendem Befehl in dieses Verzeichnis kopiert werden:
# cp -a /var/named/keys/*.key /etc/unbound/keys
Abschliessend sind hier noch die Besitzrechte und die Dateirechte, wie folgt anzupassen:
Besitzrechte:
# chown unbound:unbound /etc/unbound/keys/*.key
Dateirechte:
# chmod 664 /etc/unbound/keys/*.key
Mit nachfolgendem Befehl kann nun überprüft werden, ob das entsprechende Verzeichnis erstellt wurde und ie richtigen Besitzrechte und Dateirechte erhalten hat:
# ls -l /etc/unbound total 52 drwxrw-r-- 1 unbound unbound 824 Nov 28 10:25 keys -rw-r--r-- 1 root root 738 Oct 13 2020 trusted-key.key -rw-r--r-- 1 root root 46251 Aug 14 13:15 unbound.conf
Anschließend kann noch mit nachfolgendem Befehl überprüft werden, ob die entsprechenden keys aus der einer entsprechenden Konfiguration des DNS ISC bind Archlinux - DNSSec richtig kopiert wurden:
# ls -l # ls -l /var/named/keys total 64 -rw-rw-r-- 1 unbound unbound 318 Nov 6 08:26 K0.168.192.in-addr.arpa.+015+64298.key -rw-rw-r-- 1 unbound unbound 319 Nov 6 08:28 K0.168.192.in-addr.arpa.+015+65325.key -rw-rw-r-- 1 unbound unbound 320 Nov 6 08:28 K171.217.88.in-addr.arpa.+015+05640.key -rw-rw-r-- 1 unbound unbound 320 Nov 6 08:27 K171.217.88.in-addr.arpa.+015+59631.key -rw-rw-r-- 1 unbound unbound 309 Nov 6 08:25 Kintra.tachtler.net.+015+02340.key -rw-rw-r-- 1 unbound unbound 311 Nov 6 08:27 Kintra.tachtler.net.+015+17796.key -rw-rw-r-- 1 unbound unbound 298 Nov 6 08:26 Ktachtler.net.+015+20289.key -rw-rw-r-- 1 unbound unbound 299 Nov 6 08:28 Ktachtler.net.+015+37463.key
/etc/unbound/root.hints
Anstatt Anfragen an einen öffentlichen DNS-Server (wie z.B. Google 8.8.8.8), oder einen DNS-Server des ISP (Internet Service Providers wie z.B. die Telekom) weiterzuleiten, kann es vorgezogen werden, die Root-DNS-Server abzufragen. Nachfolgender Befehl holt die neueste Root-Server-Liste als Datei ab.
HINWEIS - Dies wird später eingebunden, indem die Weiterleitungseinträge („Forwardzone“-Abschnitte) in der Konfiguration ausgewählt werden.
# dig +bufsize=1200 +norec NS . @a.root-servers.net > /etc/unbound/root.hints
Auch hier kann mit nachfolgendem Befehl überprüft werden, ob der Inhalt der Konfigurationsdatei korrekt erstellt worden ist und sollte eine Ausgabe wie nachfolgende in etwa zurückgeben:
# cat root.hints ; <<>> DiG 9.16.23 <<>> +bufsize +norec NS . @a.root-servers.net ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31895 ;; flags: qr aa; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 27 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;. IN NS ;; ANSWER SECTION: . 518400 IN NS e.root-servers.net. . 518400 IN NS h.root-servers.net. . 518400 IN NS l.root-servers.net. . 518400 IN NS i.root-servers.net. . 518400 IN NS a.root-servers.net. . 518400 IN NS d.root-servers.net. . 518400 IN NS c.root-servers.net. . 518400 IN NS b.root-servers.net. . 518400 IN NS j.root-servers.net. . 518400 IN NS k.root-servers.net. . 518400 IN NS g.root-servers.net. . 518400 IN NS m.root-servers.net. . 518400 IN NS f.root-servers.net. ;; ADDITIONAL SECTION: e.root-servers.net. 518400 IN A 192.203.230.10 e.root-servers.net. 518400 IN AAAA 2001:500:a8::e h.root-servers.net. 518400 IN A 198.97.190.53 h.root-servers.net. 518400 IN AAAA 2001:500:1::53 l.root-servers.net. 518400 IN A 199.7.83.42 l.root-servers.net. 518400 IN AAAA 2001:500:9f::42 i.root-servers.net. 518400 IN A 192.36.148.17 i.root-servers.net. 518400 IN AAAA 2001:7fe::53 a.root-servers.net. 518400 IN A 198.41.0.4 a.root-servers.net. 518400 IN AAAA 2001:503:ba3e::2:30 d.root-servers.net. 518400 IN A 199.7.91.13 d.root-servers.net. 518400 IN AAAA 2001:500:2d::d c.root-servers.net. 518400 IN A 192.33.4.12 c.root-servers.net. 518400 IN AAAA 2001:500:2::c b.root-servers.net. 518400 IN A 199.9.14.201 b.root-servers.net. 518400 IN AAAA 2001:500:200::b j.root-servers.net. 518400 IN A 192.58.128.30 j.root-servers.net. 518400 IN AAAA 2001:503:c27::2:30 k.root-servers.net. 518400 IN A 193.0.14.129 k.root-servers.net. 518400 IN AAAA 2001:7fd::1 g.root-servers.net. 518400 IN A 192.112.36.4 g.root-servers.net. 518400 IN AAAA 2001:500:12::d0d m.root-servers.net. 518400 IN A 202.12.27.33 m.root-servers.net. 518400 IN AAAA 2001:dc3::35 f.root-servers.net. 518400 IN A 192.5.5.241 f.root-servers.net. 518400 IN AAAA 2001:500:2f::f ;; Query time: 40 msec ;; SERVER: 198.41.0.4#53(198.41.0.4) ;; WHEN: Sun Nov 28 12:08:03 CET 2021 ;; MSG SIZE rcvd: 811
remote-control
Es kann eine Kontrolle über den unbound DNS-Resolver mittels dem Befehl unbound-control eingerichtet werden. Dazu ist es zunächst erforderlich, mit nachfolgendem Befehl
unbound-control-setup
die erforderlichen TLS-Schlüsseldateien automatisch im Standardinstallationsverzeichnis
/etc/unbound
zu erzeugen, wie nachfolgend dargestellt:
# unbound-control-setup setup in directory /etc/unbound Generating RSA private key, 3072 bit long modulus (2 primes) ..........................++++ ........++++ e is 65537 (0x010001) Generating RSA private key, 3072 bit long modulus (2 primes) .....................................................................................................++++ ....................++++ e is 65537 (0x010001) Signature ok subject=CN = unbound-control Getting CA Private Key removing artifacts Setup success. Certificates created. Enable in unbound.conf file to use
Eine Überprüfung, ob das ordnungsgemäss durchgeführt wurden, kann mit nachfolgendem Befehl durchgeführt werden:
# ls -l /etc/unbound/unbound_* -rw------- 1 root root 2455 Dec 11 08:33 /etc/unbound/unbound_control.key -rw-r----- 1 root root 1411 Dec 11 08:33 /etc/unbound/unbound_control.pem -rw------- 1 root root 2459 Dec 11 08:33 /etc/unbound/unbound_server.key -rw-r----- 1 root root 1549 Dec 11 08:33 /etc/unbound/unbound_server.pem
Eine Beschreibung der möglichen Aktionen, welche mittels dem Befehl unbound-control durchgeführt werden können, gibt die man-Page zum Befehl aus.
Nachfolgend eine Beispiel, wenn die Konfiguration in /etc/unbound/unbound.conf durchgeführt wurde und der unbound DNS-Resolver gestartet wurde:
# unbound-control status version: 1.13.2 verbosity: 1 threads: 1 modules: 3 [ subnetcache validator iterator ] uptime: 6 seconds options: reuseport control(ssl) unbound (pid 36998) is running...
HINWEIS - Standardmäßig ist der unbound-control Service unter localhost Port 8953 zu erreichen!
/etc/unbound/unbound.conf
Da die Konfigurationsdatei /etc/unbound/unbound.conf aufgrund von Kommentar- und Leerzeichen sehr schnell unübersichtlich ist, kann mit nachfolgendem Befehl, eine Ausgabe ohne Kommentar- und Leerzeilen erzeugt werden, welche dann nach der Grundinstallation von unbound wie folgt aussehen sollte:
# egrep -v '(^#|^.*#|^$)' /etc/unbound/unbound.conf
Die Konfigurationsdatei /etc/unbound/unbound.conf ohne Kommentar- und Leerzeichen:
# egrep -v '(^#|^.*#|^$)' /etc/unbound/unbound.conf server: verbosity: 1 trust-anchor-file: /etc/unbound/trusted-key.key python: dynlib: remote-control:
Nachfolgende Änderungen wurden beispielhaft vorgenommen:
interface: 192.168.0.20
Interface, auf denen der unbound Anfragen entgegen nimmt.
outgoing-interface: 192.168.0.20
Interface, auf denen der unbound Anfragen weiterleitet/bzw. stellt.
HINWEIS - Es kann auch ein Interface sein, auf dem der unbound gar nicht lauscht!
access-control: 127.0.0.0/8 allow_snoop access-control: 192.168.0.0/24 allow access-control: 88.217.171.167/32 allow
Von welchen Netzwerken bzw. IP-Adressen Anfragen entgegengenommen werden.
Wenn unbound, die +trace-Funktion von dig ebenfalls ausführen soll, kann unbound so konfiguriert werden, dass dieser iterative (nicht rekursive) Abfragen ermöglicht. Dies geschieht durch die Verwendung der Option allow_snoop, anstelle von allow in der access-control: Konfiguration.
HINWEIS - Aus Sicherheitsgründen wird empfohlen, allow_snoop nur für administrative Netzwerke zu aktivieren, nicht für die allgemeinen Client-Netzwerke, die den unbound DNS-Server verwenden!
root-hints: "/etc/unbound/root.hints"
Einbinden der der ROOT-Server-Liste, da anstatt Anfragen an einen öffentlichen DNS-Server (wie z.B. Google 8.8.8.8), oder einen DNS-Server des ISP (Internet Service Providers wie z.B. die Telekom) weiterzuleiten, sollen die Root-DNS-Server verwendet werden.
hide-identity: yes
Anfragen von id.server und hostname.bind sollen nicht beantwortet werden.
hide-version: yes
Anfragen von version.server und version.bind sollen nicht beantwortet werden.
do-not-query-localhost: no
Erlaube Verbindungen auch zu localhost.
HINWEIS - Diese Einstellung ist entscheiden, wenn der dahinter liegende DNS-Server z.B. nur auf 127.0.0.1 lauscht !!!
auto-trust-anchor-file: "/etc/unbound/keys/K0.168.192.in-addr.arpa.+015+64298.key" auto-trust-anchor-file: "/etc/unbound/keys/K0.168.192.in-addr.arpa.+015+65325.key" auto-trust-anchor-file: "/etc/unbound/keys/K167.171.217.88.in-addr.arpa.+015+05640.key" auto-trust-anchor-file: "/etc/unbound/keys/K167.171.217.88.in-addr.arpa.+015+59631.key" auto-trust-anchor-file: "/etc/unbound/keys/Kintra.tachtler.net.+015+02340.key" auto-trust-anchor-file: "/etc/unbound/keys/Kintra.tachtler.net.+015+17796.key" auto-trust-anchor-file: "/etc/unbound/keys/Ktachtler.net.+015+20289.key" auto-trust-anchor-file: "/etc/unbound/keys/Ktachtler.net.+015+37463.key"
Erweitern der auto-trust-anchor-file Angaben um weitere KSK (Key Signing Keys), damit die Chain-of-Trust / Vertrauenskette auch für lokale Zonen abgefragt werden kann und eingehalten wird!
trusted-keys-file: "/etc/unbound/keys/*.key"
Erweitern der trusted-keys-file Angabe um weitere KSK (Key Signing Keys), damit die Chain-of-Trust / Vertrauenskette auch für lokale Zonen abgefragt werden kann und eingehalten wird!
domain-insecure: "localhost." domain-insecure: "1.0.0.127.in-addr.arpa." domain-insecure: "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa."
Damit auch eine forward Anfrage nach localhost und eine reverse Anfrage nach 127.0.0.1 erfolgreich beantwortet werden können, ist es erforderlich diese von den DNSSec gesicherten Zonen auszunehmen.
# Tachtler local-zone: "localhost." nodefault local-zone: "127.in-addr.arpa." nodefault local-zone: "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa." nodefault # local-zone: "onion." nodefault # local-zone: "test." nodefault # local-zone: "invalid." nodefault # local-zone: "10.in-addr.arpa." nodefault # local-zone: "16.172.in-addr.arpa." nodefault # local-zone: "17.172.in-addr.arpa." nodefault # local-zone: "18.172.in-addr.arpa." nodefault # local-zone: "19.172.in-addr.arpa." nodefault # local-zone: "20.172.in-addr.arpa." nodefault # local-zone: "21.172.in-addr.arpa." nodefault # local-zone: "22.172.in-addr.arpa." nodefault # local-zone: "23.172.in-addr.arpa." nodefault # local-zone: "24.172.in-addr.arpa." nodefault # local-zone: "25.172.in-addr.arpa." nodefault # local-zone: "26.172.in-addr.arpa." nodefault # local-zone: "27.172.in-addr.arpa." nodefault # local-zone: "28.172.in-addr.arpa." nodefault # local-zone: "29.172.in-addr.arpa." nodefault # local-zone: "30.172.in-addr.arpa." nodefault # local-zone: "31.172.in-addr.arpa." nodefault local-zone: "168.192.in-addr.arpa." nodefault local-zone: "0.in-addr.arpa." nodefault # local-zone: "254.169.in-addr.arpa." nodefault # local-zone: "2.0.192.in-addr.arpa." nodefault # local-zone: "100.51.198.in-addr.arpa." nodefault # local-zone: "113.0.203.in-addr.arpa." nodefault # local-zone: "255.255.255.255.in-addr.arpa." nodefault # local-zone: "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa." nodefault # local-zone: "d.f.ip6.arpa." nodefault # local-zone: "8.e.f.ip6.arpa." nodefault # local-zone: "9.e.f.ip6.arpa." nodefault # local-zone: "a.e.f.ip6.arpa." nodefault # local-zone: "b.e.f.ip6.arpa." nodefault # local-zone: "8.b.d.0.1.0.0.2.ip6.arpa." nodefault # And for 64.100.in-addr.arpa. to 127.100.in-addr.arpa.
Damit auch eine reverse Anfrage zum erfolgt führt, ist die Definition der local-zome wichtig. Dies muss für alle Zonen durchgeführt werden für die eine reverse Auflösung zu einem Ergebnis führen soll.
HINWEIS - Wenn keine local-zone Definitionen durchgeführt werden, werden für diese KEINE reverse Anfragen beantwortet !!!
Beispiel bei NICHT-Definition
# dig @192.168.0.20 -x 192.168.0.10 ; <<>> DiG 9.16.23 <<>> @192.168.0.20 -x 192.168.0.10 ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 20189 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ;; QUESTION SECTION: ;10.0.168.192.in-addr.arpa. IN PTR ;; AUTHORITY SECTION: 168.192.in-addr.arpa. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800 ;; Query time: 0 msec ;; SERVER: 192.168.0.20#53(192.168.0.20) ;; WHEN: Sun Nov 28 17:39:46 CET 2021 ;; MSG SIZE rcvd: 113
remote-control: control-enable: yes server-key-file: "/etc/unbound/unbound_server.key" server-cert-file: "/etc/unbound/unbound_server.pem" control-key-file: "/etc/unbound/unbound_control.key" control-cert-file: "/etc/unbound/unbound_control.pem"
Eine Kontrolle über den Befehl unbound-control soll ermöglicht werden.
forward-zone: name: "localhost" forward-addr: 127.0.0.1 forward-zone: name: "1.0.0.127.in-addr.arpa" forward-addr: 127.0.0.1 forward-zone: name: "tachtler.net" forward-addr: 127.0.0.1 forward-zone: name: "0.168.192.in-addr.arpa" forward-addr: 127.0.0.1 forward-zone: name: "167.171.217.88.in-addr.arpa" forward-addr: 127.0.0.1
Interne Anfragen sollen an den DNS-Server, welcher auf der IP-Adresse 127.0.0.1 lauscht weitergeleitet werden. Alle anderen Anfragen, sollen an die ROOT-Server-(Liste) gesendet werden.
HINWEIS - Dies könnte hier z.B. ein Authorativer DNS-Server sein, siehe auch den internen Link:
Die Konfigurationsdatei /etc/unbound/unbound.conf ohne Kommentar- und Leerzeichen inklusive der Änderungen:
# egrep -v '(^#|^.*#|^$)' /etc/unbound/unbound.conf server: verbosity: 1 interface: 192.168.0.20 outgoing-interface: 192.168.0.20 access-control: 127.0.0.0/8 allow_snoop access-control: 192.168.0.0/24 allow access-control: 88.217.171.167/32 allow root-hints: "/etc/unbound/root.hints" hide-identity: yes hide-version: yes do-not-query-localhost: no auto-trust-anchor-file: "/etc/unbound/keys/K0.168.192.in-addr.arpa.+015+64298.key" auto-trust-anchor-file: "/etc/unbound/keys/K0.168.192.in-addr.arpa.+015+65325.key" auto-trust-anchor-file: "/etc/unbound/keys/K167.171.217.88.in-addr.arpa.+015+05640.key" auto-trust-anchor-file: "/etc/unbound/keys/K167.171.217.88.in-addr.arpa.+015+59631.key" auto-trust-anchor-file: "/etc/unbound/keys/Kintra.tachtler.net.+015+02340.key" auto-trust-anchor-file: "/etc/unbound/keys/Kintra.tachtler.net.+015+17796.key" auto-trust-anchor-file: "/etc/unbound/keys/Ktachtler.net.+015+20289.key" auto-trust-anchor-file: "/etc/unbound/keys/Ktachtler.net.+015+37463.key" trust-anchor-file: /etc/unbound/trusted-key.key trusted-keys-file: "/etc/unbound/keys/*.key" domain-insecure: "localhost." domain-insecure: "1.0.0.127.in-addr.arpa." domain-insecure: "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa." local-zone: "localhost." nodefault local-zone: "127.in-addr.arpa." nodefault local-zone: "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa." nodefault local-zone: "168.192.in-addr.arpa." nodefault local-zone: "0.in-addr.arpa." nodefault python: dynlib: remote-control: control-enable: yes server-key-file: "/etc/unbound/unbound_server.key" server-cert-file: "/etc/unbound/unbound_server.pem" control-key-file: "/etc/unbound/unbound_control.key" control-cert-file: "/etc/unbound/unbound_control.pem" forward-zone: name: "localhost" forward-addr: 127.0.0.1 forward-zone: name: "1.0.0.127.in-addr.arpa" forward-addr: 127.0.0.1 forward-zone: name: "tachtler.net" forward-addr: 127.0.0.1 forward-zone: name: "0.168.192.in-addr.arpa" forward-addr: 127.0.0.1 forward-zone: name: "167.171.217.88.in-addr.arpa" forward-addr: 127.0.0.1
Konfigurationsdatei Überprüfung
Mit nachfolgendem Befehl kann die syntaktische Richtigkeit der Konfigurationsdatei:
/etc/unbound/unbound.conf
durchgeführt werden und sollte keine Meldungen ausgeben, wenn die Konfigurationsdatei syntaktische richtig ist:
# /usr/sbin/unbound-checkconf /etc/unbound/unbound.conf unbound-checkconf: no errors in /etc/unbound/unbound.conf
Erster Start
Falls alle voranstehenden Schritte wie beschrieben durchgeführt wurden, Installation, Basis-Konfiguration, sollte dem ersten Start nichts im Wege stehen und dies mit nachfolgendem Befehl durchgeführt werden:
# systemctl start unbound.service
Mit nachfolgendem Befehl kann überprüft werden, ob der erste Start erfolgreich durchgeführt wurde:
# systemctl status unbound.service
● unbound.service - Validating, recursive, and caching DNS resolver
Loaded: loaded (/etc/systemd/system/unbound.service; enabled; vendor preset: disabled)
Active: active (running) since Tue 2021-11-30 16:08:17 CET; 44s ago
Docs: man:unbound(8)
Main PID: 44109 (unbound)
Tasks: 1 (limit: 2346)
Memory: 6.7M
CPU: 96ms
CGroup: /system.slice/unbound.service
└─44109 /usr/bin/unbound -d -p
Nov 30 16:08:17 vml020 systemd[1]: Starting Validating, recursive, and caching DNS resolver...
Nov 30 16:08:17 vml020 unbound[44109]: [1638284897] unbound[44109:0] warning: IPv6 protocol not available
Nov 30 16:08:17 vml020 unbound[44109]: [44109:0] notice: init module 0: subnetcache
Nov 30 16:08:17 vml020 unbound[44109]: [44109:0] notice: init module 1: validator
Nov 30 16:08:17 vml020 unbound[44109]: [44109:0] notice: init module 2: iterator
Nov 30 16:08:17 vml020 unbound[44109]: [44109:0] info: start of service (unbound 1.13.2).
Nov 30 16:08:17 vml020 systemd[1]: Started Validating, recursive, and caching DNS resolver.
Überprüfung
Ziel ist es eine lokale Antwort –>
rechner10.intra.tachtler.net IN A 192.168.0.10
zu erhalten, welche via
- DNSSec abgesichert ist und
- bei der die (DNS) Chain-of-Trust (Vertrauenskette)
im lokalen Netzwerk überprüfbar ist, was durch
- das
ad-Flag
in der Antwort bestätigt wird.
(Siehe nachfolgendes Beispiel)
# dig @192.168.0.20 rechner10.intra.tachtler.net +dnssec +multi ; <<>> DiG 9.16.23 <<>> @192.168.0.20 rechner10.intra.tachtler.net +dnssec +multi ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36662 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 1232 ;; QUESTION SECTION: ;rechner10.intra.tachtler.net. IN A ;; ANSWER SECTION: rechner10.intra.tachtler.net. 10800 IN A 192.168.0.10 rechner10.intra.tachtler.net. 10800 IN RRSIG A 15 4 10800 ( 20211217203021 20211130133211 10887 intra.tachtler.net. Ds49XZOZ1p87ygjVtBYPk5qZED3MmbVybLoKIc8o4KPW P4xhS3R1Z9rAWBjHMi2XGxqIn7BB403SUh1quM03CA== ) ;; Query time: 20 msec ;; SERVER: 192.168.0.20#53(192.168.0.20) ;; WHEN: Tue Nov 30 16:11:49 CET 2021 ;; MSG SIZE rcvd: 187
HINWEIS - Nachfolgend muss das ad-Flag in der Antwort enthalten sein, siehe nachfolgende Zeile:
;; flags: qr rd raad;QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1