Unbound zu PiHole installiert, wichtige Dienste nicht erreichbar

Avenger84

Lt. Commander
Registriert
Feb. 2008
Beiträge
1.740
Hallo,
ich betreibe seit Jahren PiHole Zuhause mit Cloudflare als DNS, DNSSEC seit etwa 1 Jahr aktiviert.

Vorgestern habe ich zusätzlich Unbound installiert, weil ich die Idee irgendwie gut fand direkt bei der "Wurzel" nachzufragen, ohne Anbieter dazwischen (wie z.B. Cloudflare).

Meine Config dazu sah so aus:

Code:
server:
    interface: 127.0.0.1
    interface: ::1
    port: 5335
    do-ip4: yes
    do-ip6: yes
    do-udp: yes
    do-tcp: yes
    prefer-ip6: yes
    access-control: 127.0.0.0/8 allow
    access-control: ::1 allow
    root-hints: "/var/lib/unbound/root.hints"
    val-clean-additional: yes
    harden-dnssec-stripped: yes
    # Cache-Poisoning-Härtung
    harden-referral-path: yes
    harden-below-nxdomain: yes
    harden-glue: yes
    qname-minimisation: yes
    qname-minimisation-strict: yes
    unwanted-reply-threshold: 10000
    verbosity: 1
    # Performance: Cache-Optimierung
    # cache-min-ttl: 3600
    cache-max-ttl: 86400
    msg-cache-size: 50m
    rrset-cache-size: 100m
    num-threads: 2
    # Prefetching: Häufig genutzte Domains werden aktiv erneuert
    prefetch: yes
    prefetch-key: yes
    # EDNS und UDP Buffer optimieren
    edns-buffer-size: 1232
    so-rcvbuf: 1m
    so-sndbuf: 1m
    # Sicherheit
    hide-identity: yes
    hide-version: yes
    identity: "localhost"
    version: "not disclosed"
    private-address: 10.0.0.0/8
    private-address: 172.16.0.0/12
    private-address: 192.168.0.0/16
    private-address: 169.254.0.0/16
    private-address: 192.0.2.0/24
    private-address: 198.51.100.0/24
    private-address: 203.0.113.0/24
    private-address: 255.255.255.255/32
    private-address: fd00::/8
    private-address: fe80::/10
    private-address: 2001:db8::/32

Funktionierte auch erst mal, allerdings geht damit am TV kein Amazon Prime Video mehr und am PC lässt sich Battlefield 6 nicht mehr verbinden.
Angeblich ist DNSSEC lokal in Unbound strenger und das wäre eventuell der Grund.
Außerdem ist die DNS Auflösung teilweise merklich langsamer, auch nicht so doll und man kann meine DNS Abfrage, da unverschlüsselt auf dem Weg zum Root DNS Server (theoretisch) immer noch einsehen.

Habe dann die zweite für mich interessante Version ausprobiert: Cloudflare über TLS:
Code:
server:
    interface: 127.0.0.1
    interface: ::1
    port: 5335
    do-ip4: yes
    do-ip6: yes
    do-udp: yes
    do-tcp: yes
    prefer-ip6: yes
    access-control: 127.0.0.0/8 allow
    access-control: ::1 allow
    tls-cert-bundle: "/etc/ssl/certs/ca-certificates.crt"
    verbosity: 1
    hide-identity: yes
    hide-version: yes
    identity: "localhost"
    version: "not disclosed"
    private-address: 10.0.0.0/8
    private-address: 172.16.0.0/12
    private-address: 192.168.0.0/16
    private-address: 169.254.0.0/16
    private-address: 192.0.2.0/24
    private-address: 198.51.100.0/24
    private-address: 203.0.113.0/24
    private-address: 255.255.255.255/32
    private-address: fd00::/8
    private-address: fe80::/10
    private-address: 2001:db8::/32
    msg-cache-size: 50m
    rrset-cache-size: 100m
    num-threads: 2
    edns-buffer-size: 1232
    so-rcvbuf: 1m
    so-sndbuf: 1m
    prefetch-key: yes
forward-zone:
    name: "."
    forward-tls-upstream: yes
    forward-addr: 1.1.1.1@853#cloudflare-dns.com
    forward-addr: 1.0.0.1@853#cloudflare-dns.com
    forward-addr: 2606:4700:4700::1111@853#cloudflare-dns.com
    forward-addr: 2606:4700:4700::1001@853#cloudflare-dns.com

Damit funktioniert Amazon Prime Video und BF6 wieder ;)

Was sagt ihr zu der Konfig ?
Sehr ihr vielleicht warum in Teil 1 die beiden Dienste nicht mehr erreichbar sind ?
Welche Konfig nutzt ihr ?

Da ich selber einen Web & Mailserver Zuhause betreibe mit 24h Zwangstrennung, steht mein DNS auf 60s (TTL) - daher möchte ich z.B. keine 60min min. Cache, daher auskommentiert:
Code:
# cache-min-ttl: 3600
.
Ich möchte ja meine eigene Homepage nicht nicht erreichen 🙃
 
Avenger84 schrieb:
Außerdem ist die DNS Auflösung teilweise merklich langsamer, auch nicht so doll und man kann meine DNS Abfrage, da unverschlüsselt auf dem Weg zum Root DNS Server (theoretisch) immer noch einsehen.
Da stellt sich dann die Frage, ob du mit der Nutzung von Unbound wirklich irgendwelche Vorteile gewinnst.
 
Avenger84 schrieb:
Sehr ihr vielleicht warum in Teil 1 die beiden Dienste nicht mehr erreichbar sind ?

Ja.

qname-minimisation-strict: yes

Deshalb. Mit Strict QNAME Minimisation ist das halbe Internet kaputt. Wie du ja gemerkt hast. Ausschalten.

Steht auch genau so in der Doku.

qname-minimisation-strict: <yes or no>

QNAME minimisation in strict mode. Do not fall-back to sending full QNAME to potentially broken nameservers. A lot of domains will not be resolvable when this option in enabled. Only use if you know what you are doing. This option only has effect when qname-minimisation is enabled.

Default: no

https://unbound.docs.nlnetlabs.nl/e...f.html#unbound-conf-qname-minimisation-strict
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: mchawk777 und Avenger84
Avenger84 schrieb:
man kann meine DNS Abfrage, da unverschlüsselt auf dem Weg zum Root DNS Server (theoretisch) immer noch einsehen.
Spielt überhaupt keine Rolle, da bei der ClientHello Nachricht vom TLS-Handshake sowieso der Hostnamen immer unverschlüsselt übertragen wird. Dadurch kann man immer sehen welche Webseite aufgerufen wird, trotz TLS Verschlüsselung.

Avenger84 schrieb:
Außerdem ist die DNS Auflösung teilweise merklich langsamer
Das liegt eigentlich meist immer am DNS Cache.
 
Helge01 schrieb:
Spielt überhaupt keine Rolle, da bei der ClientHello Nachricht vom TLS-Handshake sowieso der Hostnamen immer unverschlüsselt übertragen wird. Dadurch kann man immer sehen welche Webseite aufgerufen wird, trotz TLS Verschlüsselung.

Wer ist denn "man"? der ISP? Der kann auch mittels Deep Packet Inspection sehen, wohin sich der Browser verbindet. Die Resolver auf dem rekursiven Weg nach unten sehen nur den Teil, den sie kennen müssen dank QNAME Minimisation (nicht strict).

Avenger84 schrieb:
Außerdem ist die DNS Auflösung teilweise merklich langsamer,

Du hast ja auch noch keinen Cache. Der muss sich erst mal füllen. Wenn du Unbound neu startest, geht der auch verloren. Daher lieber mit unbound-control reload_keep_cache die Config neu laden.

Also den Cache groß genug einstellen, Prefetch aktivieren (hast du) und einfach laufen lassen. Nach einer Weile wird das meiste aus dem Cache beantwortet und oft angefragte Namen bleiben hot im Cache.

Meine Unbound Statistiken zeigen, wie ein ordentlich laufender und cachender Resolver arbeitet:

Code:
Recursive replies:    33369
Cache misses:    33406
Cache hits:    897947
Serve expired:    17
Prefetch:    5083
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Avenger84
CoMo schrieb:
Nicht nur der sondern alle die ihre Netzwerkkomponenten dazwischen haben. Beim unverschlüsselten DNS ist es ja auch nicht anders, da sieht nur noch zusätzlich zum Provider der DNS Anbieter alles.

CoMo schrieb:
Der kann auch mittels Deep Packet Inspection sehen, wohin sich der Browser verbindet
Dieser Aufwand ist in dem Fall gar nicht notwendig da alles unverschlüsselt.
 
Helge01 schrieb:
Nicht nur der sondern alle die ihre Netzwerkkomponenten dazwischen haben.

Jop, die Backbone-Router unterwegs, die Milliarden Pakete pro Sekunde verarbeiten. Da macht sich sicher jemand die Mühe und den finanziellen Aufwand, deine DNS-Requests rauszufiltern. Um dann was damit zu machen?

Bei einem DoH-Anbieter landet alles zentral an einer Stelle. Das sollte man sich gut überlegen, ob man das will.

Helge01 schrieb:
Dieser Aufwand ist in dem Fall gar nicht notwendig da alles unverschlüsselt.

Also kannst du in Pakete schauen, ohne sie zu öffnen? Interessant.
 
CoMo schrieb:
Also kannst du in Pakete schauen, ohne sie zu öffnen? Interessant.
Was ist denn da der Unterschied zum unverschlüsselten DNS? Richtig keiner. Wird DNS verschlüsselt dann sieht dein Provider das gleiche wie wenn er deinen unverschlüsselten DNS Netzwerkverkehr überwacht. Es gibt in der Handhabe überhaupt keinen Unterschied, nur das es andere Ports betrifft.

Beim unverschlüsselten DNS überwacht er Port 53, wird DNS verschlüsselt dann eben Port 443, da dort der Hostname eben auch unverschlüsselt ist. Es gibt beim überwachen überhaupt keinen Unterschied.

Übrigens mache ich das bei mir schon immer, um Statistiken erstellen zu können.

Sinn macht verschlüsseltes DNS erst wenn es verschlüsseltes SNI (ESNI) gibt. Ursprünglich sollte das ja mit TLS Protokoll 1.3 kommen, wurde aber verworfen.
 
Zuletzt bearbeitet:
Falex163 schrieb:
Also lohnt sich unbound nicht?
Warum nicht? Ich nutze selbst meinen eigenen DNS-Resolver.

Durch den nicht immer aktuellen Cache kann die Auflösung manchmal etwas länger dauern wie bei einem großen DNS-Anbieter, stört mich aber nicht.
 
Sykehouse schrieb:
Da stellt sich dann die Frage, ob du mit der Nutzung von Unbound wirklich irgendwelche Vorteile gewinnst.
Naja, das Thema "Websperren via DNS" ist mit so was vollkommen außen vor.
Halt interessant, wenn man nicht 1.1.1.1 oder 8.8.8.8 nutzen will.
Azghul0815 schrieb:
Die Abfrage ist deshalb deutlich langsamer, da unbound jedes mal den kompletten Weg gehen muss, während Cloudflare und co. einen riesigen DNS Cache haben.
Nope. Die erste Anfrage einer Domäne könnte(!) etwas langsamer stattfinden, da der DNS-Cache noch nicht aufgebaut wurde. Sobald der aber da ist, läuft es sogar schneller.
 
  • Gefällt mir
Reaktionen: Helge01
Azghul0815 schrieb:
Ich hab 2 Unbound Server. 1x auf nem Proxmox und 1x auf ner NAS.
Nutz beide aktuell nicht, weil mir das auflösen zu lange dauert,
Azghul0815 schrieb:
Ich hab regelmäßig über Adguard und unbound 400ms plus gehabt, mit quad9 und co im 1 bis unteren stelligen Bereich.

Das ist aber ein lokales Config-Problem bei dir. Kannst du ja in einem separaten Thread analysieren lassen. In der Diskussion hier hilft das nicht weiter.
 
  • Gefällt mir
Reaktionen: Azghul0815
@CoMo weißt du warum er bei mir den Cache löscht wenn ich "sudo unbound-control reload_keep_cache" ausführe?

Habe qname-minimisation-strict nun rausgelassen und es läuft.

wenn ich in der .conf das Loglevel anpasse und dann unbound-control reload_keep_cache danach ausführe, ist der Cache weg.

Code:
control cmd:  reload_keep_cache
info: service stopped (unbound 1.19.2).
info: server stats for thread 0: 82 queries, 0 answers from cache, 82 recursions, 0 prefetch, 0 rejected by ip ratelimiting
info: server stats for thread 0: requestlist max 43 avg 5.26829 exceeded 0 jostled 0
info: mesh has 0 recursion states (0 with reply, 0 detached), 0 waiting replies, 82 recursion replies sent, 0 replies dropped, 0 states jostled out
info: average recursion processing time 0.061843 sec
 
Manche Config-Änderungen erfordern einen Restart. Dann geht auch der Cache verloren.

Man kann den Cache aber in eine Datei schreiben und wiederherstellen:


Code:
unbound-control dump_cache > dns-cache.txt
unbound-control load_cache < dns-cache.txt

Hab ich früher händisch gemacht; auf meiner OPNSense hab ich jetzt aber ein Script, das beim Shutdown den Cache sichert, damit ich ihn danach händisch wiederherstellen kann. Ging mir auf die Nerven, dass der immer weg war, wenn die OPNSense wegen Updates neu starten musste 😝


Code:
root@OPNsense:~ # cat unbound-cache.sh
#!/bin/sh
# Script to save or restore the Unbound DNS cache on OPNsense
# Usage: ./unbound-cache.sh save|load

UNBOUND_CTL="/usr/local/sbin/unbound-control"
UNBOUND_CONF="/var/unbound/unbound.conf"
CACHE_FILE="/root/dns-cache.txt"

case "$1" in
  save)
    echo "[*] Saving Unbound cache to $CACHE_FILE..."
    $UNBOUND_CTL -c "$UNBOUND_CONF" dump_cache > "$CACHE_FILE"
    echo "[+] Cache saved."
    ;;
  load)
    echo "[*] Loading Unbound cache from $CACHE_FILE..."
    if [ -f "$CACHE_FILE" ]; then
      $UNBOUND_CTL -c "$UNBOUND_CONF" load_cache < "$CACHE_FILE"
      echo "[+] Cache loaded."
    else
      echo "[!] Cache file not found: $CACHE_FILE"
      exit 1
    fi
    ;;
  *)
    echo "Usage: $0 save|load"
    exit 1
    ;;
esac

Code:
root@OPNsense:~ # cat /usr/local/etc/rc.syshook.d/stop/95-save-unbound-cache
#!/bin/sh

/root/unbound-cache.sh save
Ergänzung ()

Avenger84 schrieb:
Da ich selber einen Web & Mailserver Zuhause betreibe mit 24h Zwangstrennung, steht mein DNS auf 60s (TTL) - daher möchte ich z.B. keine 60min min. Cache, daher auskommentiert: # cache-min-ttl: 3600.
Ich möchte ja meine eigene Homepage nicht nicht erreichen 🙃

Würde ich nicht so machen. Damit schaltest du das ja global ab.

Du kannst den Eintrag händisch aus dem Cache löschen:

Code:
unbound-control flush_zone domain.dyndns.org

Oder per Systemd-Timer automatisch alle 10 Minuten oder nen Knopf mit OliveTin bauen oder wie auch immer. Werde kreativ 😅
Ergänzung ()

Falex163 schrieb:
Habe pihole mit unbound und hyperlocal und bin sehr zufrieden mit der geschwindigkeit.

Ja, wenn du All-In mit Unbound gehen willst, kannst du dir auch gleich noch die ganze Root-Zone lokal vorhalten https://datatracker.ietf.org/doc/rfc8806/
Code:
B.4.  Example Configuration: Unbound 1.9

   Recent versions of Unbound have an "auth-zone" feature that allows
   local mirroring of the root zone.  Configuration looks as follows:

   auth-zone:
       name: "."
       master: "b.root-servers.net"
       master: "c.root-servers.net"
       master: "d.root-servers.net"
       master: "f.root-servers.net"
       master: "g.root-servers.net"
       master: "k.root-servers.net"
           fallback-enabled: yes
       for-downstream: no
       for-upstream: yes
       zonefile: "root.zone"

Mache ich noch überall da, wo ich den Unbound händisch verwalte, also überall, wo ein Thin Client mit AdGuard rumsteht, z.B bei meiner Mama. Hier bei mir aber nicht mehr, seit ich den Unbound auf meinem OPNSense Router nutze. Kann man aber auch abwägen, wie sinnvoll das überhaupt ist:

https://www.heise.de/news/Hyperlocal-Wenn-die-DNS-Root-Zone-zu-Hause-steht-4215364.html
https://labs.apnic.net/index.php/2019/04/23/expanding-the-dns-root-hyperlocal-vs-nsec-caching/
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Avenger84
Wie updatest du die root-hints?

ich lasse folgenden Dienst jeden So um 3Uhr laufen:
Code:
[Unit]
Description=Update Unbound Root Hints
After=network-online.target
Wants=network-online.target

[Service]
Type=oneshot
ExecStart=/bin/bash -c '\
    set -euo pipefail; \
    WD=/var/lib/unbound; \
    URL=https://www.internic.net/domain/named.root; \
    TMP=$(mktemp); \
    HTTP_CODE=$(/usr/bin/curl -sS -w "%{http_code}" -z "$WD/root.hints" -o "$TMP" "$URL"); \
    if [ "$HTTP_CODE" = "304" ]; then \
        rm -f "$TMP"; \
        echo "Root hints unchanged (304 Not Modified) — no restart"; \
        exit 0; \
    elif [ "$HTTP_CODE" = "200" ]; then \
        mv -f "$TMP" "$WD/root.hints"; \
        echo "Root hints updated (200 OK) — restarting unbound"; \
        systemctl restart unbound; \
        exit 0; \
    else \
        echo "Root hints update failed — HTTP $HTTP_CODE"; \
        rm -f "$TMP"; \
        exit 2; \
    fi'

[Install]
WantedBy=multi-user.target
der ersetzt die "named.root" nur wenn sie geändert wurde und startet Unbound neu.
Wenn nicht: tue nichts.

P.S.
wenn du All-In mit Unbound gehen willst, kannst du dir auch gleich noch die ganze Root-Zone lokal vorhalten
hab i net verstande
 
Zuletzt bearbeitet:
andere Frage: wenn Unbound etwas länger läuft, dann geht der Load Average meiner VM von 0,0x auf
CPU Ø 1min:
1.05
CPU Ø 5min:
1.13
CPU Ø 15min:
1.22

hoch.
Liegt angeblich an der Berechnung für DNSSEC und weil meine VM nur
Code:
cat /proc/sys/kernel/random/entropy_avail
256
eine Entropie von 256 hat.

Ist das bei euch auch so?
 
Avenger84 schrieb:
Wie updatest du die root-hints?

Überhaupt nicht. Die root.hints kommt bundled mit dem Unbound Paket. Da braucht man nix händisch zu aktualisieren. So oft ändert sich da auch nix.

Avenger84 schrieb:
eine Entropie von 256 hat.

256 ist normal, seit diesen Changes ist das nur noch ein Dummy Wert. Das sieht auf jedem System so aus.

Avenger84 schrieb:
hoch.
Liegt angeblich an der Berechnung für DNSSEC

Keine Ahnung. Was stört dich an der Load? Solange der Dienst einwandfrei läuft, würde ich nicht versuchen, etwas zu reparieren, das nicht kaputt ist.
 
  • Gefällt mir
Reaktionen: Azghul0815
Zurück
Oben