"Christmas - the time to fix the computers of your loved ones" « Lord Wyrm

PiHole with Unbound (recursive DNS) Step-by-Step Tutorial | The internet is broken!

TOM 17.01.2020 - 14:35 129401 367 Thread rating
Posts

master blue

Mr. Anderson
Avatar
Registered: Oct 2000
Location: 2340, 2352, 1200
Posts: 8580
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

Here to stay
Avatar
Registered: May 2002
Location: Wien 22
Posts: 961
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

Super Moderator
Oldschool OC.at'ler
Avatar
Registered: Nov 2000
Location: Vienna
Posts: 7345
https://www.crosstalksolutions.com/...-tutorial-2023/

Sehr ausführlicher Guide mit Bildern, inkl. Unbound DNS

TOM

Super Moderator
Oldschool OC.at'ler
Avatar
Registered: Nov 2000
Location: Vienna
Posts: 7345
Zu meinem 1st post recht passend soeben entdeckt, ein talk aus 2015 The Website Obesity Crisis

I can relate

__Luki__

bierernste Islandkritik
Avatar
Registered: Nov 2003
Location: gradec
Posts: 2976
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:
click to enlarge

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:
Code:
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 :)
Bearbeitet von __Luki__ am 25.02.2023, 18:17

COLOSSUS

Administrator
GNUltra
Avatar
Registered: Dec 2000
Location: ~
Posts: 12055
Ich glaube, DNSSEC + NTP-mit-DNS-Records + DNS-Recursor-mit-Systemzeit-in-den-1970ern-nach-dem-Booten kann zu diesem Problem fuehren.

__Luki__

bierernste Islandkritik
Avatar
Registered: Nov 2003
Location: gradec
Posts: 2976
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 :)
Bearbeitet von __Luki__ am 25.02.2023, 19:36

voyager

kühler versilberer :)
Avatar
Registered: Nov 2001
Location: Stmk/Austria
Posts: 3583
Zitat aus einem Post von COLOSSUS
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

Administrator
GNUltra
Avatar
Registered: Dec 2000
Location: ~
Posts: 12055
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

kühler versilberer :)
Avatar
Registered: Nov 2001
Location: Stmk/Austria
Posts: 3583
Zitat aus einem Post von COLOSSUS
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

Moderator
Er ist tot, Jim!
Avatar
Registered: Mar 2001
Location: Wien
Posts: 49690
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

BYOB
Registered: Jan 2003
Location: -
Posts: 5924
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

kühler versilberer :)
Avatar
Registered: Nov 2001
Location: Stmk/Austria
Posts: 3583
Zitat aus einem Post von Viper780
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

Here to stay
Registered: Nov 2002
Location: Graz
Posts: 4834
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.

Code:
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

Here to stay
Registered: Nov 2002
Location: Graz
Posts: 4834
Irgendwer eine Idee? Ich komm ned drauf :(
Kontakt | Unser Forum | Über overclockers.at | Impressum | Datenschutz