PiHole with Unbound (recursive DNS) Step-by-Step Tutorial | The internet is broken! - Seite 23
URL: https://www.overclockers.at/diy-soc/pihole-with-unbound-recursive-dns-step-by-step-tutorial-the-internet-is-broken_255071/page_23 - zur Vollversion wechseln!
master blue schrieb am 26.10.2022 um 22:40
Aus der RPi Reihe dürfte ein 1B+ und 2B den geringsten Verbrauch haben. Gibts noch was mit noch weniger für pihole only (mit LAN Port)?
ZARO schrieb am 20.11.2022 um 12:00
Hi,
Hier ist noch eine Erweiterung, die für Mikrotik Router Benutzer das ganze noch ein wenig Wartungsfreundlicher macht.
Mit VRRP kann man eine Viertuelle IP Adresse zwischen dem Server und Router switchen lassen, somit sollte das DNS auch funktionieren wenn mal PiHole down ist:
In allen Scripts muss natürlich die IP passend zu dem Netzwerk gesetzt werden.
Mikrotik Router:
VRRP IP hinzufügen
/interface vrrp add interface=bridge name=vrrp-dns version=2 vrid=10
/ip address add address=192.168.x.9/24 interface=vrrp-dns network=192.168.x.0
Ubuntu/Paspi:
apt install keepalived
Konfig File anpassen: /etc/keepalived/keepalived.conf
global_defs {
router_id PiHole # give unique id for each router
vrrp_skip_check_adv_addr
script_user root
enable_script_security
}
vrrp_script check_dns {
script "/etc/keepalived/check_dns.sh"
interval 5 # every 5 seconds
weight 20 # add 20 points if OK
timeout 5 #
rise 2 # avoid flapping
fall 2 # avoid flapping
}
vrrp_instance VI_1 {
state MASTER
interface ens256 !!!
virtual_router_id 10
priority 90
advert_int 1
virtual_ipaddress {
192.168.x.9/24
}
track_script {
check_dns
}
}
DNS check script:
/etc/keepalived/check_dns.sh:
#!/bin/bash
host -s -4 -t A amazon.com 127.0.0.1 > /dev/null 2>&1
chmod +x /etc/keepalived/check_dns.sh
und starten:
systemctl restart keepalived
Ab diesem Zeitpunkt sollte bei der am Raspi funktionierenden DNS Auflösung die VRRP Adresse am Raspi liegen.
Jetzt nur noch am Miktorik den DNS Server im DHCP Server setzen:
IP -> DHCP Server -> Networks - bei dazugehörigem Netzwerk den DNS Eintrag auf die VRRP Adresse ändern.
lg
TOM schrieb am 29.11.2022 um 17:25
https://www.crosstalksolutions.com/...-tutorial-2023/
Sehr ausführlicher Guide mit Bildern, inkl. Unbound DNS
TOM schrieb am 21.01.2023 um 17:55
Zu meinem 1st post recht passend soeben entdeckt, ein talk aus 2015 The Website Obesity Crisis
I can relate
__Luki__ schrieb am 25.02.2023 um 16:24
Ich war im Skiurlaub u hab vorm wegfahren pihole, modem, etc ausgeschaltet...
Heute nachm heimkommen wieder in Betrieb genommen - dhcp funzt, aber es kommen keine dns queries mehr an am pihole & dns funzt auch net mehr... Kommt das jemandem bekannt.vor?
Ps: zu mehr analyse hatte ich grad noch net die muse, dachte mir aber ich frag mal, ob jemand das problem schonmal hatte 
edit: sieht aus, als waer das dns generell kaputt - sys reboot / dns resolver reboot etc hat leider nix gebracht...
ergebnis von dig:
Kann es sein, dass das Problem damit zusammenhaengt, dass die systemzeit offensichtlich nicht stimmt?
Er kann naemlich auch den ntp server nicht aufloesen, laut pihole.log:
Feb 21 01:33:17: query[AAAA] 1.debian.pool.ntp.org from 127.0.0.1
Feb 21 01:33:17: forwarded 1.debian.pool.ntp.org to 127.0.0.1#5353
Feb 21 01:33:17: reply error is SERVFAIL
Feb 21 01:33:17: forwarded 1.debian.pool.ntp.org to 127.0.0.1#5353
Feb 21 01:33:17: reply error is SERVFAIL
Soll ich die zeit mit 'date -s' manuell anpassen oder gibts da a elegantere loesung? Danke
COLOSSUS schrieb am 25.02.2023 um 18:50
Ich glaube, DNSSEC + NTP-mit-DNS-Records + DNS-Recursor-mit-Systemzeit-in-den-1970ern-nach-dem-Booten kann zu diesem Problem fuehren.
__Luki__ schrieb am 25.02.2023 um 19:26
Habe die IP vom NTP in der /etc/hosts hinterlegt, nun laeufts wieder.
Auch gleich wieder rueckgaengig gemacht, da das aufloesen dank richtiger zeit auch wieder funktioniert
voyager schrieb am 19.05.2023 um 22:31
Ich glaube, DNSSEC + NTP-mit-DNS-Records + DNS-Recursor-mit-Systemzeit-in-den-1970ern-nach-dem-Booten kann zu diesem Problem fuehren.
Das Zeit Problem hatte ich auch schon im Unbound. Deswegen hab ich mir jetzt ein GPS Modul bestellt, und der Pi wird dann auch ein Stratum 1 Timeserver im Lan. So sind dann Zeitprobleme gelöst, und die Zeit über GPS(PPS Signal) ist sehr genau
COLOSSUS schrieb am 20.05.2023 um 09:13
GPS als Timesource (vor allem mit funktionierendem PPS) ist schoen, aber die meisten Module brauchen dafuer einen 3D-Fix, der in Innenraeumen/Serverschraenken oft nicht so ohne weiteres zu bekommen ist :/ Welches Modul hast du denn auf deinem RPi im Einsatz?
voyager schrieb am 20.05.2023 um 12:01
GPS als Timesource (vor allem mit funktionierendem PPS) ist schoen, aber die meisten Module brauchen dafuer einen 3D-Fix, der in Innenraeumen/Serverschraenken oft nicht so ohne weiteres zu bekommen ist :/ Welches Modul hast du denn auf deinem RPi im Einsatz?
Ich hab ein Neo M8M mit externer Antenne, die ich an der Hausmauer aussen hab. M8 deswegen, weil es mit -167db auch bei geringer Signalstärke noch was raus holt, und es alle gängigen Positionssysteme anzapft (GPS, Galileo, GLONASS, BeiDou). M6/M7 ist da noch merkbar schlechter.
Viper780 schrieb am 20.05.2023 um 12:29
Schon ein ordentlicher Aufwand nur fürs Zeitsignal aber auch sehr cooles Projekt.
Überlege jetzt schon auf welcher Fensterbank ich sowas bei mir hingeben kann
watercool schrieb am 20.05.2023 um 13:46
Hab jetzt auch pihole und unbound als separate Container als Proxmox LXC laufen und als Backup separat auf der synology NAS als Docker. Gesynct über orbital sync. Klappt 1A soweit
voyager schrieb am 20.05.2023 um 14:36
Schon ein ordentlicher Aufwand nur fürs Zeitsignal aber auch sehr cooles Projekt.
Überlege jetzt schon auf welcher Fensterbank ich sowas bei mir hingeben kann
Eigentlich gar nicht so schlimm. 10-15€ Materialkosten(ohne Raspberry), 45 Minuten Arbeit.
Mein kleiner NW Schrank ist zufälligerweise neben einen Fenster, da war das thema schnell erledigt. Und Anleitungen zu einem GPS Timeserver gibts genug. Ich hab die genommen: Github GPS Timeserver
dio schrieb am 20.05.2023 um 18:50
Ich bin leider zu unfähig... möchte unbound auf Debian 11 in einer Proxmox VE laufen lassen. Ich schaffs nicht, einen Hostnamen aufzulösen.
christoph@debian-fujitsu:~$ cat /etc/unbound/unbound.conf.d/pi-hole.conf
server:
# If no logfile is specified, syslog is used
# logfile: "/var/log/unbound/unbound.log"
verbosity: 2
do-not-query-localhost: no
interface: 127.0.0.1
interface: 192.168.1.177
# interface: 0.0.0.0
port: 53
do-ip4: yes
do-udp: yes
do-tcp: yes
# May be set to yes if you have IPv6 connectivity
do-ip6: no
# 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"
#root-hints: "/usr/share/dns/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 [url]https://discourse.pi-hole.net/t/unbound-stubby-or-dnscrypt-proxy/9378[/url] 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 ([url]https://indico.dns-oarc.net/event/36/contributions/776/[/url])
# 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
# Perform prefetching of close to expired message cache entries
# This only applies to domains that have been frequently queried
prefetch: yes
# One thread should be sufficient, can be increased on beefy machines. In reality for most users running on small networks or on a single machine, it should be unnecessary to seek performance enhancement by increasing num-threads above 1.
num-threads: 1
# Ensure kernel buffer is large enough to not lose messages in traffic spikes
# so-rcvbuf: 1m
# Ensure privacy of local IP ranges
# private-address: 192.168.0.0/16
# private-address: 169.254.0.0/16
# private-address: 172.16.0.0/12
# private-address: 10.0.0.0/8
# private-address: fd00::/8
# private-address: fe80::/10
#forward-zone:
# name: "."
# forward-addr: 1.1.1.1@53#one.one.one.one
# forward-addr: 8.8.8.8@53#dns.google
# forward-addr: 1.0.0.1@53#one.one.one.one
# forward-addr: 8.8.4.4@53#dns.google
access-control: 192.168.1.0/24 allow
access-control: 127.0.0.1 allow
christoph@debian-fujitsu:~$ sudo netstat -tulpn
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:5355 0.0.0.0:* LISTEN 1477/systemd-resolv
tcp 0 0 127.0.0.53:53 0.0.0.0:* LISTEN 1477/systemd-resolv
tcp 0 0 192.168.1.177:53 0.0.0.0:* LISTEN 1143/unbound
tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN 1143/unbound
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 487/sshd: /usr/sbin
tcp 0 0 127.0.0.1:8953 0.0.0.0:* LISTEN 1143/unbound
tcp6 0 0 :::5355 :::* LISTEN 1477/systemd-resolv
tcp6 0 0 :::22 :::* LISTEN 487/sshd: /usr/sbin
udp 0 0 127.0.0.53:53 0.0.0.0:* 1477/systemd-resolv
udp 0 0 192.168.1.177:53 0.0.0.0:* 1143/unbound
udp 0 0 127.0.0.1:53 0.0.0.0:* 1143/unbound
udp 0 0 0.0.0.0:68 0.0.0.0:* 433/dhclient
udp 0 0 0.0.0.0:5355 0.0.0.0:* 1477/systemd-resolv
udp6 0 0 :::5355 :::* 1477/systemd-resolv
christoph@debian-fujitsu:~$ dig @127.0.0.1 google.at
; <<>> DiG 9.16.37-Debian <<>> @127.0.0.1 google.at
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached
hristoph@debian-fujitsu:~$ sudo service unbound status
● unbound.service - Unbound DNS server
Loaded: loaded (/lib/systemd/system/unbound.service; enabled; vendor preset: enabled)
Active: active (running) since Sat 2023-05-20 15:37:00 CEST; 3h 9min ago
Docs: man:unbound(8)
Main PID: 1143 (unbound)
Tasks: 1 (limit: 7072)
Memory: 10.2M
CPU: 644ms
CGroup: /system.slice/unbound.service
└─1143 /usr/sbin/unbound -d -p
May 20 17:26:21 debian-fujitsu unbound[1143]: [1143:0] info: resolving . DNSKEY IN
May 20 17:26:21 debian-fujitsu unbound[1143]: [1143:0] info: priming . IN NS
May 20 18:20:51 debian-fujitsu unbound[1143]: [1143:0] info: resolving . DNSKEY IN
May 20 18:20:51 debian-fujitsu unbound[1143]: [1143:0] info: priming . IN NS
May 20 18:45:18 debian-fujitsu unbound[1143]: [1143:0] info: resolving google.at. A IN
May 20 18:45:18 debian-fujitsu unbound[1143]: [1143:0] info: priming . IN NS
May 20 18:45:22 debian-fujitsu unbound[1143]: [1143:0] info: resolving google.at. A IN
May 20 18:45:22 debian-fujitsu unbound[1143]: [1143:0] info: priming . IN NS
May 20 18:45:27 debian-fujitsu unbound[1143]: [1143:0] info: resolving google.at. A IN
May 20 18:45:27 debian-fujitsu unbound[1143]: [1143:0] info: priming . IN NS
christoph@debian-fujitsu:~$ cat /var/lib/unbound/root.key
. 86400 IN DNSKEY 257 3 8 AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTOiW1vkIbzxeF3+/4RgWOq7HrxRixHlFlExOLAJr5emLvN7SWXgnLh4+B5xQlNVz8Og8kvArMtNROxVQuCaSnIDdD5LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF0jLHwVN8efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7pr+eoZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLYA4/ilBmSVIzuDWfdRUfhHdY6+cn8HFRm+2hM8AnXGXws9555KrUB5qihylGa8subX2Nn6UwNR1AkUTV74bU= ;{id = 20326 (ksk), size = 2048b} ;;state=2 [ VALID ]
christoph@debian-fujitsu:~$ cat /usr/share/dns/root.hints
; This file holds the information on root name servers needed to
; initialize cache of Internet domain name servers
; (e.g. reference this file in the "cache . <file>"
; configuration file of BIND domain name servers).
;
; This file is made available by InterNIC
; under anonymous FTP as
; file /domain/named.cache
; on server FTP.INTERNIC.NET
; -OR- RS.INTERNIC.NET
;
; last update: January 11, 2021
; related version of root zone: 2021011101
;
; FORMERLY NS.INTERNIC.NET
;
. 3600000 NS A.ROOT-SERVERS.NET.
A.ROOT-SERVERS.NET. 3600000 A 198.41.0.4
A.ROOT-SERVERS.NET. 3600000 AAAA 2001:503:ba3e::2:30
;
; FORMERLY NS1.ISI.EDU
;
. 3600000 NS B.ROOT-SERVERS.NET.
B.ROOT-SERVERS.NET. 3600000 A 199.9.14.201
B.ROOT-SERVERS.NET. 3600000 AAAA 2001:500:200::b
;
; FORMERLY C.PSI.NET
;
. 3600000 NS C.ROOT-SERVERS.NET.
C.ROOT-SERVERS.NET. 3600000 A 192.33.4.12
C.ROOT-SERVERS.NET. 3600000 AAAA 2001:500:2::c
;
; FORMERLY TERP.UMD.EDU
;
. 3600000 NS D.ROOT-SERVERS.NET.
D.ROOT-SERVERS.NET. 3600000 A 199.7.91.13
D.ROOT-SERVERS.NET. 3600000 AAAA 2001:500:2d::d
;
; FORMERLY NS.NASA.GOV
;
. 3600000 NS E.ROOT-SERVERS.NET.
E.ROOT-SERVERS.NET. 3600000 A 192.203.230.10
E.ROOT-SERVERS.NET. 3600000 AAAA 2001:500:a8::e
;
; FORMERLY NS.ISC.ORG
;
. 3600000 NS F.ROOT-SERVERS.NET.
F.ROOT-SERVERS.NET. 3600000 A 192.5.5.241
F.ROOT-SERVERS.NET. 3600000 AAAA 2001:500:2f::f
;
; FORMERLY NS.NIC.DDN.MIL
;
. 3600000 NS G.ROOT-SERVERS.NET.
G.ROOT-SERVERS.NET. 3600000 A 192.112.36.4
G.ROOT-SERVERS.NET. 3600000 AAAA 2001:500:12::d0d
;
; FORMERLY AOS.ARL.ARMY.MIL
;
. 3600000 NS H.ROOT-SERVERS.NET.
H.ROOT-SERVERS.NET. 3600000 A 198.97.190.53
H.ROOT-SERVERS.NET. 3600000 AAAA 2001:500:1::53
;
; FORMERLY NIC.NORDU.NET
;
. 3600000 NS I.ROOT-SERVERS.NET.
I.ROOT-SERVERS.NET. 3600000 A 192.36.148.17
I.ROOT-SERVERS.NET. 3600000 AAAA 2001:7fe::53
;
; OPERATED BY VERISIGN, INC.
;
. 3600000 NS J.ROOT-SERVERS.NET.
J.ROOT-SERVERS.NET. 3600000 A 192.58.128.30
J.ROOT-SERVERS.NET. 3600000 AAAA 2001:503:c27::2:30
;
; OPERATED BY RIPE NCC
;
. 3600000 NS K.ROOT-SERVERS.NET.
K.ROOT-SERVERS.NET. 3600000 A 193.0.14.129
K.ROOT-SERVERS.NET. 3600000 AAAA 2001:7fd::1
;
; OPERATED BY ICANN
;
. 3600000 NS L.ROOT-SERVERS.NET.
L.ROOT-SERVERS.NET. 3600000 A 199.7.83.42
L.ROOT-SERVERS.NET. 3600000 AAAA 2001:500:9f::42
;
; OPERATED BY WIDE
;
. 3600000 NS M.ROOT-SERVERS.NET.
M.ROOT-SERVERS.NET. 3600000 A 202.12.27.33
M.ROOT-SERVERS.NET. 3600000 AAAA 2001:dc3::35
dio schrieb am 25.05.2023 um 22:32
Irgendwer eine Idee? Ich komm ned drauf 
overclockers.at v4.thecommunity
© all rights reserved by overclockers.at 2000-2025