Hallo zusammen, ich habe auf meinem Raspberry Pi 4 B / 8GB Ram Pi-Hole + Unbound installiert und konfiguriert wie im Video.
Soweit funktioniert alles. Das einzige was auffällig ist, ist die Warnung im Log von Unbound, welche nach einem restart geloggt wird:

May 18 14:48:15 unbound[858:0] info: start of service (unbound 1.17.1).

May 18 14:54:05 unbound[858:0] info: service stopped (unbound 1.17.1).

May 18 14:54:05 unbound[1697:0] warning: subnetcache: prefetch is set but not working for data originating from the subnet module cache.

Die Angaben zum aktuellen Betriebssystem sind im Screenshot zu sehen.

Kann mir da jemand helfen? Bin noch absoluter Einsteiger im Thema Linux und Raspberry Pi.

Grüsse Manuel

@manuel Hallo Manuel!

Kannst du bitte mal die Ausgabe von dem folgenden Befehl posten:

sudo systemctl status unbound

Grüße Marcel

@marci Hallo Marcel
Danke für deine rasche Antwort.

Hier der gewünschte Screenshot 🙂 

Gruss Manuel

@manuel Hallo Manuel und Danke für den Screenshot.

Der Unbound Dienst läuft ja einwandfrei.

Die Fehlermeldung

Veröffentlicht von: @manuel

↑

unbound[1697:0] warning: subnetcache: prefetch is set but not working for data originating from the subnet module cache.

sagt nur aus, dass in der Config von Unbound bei Debain (Raspberry Pi OS) das Modul 'subnetcache (ECS)' aktiviert ist und wohl der externe DNS-Server, diese Anfrage nicht unterstützt. Das soll heißen, dass durch diesen Dienst eine EDNS-Validierung nicht durchgeführt werden kann.

Wofür EDNS steht und wofür dieses genutzt wird, kann du in diesem Artikel erfahren:

https://www.quad9.net/de/support/faq/#edns

Entweder du tauscht die Upstream-DNS-Server in der Config von Unbound aus, oder du deaktivierst das Modul mit dem folgenden Eintrag:

server:
        module-config: "validator iterator"

Ich hoffe, ich konnte deine Frage zufriedenstellend beantworten?!

Viele Grüße 

Marcel

@marci Hallo Marcel, danke für deine Unterstützung.

Ich habe noch eine Verständigungsfrage damit ich das auch wirklich verstehe.
Kann ich deine confic einfach genau so übernehmen, ausser diesen Bereich:

# !!! Bitte den IP-Adressbereich für euren entsprechend anpassen !!!

access-control: *.*.*.*/16 allow 

Betreffend deiner Aussage zu den Upstream-Servern, kann ich die alle in der confic stehen lassen oder muss da einer oder 2i weg?

# Eine Liste an Upstream-Server die TLS-Anfragen (DoH) unterstuetzen und Anfragen verschluesseln

forward-zone:

name: "."

forward-tls-upstream: yes

forward-addr: 9.9.9.11@853#dns11.quad9.net

forward-addr: 176.9.93.198@853#dnsforge.de

forward-addr: 94.140.14.140@853#unfiltered.adguard-dns.com

Gruss Manuel

@manuel 

Hallo Manuel,

ich helfe wenn ich kann, immer gerne.

Bei Access-Control gibst du deinen privaten IP-Adressbereich ein, z.B. 192.168.178.0/16 von dem Netzwerkbereich, von dem du aus zugreifst.

Bei den Upstream-Servern gibst du die folgenden Angaben ein:

# Um EDNS (ECS) zu deaktivieren 

server:
        module-config: "validator iterator"


forward-zone:

name: "."

forward-tls-upstream: yes

forward-addr: 9.9.9.11@853#dns11.quad9.net

# Die folgenden Server sind von DNS.SB

forward-addr: 185.222.222.222@853
forward-addr: 45.11.45.11@853
forward-addr: 2a09::@853#dot.sb
forward-addr: 2a11::@853#dot.sb

Nach der Änderung der Config musst du mit dem folgenden Befehl den unbound.service neu starten

sudo systemctl restart unbound

Jetzt sollte alles richtig funktionieren.

Grüße Marcel

@marci Hallo Marcel hab das mal so eingefügt:

# Unbound-Config-Datei fuer Pi-hole

server:

module-config: "validator iterator"

chroot: ""

# Versions-Informationen von Unbound nicht anzeigen - Sicherheitsaspekt

server:

hide-identity: yes

hide-version: yes

# Wenn keine Logdatei angegeben wird, wird syslog verwendet.

logfile: " Link entfernt "

verbosity: 0

log-time-ascii: yes

log-queries: no

# Port fuer Pi-hole Custom-DNS 1 angeben:

interface: 127.0.0.1

port: 5335

do-ip4: yes

do-udp: yes

do-tcp: yes

# Kann auf ja gesetzt werden, wenn du IPv6-Konnektivität hast

do-ip6: no

# Verwende dies nur, wenn du die Liste der primären Root-Server heruntergeladen hast!

root-hints: " Link entfernt "

tls-cert-bundle: " Link entfernt "

# Vertraue dem Glue nur, wenn er innerhalb der Autorität des Servers liegt

harden-glue: yes

# Erforderliche DNSSEC-Daten für vertrauenswürdige Zonen; wenn diese Daten fehlen, wird die zu Zone BOGUS

harden-dnssec-stripped: yes

# Verwende keine Großbuchstaben-Randomisierung, da sie bekanntermaßen manchmal DNSSEC-Probleme verursacht

# Siehe Link entfernt für weitere Details

use-caps-for-id: no

# Reduziere die Größe des EDNS-Zusammensetzungspuffers.

# IP-Fragmentierung ist heute im Internet unzuverlässig und kann 

# Übertragungsfehler verursachen, wenn große DNS-Nachrichten über UDP gesendet werden. Selbst

# Wenn die Fragmentierung funktioniert, ist sie unter Umständen nicht sicher.

# Es ist theoretisch möglich, Teile einer fragmentierten DNS-Nachricht zu fälschen, ohne

# dass der Empfänger es merkt. Kürzlich gab es eine hervorragende Studie

# >>> Defragmenting DNS - Determining the optimal maximum UDP response size for DNS <<<

# von Axel Koolhaas, und Tjeerd Slokker ( Link entfernt )

# in Zusammenarbeit mit NLnet Labs untersuchten DNS anhand von realen Daten aus den

# den RIPE Atlas Probes und die Forscher schlugen unterschiedliche Werte für

# IPv4 und IPv6 und in verschiedenen Szenarien. Sie raten, dass Server so konfiguriert werden sollten

# DNS-Nachrichten, die über UDP gesendet werden, auf eine Größe zu begrenzen, die keine

# Fragmentierung auf typischen Netzwerkverbindungen auslöst. DNS-Server können

# von UDP auf TCP umschalten, wenn eine DNS-Antwort zu groß ist, um in diesen begrenzten

# Puffergröße passt. Dieser Wert wurde auch auf dem DNS Flag Day 2020 vorgeschlagen.

edns-buffer-size: 1232

# TTL-Grenzen für den Cache

cache-min-ttl: 3600

cache-max-ttl: 86400

# Prefetching von fast abgelaufenen Nachrichten-Cache-Einträgen durchführen

# Dies gilt nur für Domains, die häufig abgefragt wurden

prefetch: yes

prefetch-key: yes

# Ein Thread sollte ausreichen, auf leistungsfähigen Maschinen kann er erhöht werden.

num-threads: 1

# Anzahl der Slabs im RRset-Cache. Slabs reduzieren die Sperrkonflikte zwischen den

# Threads. Muss auf eine Potenz von 2 in der Nähe von num-threads gesetzt werden.

msg-cache-slabs: 2

rrset-cache-slabs: 2

infra-cache-slabs: 2

key-cache-slabs: 2

# Cache-Speicher rrset sollte doppelt so groß sein wie msg

msg-cache-size: 50m

rrset-cache-size: 100m

# mehr ausgehende Verbindungen

# hängt von der Anzahl der Kerne ab: 1024/Kerne - 50

outgoing-range: 450

# UDP mit Multithreading beschleunigen

so-reuseport: yes

# Sicherstellen, dass der Kernel Buffer groß genug ist, um bei Traffic-Spitzen keine Nachrichten zu verlieren 

# (wird nicht zusammen mit aktiviertem AppArmor verwendet)

# so-rcvbuf: 1m

# Sicherstellung des Datenschutzes für lokale IP-Bereiche

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

# !!! Bitte den IP-Adressbereich für euren entsprechend anpassen !!!

access-control: 192.168.1.0/24 allow 

# Eine Liste an Upstream-Server die TLS-Anfragen (DoH) unterstuetzen und Anfragen verschluesseln

forward-zone:

name: "."

forward-tls-upstream: yes

forward-addr: 9.9.9.11@853#dns11.quad9.net

# Die folgenden Server sind von DNS.SB

forward-addr: 185.222.222.222@853

forward-addr: 45.11.45.11@853

forward-addr: 2a09::@853#dot.sb

forward-addr: 2a11::@853#dot.sb

Log:

May 21 18:29:16 unbound[277105:0] info: service stopped (unbound 1.17.1).

May 21 18:29:16 unbound[277396:0] info: start of service (unbound 1.17.1).

May 21 18:41:11 unbound[277396:0] info: service stopped (unbound 1.17.1).

May 21 18:41:11 unbound[278662:0] info: start of service (unbound 1.17.1).

Funktioniert!

Besten Dank dir!

Grüsse Manuel

@manuel 

Lieber Manuel, vielen Dank für deine Wertschätzung auf Patreon! Das ist wirklich sehr, sehr nett von dir!!!

Hi Marcel, wenn ich "service cronjob restart" ausführe, bekomme ich die Meldung: "Failed to restart cronjob.service: Unit cronjob.service not found." Was muss ich hier tun?
Danke, Stephan

Hallo Stephan und Danke für deine Frage.

Was passiert denn, wenn du den folgenden Befehl eingibst?

sudo systemctl restart cron

 Beziehungsweise überprüfe mal den Status von cron mit diesem Befehl

sudo systemctl status cron

Welches OS (Version) nutzt du denn?

Gruß Marcel