Meine Server verfügen seit ein paar Wochen über lokale, nur vom DNS Root abhängige DNS-Resolver, die auch DNSSEC beherrschen. Der Vorteil: DNS-Ergebnisse lassen sich lokal cachen und man muss weniger auf externe Infrastruktur vertrauen. Das verbessert Datenschutz und Sicherheit. Die DNS-Anfragen werden direkt an einen der DNS-Rootserver gestellt und von dort aus aufgelöst. Der kleine DNS-Resolver „Unbound“ ist perfekt als lokaler Resolver geeignet und mit wenigen Kommandos einsatzbereit:
apt install unbound
Eigentlich könnte die Anleitung an dieser Stelle schon fast zu Ende sein, denn nach der Installation horcht der Resolver lokal bereits auf Port 53 und beherrscht auch schon DNSSEC. Trotzdem sind wir noch nicht fertig, denn der Resolver bekommt jetzt noch eine aktualisierte Version des DNSSEC Root Trust Anchors:
unbound-anchor
… speichert neuen key in /etc/unbound/root.key
Die Datei /etc/unbound/unbound.conf.d/root-auto-trust-anchor-file.conf solltet ihr so anpassen:
server:
auto-trust-anchor-file: "/etc/unbound/root.key" (Hinweis zu Ubuntu 16.04: Bevor Unbound gestartet wird, muss noch ein kleiner Bug behoben werden: Unbound muss Zugriff auf sein Konfigurationsverzeichnis haben: chown unbound /etc/unbound/)
Unbound ist fertig eingerichtet und kann gestartet werden:
service unbound start
Damit der DNS-Server vom System genutzt wird, muss je nach Linux-Distribution die Netzwerkkonfiguration angepasst werden, sodass Unbound als DNS-Resolver genutzt wird. In meiner Konfiguration (/etc/network/interfaces) sieht das so aus:
auto lo iface lo inet loopback auto eth0 iface eth0 inet static address 5.1.76.155 netmask 255.255.255.0 gateway 5.1.76.1 dns-nameservers 127.0.0.1 8.8.8.8 8.8.4.4 iface eth0 inet6 static address 2a00:f820:417::be19:7b23 netmask 64 gateway 2a00:f820:417::1 dns-nameservers ::1 2001:4860:4860::8888 2001:4860:4860::8844
Ich habe euch blau markiert, wo ich eine Anpassung gemacht habe. In meinem Beispiel wird zuerst versucht, Unbound zu nutzen (steht an erster Stelle) – und wenn das nicht funktioniert, wird das Google DNS befragt. Neu einem Neustart wird die aktualisierte Netzwerkkonfiguration genutzt.
Wenn ihr wissen wollt, welchen Performance-Vorteil der lokale DNS-Cache bringen kann, führt zweimal hintereinander eine DNS-Anfrage aus:
dig thomas-leister.de | grep "Query time"
(evtl. Paket „dnsutils“ für „dig“-Kommando nach installieren). Die Query Time sollte beim zweiten Mal 0-1 ms betragen, während sie bei der ersten Anfrage deutlich höher liegt.
Hi
interessanter Artikel. Sehe ich das richtig, dass jeder Server und jeder PC in Deinem Netzwerk einen eigenen DNS-Cache hat?
Wäre es da nicht sinnvoller einen zentralen Rechner (evtl. den DHCP / Gateway – Server) mit dem DNS-Cache zu versehen und die DHCP-Einstellungen entsprechend DNS anzupassen (evtl. anstatt 127.0.0.1 / 192.168.1.1)?
https://legacy.thomas-leister.de/ueber-mich-und-blog/
Hi,
nur die Server verfügen bisher über einen eigenen Unbound-Server. Braucht kaum Ressourcen und ist maximal zuverlässig und sicher. Mit mehreren Servern oder PCs im Netzwerk würde mann dann vllt eher einen zentralen DNS Cache nehmen und den via DHCP bekannt machen. Bei meinen Servern verzichte ich bisher darauf, weil die Server in einem RZ stehen, dessen Netzwerk ich nicht uneingeschränkt vertrauen kann. In dem Fall ist es besser, wenn jeder Server seinen eigenen Cache hat.
LG Thomas
https://quarkdose.de
Danke für den Artikel… Wird gleich mal bei mir eingerichtet :)
Aber noch ein kleiner Hinweis: Es muss Ubuntu 16.04 und nicht Ubuntu 16.06 heißen.
https://legacy.thomas-leister.de/ueber-mich-und-blog/
:-) Jepp, da hatte ich letztens irgendwo einen Knoten im Kopf und habe überall 16.06 statt 16.04 geschrieben. Ich hoffe, das ist die letzte Stelle, die korrigiert werden muss ;-)
LG Thomas
Hast du unter 16.04 noch weitere Probleme? Z.B. mit dem Autostart von Unbound?
Unbound funktioniert wie erwartet, und mittels „systemctl enable“ sollte er eigentlich auch automatisch nach einem Neustart starten, aber irgendwie schafft er es nicht und läuft nach ca 5min in einen Timeout:
May 3 12:45:58 mail systemd[1]: Starting unbound.service…
May 3 12:45:58 mail unbound[1036]: * Starting DNS server unbound
May 3 12:50:58 mail systemd[1]: unbound.service: Start operation timed out. Terminating.
May 3 12:50:58 mail systemd[1]: Failed to start unbound.service.
May 3 12:50:58 mail systemd[1]: unbound.service: Unit entered failed state.
May 3 12:50:58 mail systemd[1]: unbound.service: Failed with result ‚timeout‘.
May 3 12:55:01 mail unbound-anchor: /var/lib/unbound/root.key has content
May 3 12:55:01 mail unbound-anchor: success: the anchor is ok
Wenn ich den Service dann mittel „systemctl start unbound“ manuell starte, dann klappt alles:
May 3 12:58:32 mail systemd[1]: Starting unbound.service…
May 3 12:58:32 mail unbound[1268]: * Starting DNS server unbound
May 3 12:58:34 mail unbound-anchor: /var/lib/unbound/root.key has content
May 3 12:58:34 mail unbound-anchor: success: the anchor is ok
May 3 12:58:34 mail unbound: [1284:0] notice: init module 0: validator
May 3 12:58:34 mail unbound: [1284:0] notice: init module 1: iterator
May 3 12:58:34 mail unbound: [1284:0] info: start of service (unbound 1.5.8).
May 3 12:58:34 mail unbound[1268]: …done.
May 3 12:58:34 mail systemd[1]: Started unbound.service.
Das problem scheint zu sein, dass das Networkinterface nicht schnell genug verfügbar ist und dann Unbound nicht weiter weiß.
Bei einem ähnlichen Problem wurde wohl empfohlen falls der NetworkManager verwendet würde den Service „systemctl enable NetworkManager-wait-online.service“ zu aktivieren, da es bei mir allerdings nur „systemd-networkd-wait-online.service“ hab ich es damit versucht, scheint aber auch nicht zu gehen.
Als Alternative bleibt wohl ein Skript in /etc/rc.d
Hast du da noch Ideen, bzw wie hast du den Autostart geregelt, falls überhaupt
https://legacy.thomas-leister.de/ueber-mich-und-blog/
Hi,
nach der Installation habe ich _kein_
systemctl enable unboundausgeführt; trotzdem startet unbound automatisch mit und funktioniert danach direkt. Also nein, ich habe keine Probleme damit unter 16.04.LG Thomas
Hallöle,
Du hast ja im Post bzgl. Postfix und Spamhaus [1] geschrieben, das der/die Google-DNS die Domain(s) von Spamhaus nicht auflöst und auf unbound verwiesen.
Allerdings weiss ja unbound vorerst genausowenig über (bspw.) zen.spamhaus.org und stellt die Anfrage an den Google-DNS, der den A-Eintrag ebensowenig kennt/kennen will.
Somit hilft doch unbound auch nicht dabei, diese Domain aufzulösen.
Oder hab ich da etwas falsch verstanden?
https://legacy.thomas-leister.de/ueber-mich-und-blog/
Das hast du falsch verstanden ;-)
unbound befragt nicht das Google-DNS, sondern direkt die DNS-Rootserver (Und dann kaskadierend die jeweiligen Nameserver der Domain und Subdomain). Dein Unbound ersetzt die Google-Resolver (die du vllt vorher verwendet hast) vollständig. Unbound ist also nicht nur Cache, sondern vollwertiger Resolver.
LG Thomas
Ok. Danke für die Aufklärung.
Scheinbar hab ich mich dann irgendwie zu glatt angestellt.
Denn nachdem ich unbound installierte und die 127.0.0.1 an erster Stelle meiner resolv.conf eintrug, konnte zen.spamhaus.org noch immer nicht aufgelöst werden. (unknown host)
An zweiter und dritter Stelle standen die beiden Google-DNS 8.8.8.8 und 8.8.4.4
Moin Thomas,
nach einigen Recherchen und Tricksereien mit Unbound ist mir aufgefallen, dass es wohl Probleme mit IPv6 und Ubuntu 16.04 gibt. Ob dieses Problem auch mit anderen Distributionen auftritt, weiß ich nicht :)
Zumindest muss in Unbound IPv6 deaktiviert werden. Ich habe dazu folgende Konfiguration genutzt:
server:
auto-trust-anchor-file: „/etc/unbound/root.key“
interface-automatic: yes
port: 53
do-ip4: yes
do-ip6: no
do-tcp: yes
do-udp: yes
do-daemonize: yes
username: „unbound“
use-syslog: yes
access-control: 127.0.0.1/24 allow
access-control: 0.0.0.0/0 deny
local-zone: „domain.de.“ transparent
local-data: „www.de.de. 3600 IN A 127.0.0.1“
forward-zone:
name: „.“
forward-addr: 8.8.8.8
Mit dieser Konfiguration hat es dann auch bei mir geklappt :)
Viele Grüße,
Lukas
forward-addr: 8.8.4.4
https://www.alenan.org
Hey Thomas,
hast du nen Tipp um einen DNS Resolver öffentlich zu betreiben, also das alle Ihn ohne logging benutzen können?
-Maxi
Hallo Thomas,
danke für den Artikel. Auf eine Unschönheit möchte ich aufmerksam machen. Unbound wird bereits im kürzlich erschienenen Ubunutu 16.04 schon nicht mehr gewartet. Das zeigt der ubuntu-support-status. D.h. Unbound erhält automatisch keine Sicherheitsupdates, was ich bei einem Resolver als bedenkenswert einstufe. Vielleicht gibt es eine bessere und genauso schlanke Alternative?
https://legacy.thomas-leister.de/ueber-mich-und-blog/
Hi, das habe ich nicht gewusst. Danke für den Hinweis. Ist tatsächlich keine schöne Sache… spontan kann ich dir keine Alternative empfehlen. Muss mich selbst erst einmal umsehen.
LG Thomas
ubuntu-support-status ist bei 16.04 nicht mehr zuverlässig, siehe https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/1574670
das muss apt-get unbound heißen ;)
https://legacy.thomas-leister.de/ueber-mich-und-blog/
Nein, die Kurzform funktioniert mindestens genauso gut ;-)
Hallo Thomas,
nice article.
Wie soll die Netzwerke Konfigurationen bei „Virtual Server“ aussehen? Bei mir sieht so aus:
auto lo
iface lo inet loopback
…
auto venet0:0
iface venet0:0 inet static
address xx.xxx.xx.xx
netmask 255.255.255.255
auto venet0:3
iface venet0:3 inet static
address xx.xxx.xx.xx
netmask 255.255.255.255
https://legacy.thomas-leister.de/ueber-mich-und-blog/
Hallo Gelin,
das hängt von deinem Server-Hoster ab. Du musst deine Konfiguration so anpassen, dass der interne DNS-Resolver genutzt wird. Dazu fügst du einfach folgende Zeile hinzu (oder änderst sie):
dns-nameservers 127.0.0.1 8.8.8.8 8.8.4.4LG Thomas
In welcher datei wenn ich fragen darf
https://legacy.thomas-leister.de/ueber-mich-und-blog/
In /etc/network/interfaces
Wie kann ich das umändern?
Damit der DNS-Server vom System genutzt wird, muss je nach Linux-Distribution die Netzwerkkonfiguration angepasst werden, sodass Unbound als DNS-Resolver genutzt wird. In meiner Konfiguration sieht das so aus:
Ich möchte mich auch erkundigen in welcher datei muss ich das ändern?
Ich glaube in /etc/network/interfaces aber das soll Thomas nochmal absegnen.
PS: Bei mir sieht das falsch aus.
auto lo
iface lo inet loopback
# Auto generated venet0 interface
auto venet0
iface venet0 inet manual
up ifconfig venet0 up
up ifconfig venet0 127.0.0.2
up route add default dev venet0
down route del default dev venet0
down ifconfig venet0 down
iface venet0 inet6 manual
up ifconfig venet0 add MEINE IPv6 HIER/64
down ifconfig venet0 del MEINE IPv6 HIER/64
up route -A inet6 add default dev venet0
down route -A inet6 del default dev venet0
auto venet0:0
iface venet0:0 inet static
address MEINE IPv4 HIER
netmask 255.255.255.255
Statt /etc/network/interfaces habe ich die Zeile
nameserver 127.0.0.1
in die Datei
/etc/resolvconf/resolv.conf.d/tail
eingefügt.
Das scheint auch zu funktionieren:
dig thomas-leister.de | grep „Query time“
;; Query time: 335 msec
dig thomas-leister.de | grep „Query time“
;; Query time: 0 msec
Hi Thomas,
vielen Dank für diesen Artikel. Da dig oftmals nicht bei den Minimalinstallationen dabei ist, wäre es vielleicht noch einmal sinnvoll zu erwähnen, wie und von wo dig (enthalten in dnsutils) bezogen werden kann. Das wäre nur ein Vorschlag meinerseits. :)
Beste Grüße
— Florian
https://legacy.thomas-leister.de/ueber-mich-und-blog/
Danke für den Hinweis! Habe es ergänzt. LG Thomas
https://www.marcush.de
1. Also Nameserver werden seit meiner ersten Slackware vor über 20 Jahren und der aktuellen Ubuntu 16.04 immer noch in der */etc/resolv.conf* eingetragen! Diese sind immer vor allen Network-Interfaces dort einzutragen! Falls bei Ubuntu du die interfaces nutzt, wo man nicht begehen soll, muss resolvconf installiert werden.
2. Ein lokaler DNS-Server auf einem relativ langsamen, gemieteten Server, kommt niemals an die Performance der Nameserver deines Hosters oder der hiesigen Server-Farmen von Google und Co. heran! Nie und nimmer.
3. Wenn du zweimal hintereinander in kurzem Abstand eine Domain über einen Nameserver auflöst… tara! Schlägt der Cache an, und sagt: Hey, die IP hatten wir gerade, bitte schön! Wie in deinem Browser, der hat auch internen eine DNS-Cache…
Beispiel (kalt nicht im DNS-Cache) mit unbound lokal:
dig linux.org
; <> DiG 9.10.3-P4-Ubuntu <> linux.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60949
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;linux.org. IN A
;; ANSWER SECTION:
linux.org. 3600 IN A 104.225.135.13
;; Query time: 307 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Sep 19 18:21:49 CEST 2016
;; MSG SIZE dcvd: 54
Eierlangsam… nicht der Rede wert. Absolute Bremse.
Jetzt mit dem DNS-Servers des Webshosters, hier STRATO (kalt nicht im DNS-Cache):
dig enlightenment.org
; <> DiG 9.10.3-P4-Ubuntu <> enlightenment.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15320
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;enlightenment.org. IN A
;; ANSWER SECTION:
enlightenment.org. 3600 IN A 140.211.167.135
;; Query time: 32 msec
;; SERVER: 85.214.XXX.XXX#53(85.214.XXX.XXX)
;; WHEN: Mon Sep 19 18:27:18 CEST 2016
;; MSG SIZE rcvd: 51
Das ist eine vernünftige Antwortzeit: 32ms sind ok.
Jetzt noch einmal sofort dieselbe Auflösung:
dig enlightenment.org
; <> DiG 9.10.3-P4-Ubuntu <> enlightenment.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61785
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;enlightenment.org. IN A
;; ANSWER SECTION:
enlightenment.org. 3490 IN A 140.211.167.135
;; Query time: 0 msec
;; SERVER: 85.214.XXX.XXX#53(85.214.XXX.XXX)
;; WHEN: Mon Sep 19 18:29:08 CEST 2016
;; MSG SIZE rcvd: 51
Also: apt-get –purge remove unbound
Auf einem frisch aufgesetzten Ubuntu 16.04 startet bei mir unbound mit der beschriebenen Methode nicht automatisch beim Systemstart, daher habe ich mich auf die Suche begeben und herausgefunden, dass man den Passus
service unbound start
folgendermaßen ändern kann…
Zunächst erstellt man eine Datei /etc/default/unbound mit folgendem Inhalt:
DAEMON_OPTS=“-c /etc/unbound/unbound.conf“
Danach bindet man unbound in den Systemstart mittels
systemctl enable unbound
ein und startet dann unbound mittels
systemctl start unbound
Danach sollte auch nach jedem Systemneustart (und nicht nur in der aktuellen Session) der Aufruf
dig +dnssec A http://www.dnssec.cz | grep ad
ein Ergebnis geben.