Der Adblocker Pi-Hole ist in der IT-Szene bereits seit einigen Jahren bekannt. Nun erobert er auch zunehmend den Consumer-Markt. Eine perfekte Ergänzung dazu ist unbound. Als DNS-Resolver übernimmt unbound künftig alle DNS-Anfragen im Netz und leitet sie an die Root-DNS-Server des Internets weiter. Damit entfallen Dienste wie Quad9 oder DNS0.eu, die teilweise bereits im Blog vorgestellt wurden. Neben einer deutlichen Beschleunigung der DNS-Abfragen hat man auch den Vorteil, dass mögliche Netzsperren kein Thema mehr sind.
Diese Hardware braucht es
Um Pi-Hole und unbound zu nutzen, braucht man natürlich nicht, wie in meinem Fall, gleich einen eigenen Homeserver mit VMware oder einer anderen Virtualisierungslösung. Auch auf einem Raspberry Pi läuft die Kombination der beiden Dienste sehr gut. Neben diesen beiden Möglichkeiten kommt natürlich auch ein NAS infrage, vorausgesetzt es unterstützt VMs. Die Anbindung über LAN an den jeweiligen Router wird jedoch für alle Anwendungsszenarien empfohlen.
Pi-Hole installieren
Als Basis für die Erstellung der Anleitung wurde eine VMware VM mit einem Ubuntu Server in der Version 22.0.4.1 LTS verwendet. Die Anleitung kann im Folgenden abweichen, wenn eine andere Linux-Version verwendet wird. Auch eine Installation über einen Docker-Container ist möglich. Auf diese Möglichkeit gehe ich hier jedoch nicht ein.
Ein einziger Befehl reicht aus, um Pi-Hole zu installieren. Unter Umständen muss jedoch vorher das Paket curl über sudo apt install curl
installiert werden. Die Installation des Pakets erfolgt komfortabel per Skript direkt aus GitHub über curl -sSL https://install.pi-hole.net | bash
.
Während der Installation erfolgt u. a. die Abfrage des Upstream-DNS-Servers. Hier wird ein beliebiger Anbieter aus der Liste ausgewählt. Dieser wird einfach ersetzt, nachdem unbound installiert und konfiguriert wurde. Des Weiteren wird nach der Installation des Web UI gefragt, was besonders für Einsteiger von Vorteil ist. Hat man den kompletten Wizard durchlaufen, beginnt bereits Pi-Hole zu installieren. Nach deren Abschluss wird der Startbildschirm mit der IPv4- und IPv6-Adresse sowie dem Passwort zum Einloggen in Pi-Hole angezeigt.
Wer das Passwort ändern oder ganz löschen möchte, wovon ich abrate, kann dies schnell und einfach mit dem Kommando sudo pihole -a -p
erledigen. Damit ist Pi-Hole auch schon installiert. Mit unbound geht es weiter.
unbound installieren
Mit sudo apt install unbound
und der anschließenden Bestätigung, die ausgewählten Pakete wirklich installieren zu wollen, wird unbound installiert. Danach muss nur noch kurz gewartet werden. Dann ist der Dienst mit den benötigten Abhängigkeiten installiert. Auch wenn die root.hints über die Abhängigkeiten vom Paketinstaller automatisch mitinstalliert werden sollten, empfiehlt es sich, die root.hints über den folgenden Befehl herunterzuladen:
wget https://www.internic.net/domain/named.root -qO-| sudo tee /var/lib/unbound/root.hints
Der Download ist abgeschlossen. Nun muss unbound noch konfiguriert werden. Dazu wird die Konfigurationsdatei in einem Editor geöffnet, in meinem Fall nano.
sudo nano /etc/unbound/unbound.conf.d/pi-hole.conf
Der folgende Inhalt wird in die Konfigurationsdatei eingetragen. Falls keine IPv6-Adresse am lokalen Internetanschluss zur Verfügung steht, muss die entsprechende Zeile natürlich angepasst werden.
server: # If no logfile is specified, syslog is used # logfile: „/var/log/unbound/unbound.log“ verbosity: 0 interface: 127.0.0.1 port: 5335 do-ip4: yes do-udp: yes do-tcp: yes # May be set to yes if you have IPv6 connectivity do-ip6: yes # You want to leave this to no unless you have *native* IPv6. With 6to4 and # Terredo tunnels your web browser should favor IPv4 for the same reasons prefer-ip6: no # Use this only when you downloaded the list of primary root servers! # If you use the default dns-root-data package, unbound will find it automatically #root-hints: „/var/lib/unbound/root.hints“ # Trust glue only if it is within the server’s authority harden-glue: yes # Require DNSSEC data for trust-anchored zones, if such data is absent, the zone becomes BOGUS harden-dnssec-stripped: yes # Don’t use Capitalization randomization as it known to cause DNSSEC issues sometimes # see https://discourse.pi-hole.net/t/unbound-stubby-or-dnscrypt-proxy/9378 for further details use-caps-for-id: no # Reduce EDNS reassembly buffer size. # IP fragmentation is unreliable on the Internet today, and can cause # transmission failures when large DNS messages are sent via UDP. Even # when fragmentation does work, it may not be secure; it is theoretically # possible to spoof parts of a fragmented DNS message, without easy # detection at the receiving end. Recently, there was an excellent study # >>> Defragmenting DNS – Determining the optimal maximum UDP response size for DNS <<< # by Axel Koolhaas, and Tjeerd Slokker (https://indico.dns-oarc.net/event/36/contributions/776/) # in collaboration with NLnet Labs explored DNS using real world data from the # the RIPE Atlas probes and the researchers suggested different values for # IPv4 and IPv6 and in different scenarios. They advise that servers should # be configured to limit DNS messages sent over UDP to a size that will not # trigger fragmentation on typical network links. DNS servers can switch # from UDP to TCP when a DNS response is too big to fit in this limited # buffer size. This value has also been suggested in DNS Flag Day 2020. edns-buffer-size: 1232
Nach dem Einfügen und Speichern des Inhalts der Konfigurationsdatei muss der unbound-Dienst mit dem folgenden Befehl neu gestartet werden.
sudo service unbound restart
Ob unbound funktioniert, kann mit folgendem Befehl getestet werden.
dig pi-hole.net @127.0.0.1 -p 5335
Bei der ersten Anfrage wurde die URL, die im Beispiel verwendet wurde, innerhalb von 144 ms gefunden. Die Zeit, in der unbound nun die Ziel-Adresse kennt, beträgt bei einem zweiten Aufruf 0 ms. In Zukunft müssen die Zieladressen erst beim ersten Mal abgerufen werden. Das Öffnen einer Webseite oder App dauert daher länger. In Zukunft wird das Abrufen der Adressen jedoch nahezu in Echtzeit erfolgen.
Pi-Hole und unbound miteinander verbinden
Für die Verbindung von Pi-Hole mit unbound ist nun der Aufruf des Web-UI über die im Vorfeld bekannte IP-Adresse bzw. den Hostnamen erforderlich. Mit dem vergebenen Passwort loggt man sich ein. Unter dem Punkt Settings ruft man die DNS-Einstellungen auf. Auf der linken Seite werden unter Upstream DNS-Servers alle Häkchen entfernt. Im rechten Feld wird unter Custom 1 (IPv4) 127.0.0.1#5335
eingetragen. Zusätzlich muss unter Custom 3 (IPv6) die lokale IPv6-Adresse ::1#5335
eingetragen werden, sofern man unbound für die Verwendung mit IPv6 konfiguriert hat. Anschließend wird noch DNSSEC aktiviert und die Einstellungen gespeichert. Schon ist die Verbindung zwischen den beiden Diensten hergestellt.
Automatische root.hints-Updates
Es empfiehlt sich nun, ein Update-Skript zu erstellen, damit unbound auch nach zukünftigen Updates von root.hints zuverlässig funktioniert. Dieses kann in einem beliebigen Ordner liegen.
#!/bin/bash wget -O root.hints https://www.internic.net/domain/named.root && ( mv -fv root.hints /var/lib/unbound/ service unbound restart )
Das erstellte Skript wird nun ausführbar gemacht. Je nachdem, wie das Skript benannt wurde, muss dazu das Befehl angepasst werden.
sudo chmod +x update_unbound_dns.sh
Zum automatischen Ausführen des Updater-Skripts ist nun ein Cron-Job erforderlich. Im Crontab ist hierbei unter Umständen eine Anpassung des Scriptpfades erforderlich.
sudo nano /etc/crontab
* * * */3 * root /home/user/update_unbound_dns.sh >/dev/null 2>&1
In der hier gezeigten Einstellung werden die root.hints nun automatisch alle drei Monate durch den Cronjob auf den neuesten Stand gebracht, sodass es keine Probleme mit unbound geben sollte.
DNS-Server im Router ändern
Damit Pi-Hole und unbound nun im gesamten Netzwerk funktionieren, muss nun noch der DNS-Server im eigenen Router geändert werden. Im Fall der FRITZ!Box ist dieser Punkt unter Internet – DNS-Server zu finden. Die Adressen des Pi-Hole Hosts müssen dort nun unter IPv4 und IPv6 eingetragen werden.
Anschließend müssen die Einstellungen noch gespeichert werden und schon funktioniert der Dienst. Die DNS-Anfragen, die von den eigenen Geräten gestellt werden, sollten nun auch über die Weboberfläche von Pi-Hole erscheinen. Über die Web-Benutzeroberfläche können weitere Filterlisten hinzugefügt und bestehende Listen aktualisiert werden. Für Eltern mit minderjährigen Kindern werden zudem entsprechende Listen im Netz angeboten, die für Minderjährige ungeeignete Inhalte blockieren. Außerdem können über das Web-UI Seiten auf eine Whitelist gesetzt oder ganze Dienste wie zum Beispiel TikTok komplett gesperrt werden.
Danke für die tolle Anleitung.
Wenn ich mal wieder etwas mehr Zeit habe, werde ich es gerne mal ausprobieren.
Sehr cool. Das mit dem unbound kannte ich noch gar nicht. Hatte vor ein paar Tagen erst das Problem, dass mein DNS fur IPv6 nicht zur Verfügung stand. Werde das auf jeden Fall mal testen.
Anmerkung: im Artikel haben sich bei den Terminalbefehlen ein paar HTML-Tags eingeschlichen. Glaube die müssten entfernt werden (gesehen mit der Deskmodder App)
gepostet mit der Deskmodder.de-App für Android
Danke für den Tipp. Sollten alle raus sein.
Mir würde es reichen wenn PI hole nativ verschlüsseltes DNS unterstützen würde aber das wird wohl nie passieren. 🤷🏻♂️
Dann nutze doch AdGuard Home (auch mit Unbound).
Nö nutze es normal weiter, wäre halt nur nice to have.
Tut es doch verschlüsselt, wenn man weiss wie man sich eine Kette aus Resolvern selbst aufbaut. Liest man sich mal geschlagene 2 Minuten ein, wie man unbound mit DNScrypt verknüpft. Außerdem ist verschlüsseltes DNS ein Placebo da die Besuchte Seite trotzdem über ihr Zertifikat sich ausweist. Selbst wenn sich hinter einer IP mehrere Server verbergen, so weiss man immer durch den Zertifikatsaustausch du warst gerade auf Deskmodder, selbst wenn du die IP auswendig wüsstest und gar kein DNS nutzt.
https://de.wikipedia.org/wiki/Server_Name_Indication
Leider ist die Anleitung fehlerhaft. Ich betreibe diese Software schon seid Jahren. Wenn man unbound mit apt Install unbound installiert, braucht man das Update Script nicht. Die DNS Server in der fritzbox stellt man unter: Heimnetz, Netzwerk, Netzwerkeinstellungen, ipv4 Einstellungen und ipv6 Einstellungen ein. Schade das hier nicht richtig recherchiert wurde. Es sind noch mehrere Fehler.
Schöner Guide für Leute die noch in das Thema einsteigen wollen. Nur eine Anmerkung von mir:
Bitte zensiert LAN-Adressen nicht in Tutorials. Es suggeriert, dass diese geschützt werden müssen.
Wäre ein Angreifer auch nur auf einem Gerät von euch kann er mit einem simplen ARP-Scan sowieso *jedes* Gerät im LAN sichtbar machen. Soviel dazu. Von außen nützt die IP im LAN ebenfalls nichts.
Wer es in mein Netz schafft kann sich gerne auf 10.0.0.1 bis 254 austoben. Die meisten hier dürften eh die Standard-Range der Fritze fahren 192.168.178.1 bis 254, von daher quatsch zu zensieren, jeder weiss es
Anmerkung 2: Da ich pi-hole nicht brauche (PC hat uBlock Origin und Android Blokada), kann man unbound auch nur betreiben um Zensur zu umgehen. Man darf auch gerne das INADDR_ANY auf 0.0.0.0 gemäß RFC 5735, Sektion 3 fahren. Dann antwortet unbound auf alle Anfragen von außen, von jeder IP, statt nur localhost.
qname-minimisation wird explizit erzwungen, sonst geht die vollständige addresse die man ansteuern will an root und alle nameserver -> wäre unklug
do-not-query-localhost, nicht den internen systemd-resolved Resolver verwenden, sonst hat das ganze null Sinn.
access-control um zugriffe vom internet zu blockieren damit der Server kein Teil von DNS amplification attacks wird (aber port ist eh nicht freigegeben, ist nur doppelter schutz für paranoiker)
Natürlich Port 53 statt 5353, damit Windows direkt zugreifen kann.
Statt 0.0.0.0 oder 127.0.0.1 nehme ich direkt die IP des SBCs, da ich intern systemd laufen lasse und unbound nur für externe Anfragen anderer LAN-Geräte da ist.
Klappt bei mir irgendwie nicht:
sudo service unbound restart
Job for unbound.service failed because the control process exited with error code.
systemctl status unbound.service
× unbound.service – Unbound DNS server
Loaded: loaded (/lib/systemd/system/unbound.service; enabled; preset: enabled)
Active: failed (Result: exit-code) since Wed 2023-02-08 21:38:04 CET; 15s ago
Docs: man:unbound(8)
Process: 3293 ExecStartPre=/usr/libexec/unbound-helper chroot_setup (code=exited, status=1/FAILURE)
Process: 3295 ExecStartPre=/usr/libexec/unbound-helper root_trust_anchor_update (code=exited, status=0/SUCCESS)
Process: 3297 ExecStart=/usr/sbin/unbound -d -p $DAEMON_OPTS (code=exited, status=1/FAILURE)
Process: 3298 ExecStopPost=/usr/libexec/unbound-helper chroot_teardown (code=exited, status=0/SUCCESS)
Main PID: 3297 (code=exited, status=1/FAILURE)
CPU: 86ms
Feb 08 21:38:04 serverchen systemd[1]: unbound.service: Scheduled restart job, restart counter is at 5.
Feb 08 21:38:04 serverchen systemd[1]: Stopped Unbound DNS server.
Feb 08 21:38:04 serverchen systemd[1]: unbound.service: Start request repeated too quickly.
Feb 08 21:38:04 serverchen systemd[1]: unbound.service: Failed with result ‚exit-code‘.
Feb 08 21:38:04 serverchen systemd[1]: Failed to start Unbound DNS server.
Und irgendwie… keine Ahnung, grad keine Lust auf Fehlersuche zu gehen ^^
Da scheint sich in deiner Config irgendwo ein Fehler eingeschlichen zu haben. Würde empfehlen die nochmal komplett abzugleichen.
IPv6 nur dann auf „yes“, wenn IPv6 auch zur Verfügung steht/genutzt wird – andernfalls auf „no“.
ipv6 steht zur Verfügung, da Kabelanschluss von Vodafone.
Inzwischen ist die gesamte Linux-Installation abgeraucht. Kann aktuell nicht prüfen, was da los ist, da am Server kein Monitor hängt. Ich bekomm nicht mal mehr einen SSH-Zugriff hin. Da muss ich wohl Zeit investieren ;(
Überprüf‘ mal Deine Config auf Syntaxfehler. Das geht ganz fix mit „unbound-checkconf“.
Warum eigentlich den ganzen Umstand mit manuell konfiguriertem Unbound?
Einfach Adguard Home aufsetzen. Geht deutlich einfacher und die Funktionalitäten von Unbound bringt AGH gleich direkt mit.
Die UI von AGH ist zudem noch deutlich moderner und lässt sich m.E. deutlich schöner handhaben. Zudem ist AGH deutlich leistungsfähiger. Ich hab PiHole und AGH als VM in einem größeren Umfeld laufen gehabt. PiHole hat sich da nicht wirklich bewährt, AGH schon.
Ich installiere meinen Kram lieber so weit wie es vertretbar ist, lieber selbst. AGH hat mich zudem im Selbsttest nicht überzeugt.
Ist mir alles zu kompliziert gibt es da nicht eine „günstige“ Hardware incl. dieser Software fertig zu kaufen?
Am besten mit Auto-Update Funktion des Hersteller?
Danke für den Guide!
Warum bleibt folgende Zeile auskommentiert?
[code]#root-hints: „/var/lib/unbound/root.hints“[/code]
Super Beitrag. Bei mir zu Hause kann ich meinen Raspberry auch nicht mehr wegdenken.
Wenn jemand etwas mehr möchte, kann ich eine Komplettanleitung bei GitHuB empfehlen.
https://github.com/trinib/AdGuard-WireGuard-Unbound-DNScrypt
Diese beinhaltet die Installation eines Raspberry OS samt Adguard + Unbound + DNSCrypt und Wireguard VPN.
Mit dem DNSCrypt werden noch zusätzlich die DNS Anfragen verschlüsselt und per Wireguard VPN kann man von überall in sein Heimnetzwerk. Man kann z.B. so auch sein Smartphone per VPN und Adguard filtern lassen.
Bei mir laufen 2 PiHoles auf Raspis, Unbound habe ich mal getestet, dass hat aber oft nicht richtig funktioniert. Seit langem habe ich nun in meinem Pihole meinen Router als DNS Resolver eingetragen. Im Router verwende ich dann DOT mit den Servern u.A. von Adguard. Das läuft alles super und sollte imho auch erstmal ausreichend sein. Ich kann keine signifikante Verschlechterung d. Ping od. Latenzen feststellen. VG
Meines Wissens nach wird die Adresse des pi-holes aber NICHT unter „Internet-DNS“ eingetragen sondern unter „Heimnetz-Netzwerk-IP4-Einstellungen“ und zusätzlich noch unter dem DNS-Rebindschutz!
Ich habe nicht so viele CLients. Ich trage die IP d. Pihole direkt in den Clients ein. Imho bin ich da etwas flexibler…
Wenn man den Pi-Hole als DNS verwendet, dann muss man dessen Adresse auf dem Router in den Internet-DNS Optionen eintragen. Schließlich sollen ja die DNS-Anfragen über den Pi-Hole, bzw. Unbound laufen. Das ist die Route:
internetfähiges Gerät -> Router -> Pi-Hole / Unbound -> Upstream DNS-Server / Root-Nameserver
Man hätte in dem Tutorial noch erwähnen sollen, dass Unbound grundsätzlich kein DoT und DoH unterstützt, wenn man diesen als Resolver nutzt. Denn die Root-Server können nur unverschlüsselte Anfragen bearbeiten und ausgeben. Die Verschlüsselung der DNS-Anfragen würde dann erst im Unbound stattfinden. Aber der Weg im Netz ist komplett unverschlüsselt.
Wenn man DoT nutzen möchte, muss in der Unbound Konfiguration öffentliche rekursive DNS-Server eingetragen werden. Dann fragt der Unbound nicht mehr direkt die Root-Server, sondern die öffentlichen DNS. Damit ist Unbound zwar kein echter Resolver mehr, aber dafür sind die Anfragen verschlüsselt.
Mit Unbound schon, aber sonst geht auch Client->Pihole -> Router -> Upstream DNS Server od. DOT Server.
Unter ‚Heimnetz-Netzwerk‘ gibt es bei mir in der FRITZ!Box 7590 AX keine Einstellungen zu IP4/IPv6 oder DNS.
Natürlich gibt es das auch bei Dir – Du musst nur direkt unter „WAN-Einstellung“ die „weitere Einstellungen“ ausklappen und dann ganz noch unten scrollen. Ein Klick auf das „?“ oben rechts in der Ecke hätte Dir bestimmt auch weitergeholfen.
Aber ob dort etwas zu ändern für Dich das richtige ist, wenn Du Dich nicht richtig durch das Menü der FRITZ!Box bewegen kannst, das lasse ich besser mal unkommentiert.
Danke für die Anleitung. Hat prima geklappt.
Allerdings kann man die Datei auch direkt via Cron updaten lassen:
Zum 1. jeden Monats wird’s um 4 Uhr ausgeführt
0 4 1 * * /usr/bin/curl -o /var/lib/unbound/root.hints https://www.internic.net/domain/named.cache && /usr/sbin/service unbound reload
was ich nicht ganz begreife ist, mit dem Automatische root.hints-Updates,muss ich das direkt ins terminal eingeben ? und wo soll ich das speichern ?
Cronjob erstellen
Die Anleitung ist fehlerhaft!
Lese die das hier Mal durch:
https://docs.pi-hole.net/guides/dns/unbound/
Wenn man unbound über apt Install unbound installiert, werden die Aktualisierungen der root hints automatisch durchgeführt.
Ich würde nicht so weit gehen und behaupten, dass die Anleitung in diesem Punkt fehlerhaft ist. Die Entwickler schreiben dazu folgendes (siehe: https://nlnetlabs.nl/documentation/unbound/unbound.conf):
root-hints:
Default is nothing, using builtin hints for the IN class. The file has the format of zone files, with root nameserver names and addresses only. The default may become outdated, when servers change, therefore it is good practice to use a root-hints file.
Fazit für mich: es kann nichts schaden.
Generell finde ich gut wenn man so etwas betreibt. Ich habe auf meinem Proxmox eine VM mit Pihole+Unbound+Wireguard seid vielen Jahren und in meinen Augen Pflicht bei jedem der mindestens einen Pi hat.
Es sind in der Anleitung leider einige Fehler bzw ungenügende Angaben. Und das finde ich schade.
Wer Filterlisten für Pihole sucht, wird hier fündig. In meinen Augen ein guter Anfang und deckt echt viel ab:
https://firebog.net/
https://github.com/RPiList/specials/blob/master/Blocklisten.md
Ich würde folgende Erweiterung der Unbound-Konfig vorschlagen:
auth-zone:
name: „.“
master: „b.root-servers.net“
master: „c.root-servers.net“
master: „d.root-servers.net“
master: „f.root-servers.net“
master: „g.root-servers.net“
master: „k.root-servers.net“
fallback-enabled: yes
for-downstream: no
for-upstream: yes
zonefile: „root.zone“
https://www.rfc-editor.org/rfc/rfc8806 <- ist nach dem RFC, damit ist dieser Unbound immer noch rekursiv, läd sich aber automatisch & regelmäßig die Rootzone einmal komplett, was den Vorteil hat, das die Rootserver weniger belastet werden, weil der erste DNS-Requests an die Rootserver dann entfallen würde. (ggf zonenfile-Name anpassen und testen)
Gute Ergänzung.
Aber wäre für diesen Zweck folgende Ergänzung nicht besser?
(aus /usr/share/doc/unbound/examples/unbound.conf)
auth-zone:
name: „.“
primary: 199.9.14.201 # b.root-servers.net
primary: 192.33.4.12 # c.root-servers.net
primary: 199.7.91.13 # d.root-servers.net
primary: 192.5.5.241 # f.root-servers.net
primary: 192.112.36.4 # g.root-servers.net
primary: 193.0.14.129 # k.root-servers.net
primary: 192.0.47.132 # xfr.cjr.dns.icann.org
primary: 192.0.32.132 # xfr.lax.dns.icann.org
primary: 2001:500:200::b # b.root-servers.net
primary: 2001:500:2::c # c.root-servers.net
primary: 2001:500:2d::d # d.root-servers.net
primary: 2001:500:2f::f # f.root-servers.net
primary: 2001:500:12::d0d # g.root-servers.net
primary: 2001:7fd::1 # k.root-servers.net
primary: 2620:0:2830:202::132 # xfr.cjr.dns.icann.org
primary: 2620:0:2d0:202::132 # xfr.lax.dns.icann.org
fallback-enabled: yes
for-downstream: no
for-upstream: yes
zonefile: „/var/lib/unbound/root.zone“
Hallo,
erst einmal ein Lob für die Dokumentation.
Nach Vollzug der einzelnen Schritte mit entsprechenden Aufrufen habe ich „nur noch 2 Probleme“.
1.) Rufe ich den DNS Leaktest auf, wird mir anstatt eines Root-DNS Servers meine ISP angezeigt. Der ISP sollte eigentlich nur den Zugang zum INet bereitstellen oder wird über den Test nur dieser abgefragt? Wie kann ich sicherstellen, dass wirklich nur ein DNS-Root-Server angefragt wird?
2.)
Beim Aufruf
dig pi-hole.net @127.0.0.1 -p 5335
erhalte ich keinen ad flag im DNS response,
beim Aufruf
dig dnssec.works @127.0.0.1 -p 5335
allerdings schon.
Warum?
Vielen Dank
Ein Vorschlag für ein verbessertes Update-Skript (temporärer Pfad ist bei mir /opt/cron/tmp, kann angepasst werden; Dienstmanagement läuft hier per „systemctl“):
#!/bin/bash
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/games:/usr/games
if [ -f „/opt/cron/tmp/named.root“ ]; then
rm „/opt/cron/tmp/named.root“
fi
wget -nv -N -P „/opt/cron/tmp“ https://www.internic.net/domain/named.root
if [ -f „/opt/cron/tmp/named.root“ ]; then
if cmp -s „/var/lib/unbound/root.hints“ „/opt/cron/tmp/named.root“; then
rm „/opt/cron/tmp/named.root“
else
mv -f „/opt/cron/tmp/named.root“ „/var/lib/unbound/root.hints“
#service unbound restart
systemctl restart unbound
fi
fi
Das würde ich so nicht machen. Das ist aus meiner Sicht viel zu umständlich und die Laufzeit des Scripts viel zu lang.
Ich rekapituliere mal:
1.du setzt Pfadvariablen
2.Du lädst die neue named.root herunter,
3.du prüfst ob die Datei neuer ist als die vorhandene,
4.du ersetzt die alte mit der neuen Datei
5. du startest unbound neu
Schritt 1 ist aus meiner Sicht unnötig,da die Pfade für ein Script mit Root-Rechten normalerweise erreichbar sind
Schritte 2-4 kannst du zusammenfassen,indem du direkt die alte named.root mit der neuen ersetzt. Warum? Weil es keine Rolle spielt,ob die vorhandene identisch oder älter ist.
Dann würde ich prüfen,ob ein „reload“ bei unbound nicht ausreichend ist,weil der „restart“ deutlich länger braucht. Da will ich mich aber nicht festlegen,weil ich gerade kein Unbound zur Verfügung habe um das zu testen.
Was spricht gegen das in der Anleitung genannte Script bzw. wo konkret sollen die Verbesserungen sein? Es ist -zumindest für mich als SysAdmin- umständlicher und erzeugt mehr unnötige Last auf dem System als nötig.
Aus meiner Sicht kann man das in der Anleitung genannte Script nicht verbessern,mal abgesehen davon,dass man sich das ganze Script spart und die nötigen Befehle direkt als Einzeiler in die Crontab einträgt.
Schöne Anleitung aber du hast die root.hints geladen und dann müsste auch die # weg beim root.hints Pfad in der unbound.conf.
😉
Hallo, bei mir gehen mit unbound 2 DNS-Adressen nicht. (127.0.0.1#5335)
Ich habe schon alles versucht, Browser natürlich auch egal.
Kann Jemand die Adressen bitte mal testen?
http://www.geocachingtoolbox.com
http://www.gc-apps.com
Mit Kreuz bei Upstram DNS Google bzw. Cloudflare gehts natürlich.
Weiß Jemand Rat? Danke!
Ja, ich könnte mir vorstellen woran es liegt.
Ist in der /etc/unbound/unbound.conf das richtige interface eingetragen ?
z.B.: outgoing-interface: 192.168.178.8
Hier müssen die Hochkommas raus, falls man die Zeile nutzen will, mit Hochkommas startet unbound nicht
#root-hints: „/var/lib/unbound/root.hints“
Danke für die Anleitung
In dem script für die /etc/crontab ist ein Fehler.
Mit diesen Einstellungen „* * * */3 * root /home/user/update_unbound_dns.sh >/dev/null 2>&1“
wird es alle 1/4 Jahre (Jan – Dez) das ganze Vierteljahr ausgeführt.
01 04 01 */3 * root /home/user/update_unbound_dns.sh > /dev/null 2>&1
schafft Abhilfe.