Dies ist eine alte Version des Dokuments!
Inhaltsverzeichnis
DNS unbound CentOS 7
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 | | 192.168.1.20 | | 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 –>
tachtler.net IN A 192.168.0.90
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 @127.0.0.2 tachtler.net +dnssec +multi ; <<>> DiG 9.9.4-RedHat-9.9.4-61.el7_5.1 <<>> @192.168.0.20 tachtler.net +dnssec +multi ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33980 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;tachtler.net. IN A ;; ANSWER SECTION: tachtler.net. 10777 IN A 192.168.0.90 tachtler.net. 10777 IN RRSIG A 10 2 10800 ( 20181002054109 20180902050808 13937 tachtler.net. tI018q4i7QVSIirCjMwFfAH9C2nVHBrz6WuM7VZFv7hF yLRM4a0m6siKLxtYGBX1IAqS4BjRJqWyskgejdkogr9y T6iMLrRNGLh2PcZH2auApuK7QKqtMb4U2iCeJ/TsEH6g gW848ljS6Zz9EaVFBlyxyYm3BSXBIJpHFKRN1msh7L0F NPe3gwXkwoj1X/QP7R6/lF52G4MA6GwAhX2yWmM3ofVh 4zIQKEZ211k148Txy6pnifyOZeNEhKrp/Rajg4HkZ/Ob F+Betj/Dpsu4yhEG79tRZ5xZh8rDbtlpP9Rcc6UDIgf8 RbDxdRARtlOGoe8GuG4ga7s19w1VdT8ayw== ) ;; Query time: 0 msec ;; SERVER: 192.168.0.20#53(192.168.0.20) ;; WHEN: Tue Sep 04 08:34:44 CEST 2018 ;; MSG SIZE rcvd: 357
HINWEIS - Nachfolgend muss das ad
-Flag in der Antwort enthalten sein, siehe nachfolgende Zeile:
;; flags: qr rd ra
ad
;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 drei Zonen durchgeführt werden. Nachfolgende Zonen werden dabei ausgeliefert:
- IDMZ - Domain: idmz.tachtler.net - IP-Adressbereich: 192.168.0.0/24
- EDMZ - Domain: edmz.tachtler.net - IP-Adressbereich: 192.168.1.0/24
- Intranet - Domain: intra.tachtler.net - IP-Adressbereich: 192.168.2.0/24
HINWEIS - IPv6 soll NICHT genutzt werden!!!
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:
# yum install unbound Loaded plugins: changelog, priorities base | 3.6 kB 00:00 epel | 3.2 kB 00:00 extras | 3.4 kB 00:00 icinga-stable-release | 2.5 kB 00:00 updates | 3.4 kB 00:00 164 packages excluded due to repository priority protections Resolving Dependencies --> Running transaction check ---> Package unbound.x86_64 0:1.6.6-1.el7 will be installed --> Processing Dependency: unbound-libs(x86-64) = 1.6.6-1.el7 for package: unbound-1.6.6-1.el7.x86_64 --> Processing Dependency: libunbound.so.2()(64bit) for package: unbound-1.6.6-1.el7.x86_64 --> Processing Dependency: libevent-2.0.so.5()(64bit) for package: unbound-1.6.6-1.el7.x86_64 --> Running transaction check ---> Package libevent.x86_64 0:2.0.21-4.el7 will be installed ---> Package unbound-libs.x86_64 0:1.6.6-1.el7 will be installed --> Finished Dependency Resolution Changes in packages about to be updated: Dependencies Resolved ================================================================================ Package Arch Version Repository Size ================================================================================ Installing: unbound x86_64 1.6.6-1.el7 base 673 k Installing for dependencies: libevent x86_64 2.0.21-4.el7 base 214 k unbound-libs x86_64 1.6.6-1.el7 base 405 k Transaction Summary ================================================================================ Install 1 Package (+2 Dependent packages) Total download size: 1.3 M Installed size: 4.2 M Is this ok [y/d/N]: y Downloading packages: (1/3): libevent-2.0.21-4.el7.x86_64.rpm | 214 kB 00:00 (2/3): unbound-1.6.6-1.el7.x86_64.rpm | 673 kB 00:00 (3/3): unbound-libs-1.6.6-1.el7.x86_64.rpm | 405 kB 00:00 -------------------------------------------------------------------------------- Total 2.4 MB/s | 1.3 MB 00:00 Running transaction check Running transaction test Transaction test succeeded Running transaction Installing : libevent-2.0.21-4.el7.x86_64 1/3 Installing : unbound-libs-1.6.6-1.el7.x86_64 2/3 Installing : unbound-1.6.6-1.el7.x86_64 3/3 Verifying : libevent-2.0.21-4.el7.x86_64 1/3 Verifying : unbound-1.6.6-1.el7.x86_64 2/3 Verifying : unbound-libs-1.6.6-1.el7.x86_64 3/3 Installed: unbound.x86_64 0:1.6.6-1.el7 Dependency Installed: libevent.x86_64 0:2.0.21-4.el7 unbound-libs.x86_64 0:1.6.6-1.el7 Complete!
Mit nachfolgendem Befehl kann überprüft werden, welche Inhalte mit den Paket unbound
installiert wurden:
# rpm -qil unbound Name : unbound Version : 1.6.6 Release : 1.el7 Architecture: x86_64 Install Date: Mon 03 Sep 2018 07:29:36 PM CEST Group : System Environment/Daemons Size : 2528522 License : BSD Signature : RSA/SHA256, Wed 25 Apr 2018 01:49:56 PM CEST, Key ID 24c6a8a7f4a80eb5 Source RPM : unbound-1.6.6-1.el7.src.rpm Build Date : Wed 11 Apr 2018 04:17:19 AM CEST Build Host : x86-01.bsys.centos.org Relocations : (not relocatable) Packager : CentOS BuildSystem <http://bugs.centos.org> Vendor : CentOS URL : https://unbound.net/ Summary : Validating, recursive, and caching DNS(SEC) resolver Description : Unbound is a validating, recursive, and caching DNS(SEC) resolver. The C implementation of Unbound is developed and maintained by NLnet Labs. It is based on ideas and algorithms taken from a java prototype developed by Verisign labs, Nominet, Kirei and ep.net. Unbound is designed as a set of modular components, so that also DNSSEC (secure DNS) validation and stub-resolvers (that do not run as a server, but are linked into an application) are easily possible. /etc/sysconfig/unbound /etc/unbound/conf.d /etc/unbound/conf.d/example.com.conf /etc/unbound/keys.d /etc/unbound/keys.d/example.com.key /etc/unbound/local.d /etc/unbound/local.d/block-example.com.conf /etc/unbound/unbound.conf /usr/lib/systemd/system/unbound-keygen.service /usr/lib/systemd/system/unbound.service /usr/lib/tmpfiles.d/unbound.conf /usr/sbin/unbound /usr/sbin/unbound-checkconf /usr/sbin/unbound-control /usr/sbin/unbound-control-setup /usr/sbin/unbound-host /usr/sbin/unbound-streamtcp /usr/share/doc/unbound-1.6.6 /usr/share/doc/unbound-1.6.6/CREDITS /usr/share/doc/unbound-1.6.6/FEATURES /usr/share/doc/unbound-1.6.6/LICENSE /usr/share/doc/unbound-1.6.6/README /usr/share/man/man1/unbound-host.1.gz /usr/share/man/man1/unbound-streamtcp.1.gz /usr/share/man/man5/unbound.conf.5.gz /usr/share/man/man8/unbound-anchor.8.gz /usr/share/man/man8/unbound-checkconf.8.gz /usr/share/man/man8/unbound-control-setup.8.gz /usr/share/man/man8/unbound-control.8.gz /usr/share/man/man8/unbound.8.gz /var/run/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 from /etc/systemd/system/multi-user.target.wants/unbound.service to /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
bzw.
# systemctl is-enabled unbound.service enabled
iptables Regel
Damit der DNS-Resolver auch erreichbar ist und nicht die Weitergabe der Namensauflösungsinformationen vom Paketfilter iptables
blockiert wird, muss nachfolgende Regel zum iptables
-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 -L -nv --line-numbers Chain INPUT (policy ACCEPT 0 packets, 0 bytes) num pkts bytes target prot opt in out source destination 1 0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state 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 state NEW tcp dpt:22 5 0 0 REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) num pkts bytes target prot opt in out source destination 1 0 0 REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited Chain OUTPUT (policy ACCEPT 0 packets, 0 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 5 -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 -L -nv --line-numbers Chain INPUT (policy ACCEPT 0 packets, 0 bytes) num pkts bytes target prot opt in out source destination 1 0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state 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 state NEW tcp dpt:22 5 0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:53 6 0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:53 7 0 0 REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) num pkts bytes target prot opt in out source destination 1 0 0 REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited Chain OUTPUT (policy ACCEPT 6 packets, 936 bytes) num pkts bytes target prot opt in out source destination
Die neuen Zeilen sind an Position 5 und Postition 6 zu sehen, hier nachfolgend zur Verdeutlichung noch einmal dargestellt (nur relevanter Ausschnitt):
... 5 0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:53 6 0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp 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/sysconfig/iptables
Basis-Konfiguration
Bevor mit der eigentliches Basis-Konfiguration begonnen werden kann sind noch nachfolgende Vorarbeiten durchzuführen.
/etc/unbound/keys.d
Auf nachfolgendes Verzeichnis /etc/unbound/keys.d
benötigt der Benutzer unter dem der unbound läuft, Schreibrechte, was mit nachfolgendem Befehl gesetzt werden kann:
# chmod g+w /etc/unbound/keys.d
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 /etc/dnssec/Ktachtler.net.+010+41592.key /etc/unbound/keys.d # cp -a /etc/dnssec/K171.217.88.in-addr.arpa.+010+05364 /etc/unbound/keys.d
Abschliessend sind hier noch die Besitzrechte und die Dateirechte, wie folgt anzupassen:
Besitzrechte:
# chown root:unbound /etc/unbound/keys.d/*.key
Dateirechte:
# chmod 664 /etc/unbound/keys.d/*.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
/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 statistics-interval: 0 statistics-cumulative: no extended-statistics: yes num-threads: 4 interface-automatic: no so-reuseport: yes ip-transparent: yes chroot: "" username: "unbound" directory: "/etc/unbound" log-time-ascii: yes pidfile: "/var/run/unbound/unbound.pid" harden-glue: yes harden-dnssec-stripped: yes harden-below-nxdomain: yes harden-referral-path: yes unwanted-reply-threshold: 10000000 prefetch: yes prefetch-key: yes rrset-roundrobin: yes minimal-responses: yes module-config: "ipsecmod validator iterator" trust-anchor-signaling: yes trusted-keys-file: /etc/unbound/keys.d/*.key auto-trust-anchor-file: "/var/lib/unbound/root.key" val-clean-additional: yes val-permissive-mode: no val-log-level: 1 include: /etc/unbound/local.d/*.conf ipsecmod-enabled: no ipsecmod-hook: "/usr/libexec/ipsec/_unbound-hook" python: 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" include: /etc/unbound/conf.d/*.conf
Nachfolgende Änderungen wurden beispielhaft vorgenommen:
interface: 192.168.0.20 interface: 192.168.1.20
Interface, auf denen der unbound Anfragen entgegen nimmt.
outgoing-interface: 192.168.1.20
Interface, auf denen der unbound Anfragen weiterleitet/bzw. stellt nimmt (Hier der Root-Server-(Liste).
HINWEIS - Es kann auch ein Interface sein, auf dem der unbound gar nicht lauscht!
do-ip6: no
Deaktivieren von IPv6.
access-control: 127.0.0.0/8 allow_snoop access-control: 192.168.0.0/24 allow access-control: 192.168.1.0/24 allow access-control: 192.168.2.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
allow_snoopdig
ebenfalls ausführen soll, kann unbound so konfiguriert werden, dass dieser iterative (nicht rekursive) Abfragen ermöglicht. Dies geschieht durch die Verwendung der Option , anstelle von
access-control:allow
in der 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!
* <code ini> root-hints: „/etc/unbound/root.hints“</code>
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.
* <code ini> hide-identity: yes</code>
Anfragen von
127.0.0.1id.server
und hostname.bind
sollen nicht beantwortet werden.
* <code ini> hide-version: yes</code>
Anfragen von version.server
und version.bind
sollen nicht beantwortet werden.
* <code ini> do-not-query-localhost: no</code>
Erlaube Verbindungen auch zu localhost
.
HINWEIS - Diese Einstellung ist entscheiden, wenn der dahinter liegende DNS-Server z.B. nur auf lauscht !!!
* <code> trusted-keys-file: /etc/unbound/keys.d/*.key
auto-trust-anchor-file: „/var/lib/unbound/root.key“
# Tachtler
auto-trust-anchor-file: „/etc/unbound/keys.d/Ktachtler.net.+010+41592.key“
auto-trust-anchor-file: „/etc/unbound/keys.d/K171.217.88.in-addr.arpa.+010+05364“</code>
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!
* <code> domain-insecure: „localhost“
domain-insecure: „1.0.0.127.in-addr.arpa.“</code>
Damit auch eine forward Anfrage nach
reverselocalhost
und eine Anfrage nach
local-zome127.0.0.1
erfolgreich beantwortet werden können, ist es erforderlich diese von den DNSSec gesicherten Zonen auszunehmen.
* <code ini> # 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.</code>
Damit auch eine reverse Anfrage zum erfolgt führt, ist die Definition der 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
<code>
# dig -x 10.7.0.10
; «» DiG 9.9.4-RedHat-9.9.4-61.el7_5.1 «» -x 192.168.0.10
;; global options: +cmd
;; Got answer:
;; →>HEADER«- opcode: QUERY, status: NXDOMAIN, id: 18038
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;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: 1 msec
;; SERVER: 192.168.0.20#53(192.168.0.20)
;; WHEN: Wed Sep 05 07:33:57 CEST 2018
;; MSG SIZE rcvd: 110
</code>
* <code ini>forward-zone:
name: „tachtler.net“
forward-addr: 127.0.0.1
forward-zone:
name: „2.168.192.in-addr.arpa“
forward-addr: 127.0.0.1
forward-zone:
name: „1.168.192.in-addr.arpa“
forward-addr: 127.0.0.1
forward-zone:
name: „0.168.192.in-addr.arpa“
forward-addr: 127.0.0.1</code>
Interne Anfragen sollen an den DNS-Server, welcher auf der IP-Adresse
unbound-keygen127.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:
* DNS ISC bind CentOS 7
Die Konfigurationsdatei /etc/unbound/unbound.conf
ohne Kommentar- und Leerzeichen inklusive der Änderungen:
<code ini>
# egrep -v '(^#|^.*#|^$)' /etc/unbound/unbound.conf
server:
verbosity: 1
statistics-interval: 0
statistics-cumulative: no
extended-statistics: yes
num-threads: 4
interface: 192.168.0.20
interface: 192.168.1.20
interface-automatic: no
outgoing-interface: 192.168.1.20
so-reuseport: yes
ip-transparent: yes
do-ip6: no
access-control: 127.0.0.1/8 allow
access-control: 192.168.0.0/24 allow
access-control: 192.168.1.0/24 allow
access-control: 192.168.2.0/24 allow
access-control: 88.217.171.167/32 allow
chroot: „“
username: „unbound“
directory: „/etc/unbound“
log-time-ascii: yes
pidfile: „/var/run/unbound/unbound.pid“
root-hints: „/etc/unbound/root.hints“
hide-identity: yes
hide-version: yes
do-not-query-localhost: no
harden-glue: yes
harden-dnssec-stripped: yes
harden-below-nxdomain: yes
harden-referral-path: yes
unwanted-reply-threshold: 10000000
prefetch: yes
prefetch-key: yes
rrset-roundrobin: yes
minimal-responses: yes
module-config: „ipsecmod validator iterator“
trust-anchor-signaling: yes
trusted-keys-file: /etc/unbound/keys.d/*.key
auto-trust-anchor-file: „/var/lib/unbound/root.key“
auto-trust-anchor-file: „/etc/unbound/keys.d/Ktachtler.net.+010+41592.key“
auto-trust-anchor-file: „/etc/unbound/keys.d/K171.217.88.in-addr.arpa.+010+05364“
domain-insecure: „localhost“
domain-insecure: „1.0.0.127.in-addr.arpa.“
local-zone: „localhost.“ nodefault
local-zone: „127.in-addr.arpa.“ nodefault
local-zone: „168.192.in-addr.arpa.“ nodefault
local-zone: „0.in-addr.arpa.“ nodefault
val-clean-additional: yes
val-permissive-mode: no
val-log-level: 1
include: /etc/unbound/local.d/*.conf
ipsecmod-enabled: no
ipsecmod-hook: „/usr/libexec/ipsec/_unbound-hook“
python:
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“
include: /etc/unbound/conf.d/*.conf
forward-zone:
name: „tachtler.net“
forward-addr: 127.0.0.1
forward-zone:
name: „2.168.192.in-addr.arpa“
forward-addr: 127.0.0.1
forward-zone:
name: „1.168.192.in-addr.arpa“
forward-addr: 127.0.0.1
forward-zone:
name: „0.168.192.in-addr.arpa“
forward-addr: 127.0.0.1
</code>
==== 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:
<code>
# /usr/sbin/unbound-checkconf /etc/unbound/unbound.conf
</code>
Nachfolgende Ausführung des Befehls, direkt nach der Installation, zur Überprüfung der Konfigurationsdatei /etc/unbound/unbound.conf
, wird nachfolgende Fehlermeldung ausgeben
<code>
# /usr/sbin/unbound-checkconf /etc/unbound/unbound.conf
/etc/unbound/unbound_server.key: No such file or directory
[1535999132] unbound-checkconf[31881:0] fatal error: server-key-file: „/etc/unbound/unbound_server.key“ does not exist
</code>
HINWEIS - Dies ist ganz normal, da beim ersten Start des Dienstes/Daemon auch der Service mit gestartet wird und dieses Problem dann löst !!!
Siehe auch nachfolgenden externen Link:
* Failed unbound-checkconf when unbound hasn't been started yet
Nachfolgende das
systemd-Start-Skript:
<code ini>
[Unit]
Description=Unbound recursive Domain Name Server
After=syslog.target network.target
After=unbound-keygen.service
Wants=unbound-keygen.service
Wants=unbound-anchor.timer
Before=nss-lookup.target
Wants=nss-lookup.target
[Service]
Type=simple
EnvironmentFile=-/etc/sysconfig/unbound
ExecStartPre=/usr/sbin/unbound-checkconf
ExecStartPre=-/usr/sbin/unbound-anchor -a /var/lib/unbound/root.key -c /etc/unbound/icannbundle.pem
ExecStart=/usr/sbin/unbound -d $UNBOUND_OPTIONS
[Install]
WantedBy=multi-user.target
</code>
===== 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:
<code>
# systemctl start unbound.service
</code>
Mit nachfolgendem Befehl kann überprüft werden, ob der erste Start erfolgreich durchgeführt wurde:
<code>
# systemctl status unbound.service
● unbound.service - Unbound recursive Domain Name Server
Loaded: loaded (/usr/lib/systemd/system/unbound.service; enabled; vendor preset: disabled)
Active: active (running) since Mon 2018-09-03 21:43:39 CEST; 5s ago
Process: 16259 ExecStartPre=/usr/sbin/unbound-anchor -a /var/lib/unbound/root.key -c /etc/unbound/icannbundle.pem (code=exited, status=0/SUCCESS)
Process: 16258 ExecStartPre=/usr/sbin/unbound-checkconf (code=exited, status=0/SUCCESS)
Main PID: 16267 (unbound)
CGroup: /system.slice/unbound.service
└─16267 /usr/sbin/unbound -d
Sep 03 21:43:39 vml70020.idmz.tachtler.net systemd[1]: Starting Unbound recur…
Sep 03 21:43:39 vml70020.idmz.tachtler.net unbound-checkconf[16258]: unbound-…
Sep 03 21:43:39 vml70020.idmz.tachtler.net systemd[1]: Started Unbound recurs…
Sep 03 21:43:39 vml70020.idmz.tachtler.net unbound[16267]: [16267:0] notice: …
Sep 03 21:43:39 vml70020.idmz.tachtler.net unbound[16267]: [16267:0] notice: …
Sep 03 21:43:39 vml70020.idmz.tachtler.net unbound[16267]: [16267:0] notice: …
Sep 03 21:43:39 vml70020.idmz.tachtler.net unbound[16267]: [16267:0] info: st…
Hint: Some lines were ellipsized, use -l to show in full.
</code>
===== Überprüfung =====
Ziel ist es eine lokale Antwort –>
*
tachtler.net IN A 192.168.0.90
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)
<code>
# dig @127.0.0.2 tachtler.net +dnssec +multi
; «» DiG 9.9.4-RedHat-9.9.4-61.el7_5.1 «» @192.168.0.20 tachtler.net +dnssec +multi
; (1 server found)
;; global options: +cmd
;; Got answer:
;; →>HEADER«- opcode: QUERY, status: NOERROR, id: 33980
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;tachtler.net. IN A
;; ANSWER SECTION:
tachtler.net. 10777 IN A 192.168.0.90
tachtler.net. 10777 IN RRSIG A 10 2 10800 (
20181002054109 20180902050808 13937 tachtler.net.
tI018q4i7QVSIirCjMwFfAH9C2nVHBrz6WuM7VZFv7hF
yLRM4a0m6siKLxtYGBX1IAqS4BjRJqWyskgejdkogr9y
T6iMLrRNGLh2PcZH2auApuK7QKqtMb4U2iCeJ/TsEH6g
gW848ljS6Zz9EaVFBlyxyYm3BSXBIJpHFKRN1msh7L0F
NPe3gwXkwoj1X/QP7R6/lF52G4MA6GwAhX2yWmM3ofVh
4zIQKEZ211k148Txy6pnifyOZeNEhKrp/Rajg4HkZ/Ob
F+Betj/Dpsu4yhEG79tRZ5xZh8rDbtlpP9Rcc6UDIgf8
RbDxdRARtlOGoe8GuG4ga7s19w1VdT8ayw== )
;; Query time: 0 msec
;; SERVER: 192.168.0.20#53(192.168.0.20)
;; WHEN: Tue Sep 04 08:34:44 CEST 2018
;; MSG SIZE rcvd: 357
</code>
HINWEIS - Nachfolgend muss das
ad-Flag in der Antwort enthalten sein, siehe nachfolgende Zeile:
*
;; flags: qr rd ra
ad
; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1