Fehler (?): pihole + unbound

Cpt.H4rl0ck

Ensign
Registriert
Apr. 2010
Beiträge
163
Hallo Forum,

hab meinen Pi neu aufsetzten müssen. Pi-hole ist installiert und läuft.

Unbound läuft mit folgender .conf :

Code:
# Konfiguration für Unbound als DNS für PiHole mit DoT. Basiert auf:
# Konfiguration von https://bartonbytes.com/posts/configure-pi-hole-for-dns-over-tls/
# und Konfiguration von https://docs.pi-hole.net/guides/dns/unbound/

server:
# If no logfile is specified, syslog is used
chroot: ""
logfile: "/var/log/unbound.log"
verbosity: 1
log-queries: yes

# If enabled id.server and hostname.bind queries are refused.
hide-identity: yes

# If enabled version.server and version.bind queries are refused.
hide-version: yes

# If yes, Unbound doesn't insert authority/additional sections
# into response messages when those sections are not required.
minimal-responses: yes

#Send minimum amount of information to  upstream servers to
# enhance privacy.
qname-minimisation: yes

# rotates RRSet order in response (the random number
# is taken from the query ID, for speed and thread safety)
rrset-roundrobin: yes

# Enable  or disable whether the upstream queries use TCP only for
# transport.  Useful in tunneling scenarios.
# tcp-upstream: yes

# Enable or disable whether the upstream queries use SSL only for
# transport.
ssl-upstream: yes

# certificates used for authenticating connections made to outside peers
ssl-cert-bundle: /etc/ssl/certs/ca-certificates.crt

# Interface to use to connect to the network
interface: 127.0.0.1

# Port for Usage in Pi-Hole as 127.0.0.1#5533
port: 5533

# Enable or disable whether TCP/UDP/IP4 queries are answered or issued.
do-ip4: yes
do-udp: yes
do-tcp: yes

# May be set to yes if you have IPv6 connectivity
do-ip6: yes

# prefer IPv6 over IPv4 yes or no
prefer-ip6: no

# Trust glue only if it is within the servers 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.
# Suggested by the unbound man page to reduce fragmentation reassembly problems
edns-buffer-size: 1472

# TTL bounds for cache
cache-min-ttl: 600
cache-max-ttl: 14400

# 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
num-threads: 1

# Cache Memory rrset should have double size as msg
msg-cache-size: 50m
rrset-cache-size: 100m

# Accelerate UDP with multithreading
so-reuseport: yes

# Ensure kernel buffer is large enough to not loose 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

access-control: 127.0.0.0/8 allow

forward-zone: 
name: "."
# quad9.net primary
forward-addr: 9.9.9.9@853
# cloudflare primary
forward-addr: 1.1.1.1@853
# quad9.net secondary
forward-addr: 149.112.112.112@853
# cloudflare secondary
forward-addr: 1.0.0.1@853 
#quad9 ipv6 primary
forward-addr: 2620:fe::fe@853   
#quad9 ipv6 secondary
forward-addr: 2620:fe::9@853   
#cloudflare ipv6
forward-addr: 2606:4700:4700::1111@853   
#cloudflare ipv6
forward-addr:2606:4700:4700::1001@853

Wenn ich jetzt unbound auf Funktionalität (DNSSEC validation) prüfe,
Code:
dig kuketz-blog.de @127.0.0.1 -p 5335 +short

passiert folgendes:
Code:
; <<>> DiG 9.11.5-P4-5.1+deb10u5-Raspbian <<>> kuketz-blog.de @127.0.0.1 -p 5335 +short
;; global options: +cmd
;; connection timed out; no servers could be reached
Hier sollte doch eine IP-Adresse zurückkommen?

Die zweite Prüfung mit,
Code:
dig sigfail.verteiltesysteme.net @127.0.0.1 -p 5335
sollte doch "status: SERVFAIL" enthalten.

Bei mir sieht es jedoch so aus:
Code:
; <<>> DiG 9.11.5-P4-5.1+deb10u5-Raspbian <<>> sigfail.verteiltesysteme.net @127.0.0.1 -p 5335 
;; global options: +cmd 
;; connection timed out; no servers could be reached

Hab Unbound als DNS-Resolver im Pi-hole angegeben - keine weiteren DNS-Server.
Webseiten können ohne Probleme aufgelöst werden ...

Finde den Fehler nicht..

Grüße
 
Jap, check mal deine Ports, Zahlendreher.
 
  • Gefällt mir
Reaktionen: Cpt.H4rl0ck
Zuletzt bearbeitet:
es gibt keine guten und schlechten ports. nur welche, die oft in standards oder quasi-standards verwendet werden - bspw. 21 (FTP), 22 (SSH), 80/8080 (HTTP), 443 (HTTPS/SSL) oder eben 53 (DNS).

funktional macht das überhaupt keinen unterschied, es ist nur eine art zusatzinfo á la die zimmernummer zur hausnummer. port 53 willst du nicht nehmen (da das für standard DNS gilt), sondern etwas anderes, da du "secure DNS" machen willst, aber da liegt es nahe einfach die nummer irgendwie abzuwandeln und schon kommen zahlen raus wie 5353, 5533, 5300 o.ä.. und jeder kann sich trotzdem denken, aha.. wird wohl was mit DNS zu tun haben. du kannst aber auch port 1234, 42069 oder 666 nehmen, wenn dir das lieber ist und noch nicht belegt ist :D
 
  • Gefällt mir
Reaktionen: masked__rider und Cpt.H4rl0ck
Cai-pirinha schrieb:
es gibt keine guten und schlechten ports. nur welche, die oft in standards oder quasi-standards verwendet werden - bspw. 21 (FTP), 22 (SSH), 80/8080 (HTTP), 443 (HTTPS/SSL) oder eben 53 (DNS).

funktional macht das überhaupt keinen unterschied, es ist nur eine art zusatzinfo á la die zimmernummer zur hausnummer. port 53 willst du nicht nehmen (da das für standard DNS gilt), sondern etwas anderes, da du "secure DNS" machen willst, aber da liegt es nahe einfach die nummer irgendwie abzuwandeln und schon kommen zahlen raus wie 5353, 5533, 5300 o.ä.. und jeder kann sich trotzdem denken, aha.. wird wohl was mit DNS zu tun haben. du kannst aber auch port 1234, 42069 oder 666 nehmen, wenn dir das lieber ist und noch nicht belegt ist :D
Super - danke für die Antwort ... ;-)
 
Zurück
Oben