Hilfe bei Unbound Config - Servfail bei allen Domains

Hallo zusammen.
Ich habe mir auf meinem Heimserver pihole mit unbound installiert und stolpere über ein paar Probleme, die ich alleine irgendwie nicht gelöst bekomme. Ich hoffe hier kann mir jemand helfen.

Ich nutze einen Proxmox Container mit Debian 10 Buster. Installiert ist Unbound Version 1.9.0 und Pi-hole Version v4.4 Web Interface Version v4.3.3 FTL Version v4.3.1.

Ich habe mich bei der Konfiguration von Unbound an die PiHole Doku gehalten, jedoch nach und nach Sachen auskommentiert um mein Problem einzugrenzen.

Ein dig nach google.de einmal an Unbound und einmal nach Cloudflare. Wie zu sehen löst Cloudflare auf und Localhost mit Unbound auf 5353 gibt keine Antwort.
root@pihole:/etc/unbound# dig @127.0.0.1 -p 5353 google.de

; <<>> DiG 9.11.5-P4-5.1-Debian <<>> @127.0.0.1 -p 5353 google.de
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 35716
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1472
;; QUESTION SECTION:
;google.de.			IN	A

;; Query time: 0 msec
;; SERVER: 127.0.0.1#5353(127.0.0.1)
;; WHEN: Sun Apr 19 13:34:09 UTC 2020
;; MSG SIZE  rcvd: 38

root@pihole:/etc/unbound# dig @1.1.1.1 google.de

; <<>> DiG 9.11.5-P4-5.1-Debian <<>> @1.1.1.1 google.de
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19727
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1452
;; QUESTION SECTION:
;google.de.			IN	A

;; ANSWER SECTION:
google.de.		257	IN	A	216.58.207.163

;; Query time: 33 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Sun Apr 19 13:34:22 UTC 2020
;; MSG SIZE  rcvd: 63

Meine unbound.conf sieht im Moment so aus:

server:
    interface: 127.0.0.1
    port: 5353

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

    do-ip4: yes
    do-ip6: yes
    prefer-ip6: no

    do-udp: yes
    do-tcp: yes

    #root-hints: "/var/lib/unbound/root.hints"
    #auto-trust-anchor-file: "/var/lib/unbound/root.key"
    #harden-glue: yes

    #harden-dnssec-stripped: no
    prefetch: yes
    #use-caps-for-id: no

    #hide-identity: yes
    #hide-version: yes
    #minimal-responses: yes
    #qname-minimisation: yes

    # Reduce EDNS reassembly buffer size.
    # Suggested by the unbound man page to reduce fragmentation reassembly problems
    edns-buffer-size: 1472

    num-threads: 2
    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

    tls-cert-bundle: /etc/ssl/certs/ca-certificates.crt

forward-zone:
  name: "."
  forward-tls-upstream: yes
  # Cloudflare DNS
  forward-addr: 2606:4700:4700::1111@853#cloudflare-dns.com
  forward-addr: 1.1.1.1@853#cloudflare-dns.com
  forward-addr: 2606:4700:4700::1001@853#cloudflare-dns.com
  forward-addr: 1.0.0.1@853#cloudflare-dns.com
  # Quad9 Primary & Secondary DNS Server (Beispiel)
  forward-addr: 9.9.9.9@853#dns.quad9.net

Wie könnte ich bei der weiteren Fehlersuche vorgehen? Warum bekomme ich ein Servfail bei egal welcher Domain, die ich mit dig auflösen möchte? Ich bin dankbar für jeden Tipp.

Viele Grüße

The Pi-hole guide does not configure unbound as a forwarding resolver, but your configuration shows this has been done. Please revert to the settings shown in the Pi-hole guide and then we can troubleshoot from there.

https://docs.pi-hole.net/guides/unbound/

Hi,
jfb du hast recht. Später wäre es mein bevorzugtes Verhalten, unbound als forwarding resolver mit cache zu nutzen.

Für das Erste habe ich es mal auskommentiert. Es scheint prinzipiell zu funktionieren, jedoch nicht immer. Wenn ich mehrere querys hintereinander starte, bekomme ich manchmal eine Antwort und manchmal auch nicht.

root@pihole:/etc/unbound# dig @127.0.0.1 -p 5353 google.de

; <<>> DiG 9.11.5-P4-5.1-Debian <<>> @127.0.0.1 -p 5353 google.de
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38547
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1472
;; QUESTION SECTION:
;google.de.			IN	A

;; ANSWER SECTION:
google.de.		300	IN	A	172.217.20.227

;; Query time: 319 msec
;; SERVER: 127.0.0.1#5353(127.0.0.1)
;; WHEN: Sun Apr 19 15:11:30 UTC 2020
;; MSG SIZE  rcvd: 54

root@pihole:/etc/unbound# dig @127.0.0.1 -p 5353 google.de

; <<>> DiG 9.11.5-P4-5.1-Debian <<>> @127.0.0.1 -p 5353 google.de
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 20084
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1472
;; QUESTION SECTION:
;google.de.			IN	A

;; Query time: 0 msec
;; SERVER: 127.0.0.1#5353(127.0.0.1)
;; WHEN: Sun Apr 19 15:11:32 UTC 2020
;; MSG SIZE  rcvd: 38

Wie man an diesem Beispiel sieht. Der erste geht durch und liefert eine Antwort. 2 Sekunden später die gleiche Anfrage mit Fehler. Grob geschätzt sind es 80 % der Anfragen bei denen ich ein Servfail bekomme.

In which configuration do you see these errors? With unbound as a forwarder, or unbound as a recursive resolver, or both?

Just as resolver.

root@pihole:/etc/unbound# cat unbound.conf
server:
    interface: 127.0.0.1
    port: 5353

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

    do-ip4: yes
    do-ip6: yes
    prefer-ip6: no

    do-udp: yes
    do-tcp: yes

    root-hints: "/var/lib/unbound/root.hints"
    auto-trust-anchor-file: "/var/lib/unbound/root.key"
    harden-glue: yes

    harden-dnssec-stripped: yes
    prefetch: yes
    #use-caps-for-id: no

    #hide-identity: yes
    #hide-version: yes
    #minimal-responses: yes
    qname-minimisation: yes

    # Reduce EDNS reassembly buffer size.
    # Suggested by the unbound man page to reduce fragmentation reassembly problems
    edns-buffer-size: 1472

    num-threads: 2
    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

    #tls-cert-bundle: /etc/ssl/certs/ca-certificates.crt

#forward-zone:
#  name: "."
#  forward-tls-upstream: yes
#  # Cloudflare DNS
#  forward-addr: 2606:4700:4700::1111@853#cloudflare-dns.com
#  forward-addr: 1.1.1.1@853#cloudflare-dns.com
#  forward-addr: 2606:4700:4700::1001@853#cloudflare-dns.com
#  forward-addr: 1.0.0.1@853#cloudflare-dns.com
#  # Quad9 Primary & Secondary DNS Server (Beispiel)
#  forward-addr: 9.9.9.9@853#dns.quad9.net

I would increase the unbound verbosity to 5 and then look at the log output to see where the problem may lie.

Thank you jfb.

My impression is, that at those occurrences where I do not get an answer, there is nothing written to the log, even with log level / verbosity set to 5.

I put the logoutput on pastebin, because it was larger, than the allowed maximum body size per post.

/etc/unbound/unbound.conf.d/pi-hole.conf
num-threads: 1

lt. Redirecting...

bei dir steht 2

wenn num-threads: 2 dann
diese Einträge gleich drunter einfügen
outgoing-range: 465
num-queries-per-thread: 256

hat bei mir geholfen

1 Like

Danke für den Hinweis. Das habe ich direkt nochmal überprüft.

Ich habe jetzt zur Sicherheit num-threads auch nochmal auf 1 gesetzt und somit 1:1 die config von Redirecting....

Leider bekomme ich trotz alledem immer wieder solche Sachen:

root@pihole:/etc/unbound# dig @127.0.0.1 -p 5353 google.de





; <<>> DiG 9.11.5-P4-5.1-Debian <<>> @127.0.0.1 -p 5353 google.de
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached

Das, abwechselnd mit servfail und hin und wieder auch eine korrekte Antwort. An der Config kann es demnach wohl nicht liegen, oder? Und ja, ich starte unbound nach jeder Config Änderung neu.

Ich verstehe es einfach nicht :frowning:

Hm, ich merke jedoch auch, das dieses unregelmäßige Verhalten häufiger mit dig nach google.de auftaucht. Wenn ich pi-hole.net oder andere "kleine" Seiten abfrage, dann werden diese mit hoher Trefferrate konstant aus dem Cache beantwortet.

Mein Problem beschränkt sich somit wohl erstmal auf große Seiten mit vielen IPs. ?

dig @127.0.0.1 -p 5335 google.de

warum port 5353 ?

was hast du bei Upstream DNS Servers eingestellt?
es sollte nur DNS 127.0.0.1#5335 as the Custom DNS (IPv4) eingestellt sein

Weil das der Port von Unbound ist.

aber nicht lt. der Anleitung ...
bitte beachte auch meinen Hinweis auf den eingestellten Upstream DNS Servers

also ich habs gerade bei mir getestet, bekomme den gleichen Fehler wie du, wenn ich den falschen Port wähle...

bitte den port richtig einstellen in der config und auch im PiHole ... dann gehts auch bei dir

Irgendwie bekomme ich das mit dem Zitieren nicht hin in discourse. Naja ...

Mit Verweis auf die Anleitung:

interface: 127.0.0.1
port: 5335

Steht in den ersten paar Zeilen.

Den Hinweis über die eingestellten Upstream DNS Server habe ich beachtet. Ich denke das habe ich richtig gemacht.

du hast den Port im PiHole noch immer falsch.
Im Upstream steht der Port 5353 bei dir!

1 Like

Mir ist der Zahlendreher gerade aufgefallen :see_no_evil:
Riesiges Danke, ich glaube das wars. Ich Berichte nochmal, falls das Problem nochmal auftritt. Drück mir die Daumen :slight_smile:

tja, bin ja froh dass es bei dir nun auch geht...
ich hatte auch schon den gleichen Fehler ... kommt daher dass es auch Anleitungen im Netz gibt welche den Port 5353 haben....

ist mir auch schon mal passiert

schönen Abend noch

1 Like

Danke. Dir auch noch einen schönen Abend.

Darf ich vielleicht noch kurz was fragen?
Ich habe manche Anleitungen im Netz gesehen, die den DNS Cache von PiHole auf 0 setzen um alle Anfragen an Unbound weiterzuleiten.

Ist diese Empfehlung noch aktuell? Oder ruhig beides Cachen lassen?

@Amari ich habe den Cache vom Pi-Hole auch auf 0 gesetzt.

für was sind diese Eintragungen gut?