The Pi-hole developers recommend leaving the Pi-hole cache enabled with unbound.
Okay, I'll reaktivate the cache of Pi-Hole.
Die Argumente die scheinbar für ein Deaktivieren des Caches sprechen sind
- Doppelter Cache bringt nix
- Unbound kann kein Prefetch machen
Hier in diesem Topic ist das mal aufgearbeitet.
Was bleibt:
- Doppelter Cache schadet nicht
- Unbound macht sehr wohl auch bei aktiviertem Pihole Cache Prefetching
- Es gibt einen minimalen Geschwindigkeitsvorteil (0,05ms)
- Das manuelle Deaktivieren nach jedem Neustart/Update von Pihole entfällt
Mein Fazit war: Cache bleibt an.
@yubiuser Ich mache es nun auch so.
Wie hast du denn Unbound konfiguriert?
Danke. Sehr interessant.
Leider findet sich noch keine Antwort welche Vorteile entstehen, wenn der pihole Cache nicht abgeschaltet wird. Aus rein technischer Sicht erscheint mir das nämlich eher nachteilig. Es ist für die Funktionsweise eines Caches ja doch von Vorteil über die cachehits und cachemiss Bescheid zu wissen.
Größtenteils habe ich die pihole-unbound Anleitung befolgt, wichtigster Unterschied ist wahrscheinlich, dass ich serve-expired
auf yes gesetzt habe
server:
# If no logfile is specified, syslog is used
logfile: "/var/log/unbound/unbound.log"
log-time-ascii: yes
verbosity: 1
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: 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!
root-hints: "/var/lib/unbound/root.hints"
# 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: 0
cache-max-ttl: 86400
# If enabled, unbound attempts to serve old responses from cache with a TTL of serve-expired-reply-ttl in the response without
# waiting for the actual resolution to finish. The actual resolu tion answer ends up in the cache later on. Default is "no"
serve-expired: yes
# Limit serving of expired responses to configured seconds after expiration. 0 disables the limit. This option only applies when
# serve-expired is enabled. A suggested value per draft-ietf-dnsop-serve-stale-10 is between
# 86400 (1 day) and 259200 (3 days). The default is 0.
serve-expired-ttl: 172800
# Perform prefetching of close to expired message cache entries
# This only applies to domains that have been frequently queried
prefetch: yes
# If yes, fetch the DNSKEYs earlier in the validation process, when a DS record is encountered. This lowers the latency of
# requests. It does use a little more CPU. Also if the cache is
# set to 0, it is no use. Default is no
prefetch-key: yes
# One thread should be sufficient, can be increased on beefy machines
num-threads: 1
# UDP schneller mit Multithreading (Tux only).
so-reuseport: yes
# 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
# If enabled, statistics are cumulative since starting unbound, without clearing the statistics counters
# after logging the statistics. Default is no
statistics-cumulative: yes
# If enabled, extended statistics are printed from unbound-control. Default is off, because keeping track
#of more statistics takes time. The counters are listed in unbound-control.
extended-statistics: yes
remote-control:
# Enable remote control with unbound-control(8) here.
# set up the keys and certificates with unbound-control-setup.
control-enable: yes
Ja, dachte ich auch erst, allerdings sehe ich, dass Unbound bei mir cachehits und cachemiss trotz aktiviertem pihole-cache kennt. Möglicherweise liegt das am aktivierten serve-expired
.
Hier mal ein aktueller Stats-Auszug von Unbound
total.num.queries=112479
total.num.queries_ip_ratelimited=0
total.num.cachehits=107345
total.num.cachemiss=5134
total.num.prefetch=48121
total.num.zero_ttl=46861
total.num.recursivereplies=5134
total.requestlist.avg=1.34215
total.requestlist.max=48
total.requestlist.overwritten=0
total.requestlist.exceeded=0
total.requestlist.current.all=0
total.requestlist.current.user=0
total.recursion.time.avg=0.443407
total.recursion.time.median=0.0842971
Sieht tatsächlich ganz gut aus.
Ich bin mal gespannt und beobachte das ein paar Tage. Läuft ja nun erst ein paar Stunden zuverlässig