SERVFAIL Probleme mit Pi-Hole + Unbound + Hyperlocal an FreshTomato WRT + NordVPN

themadlad · August 6, 2020, 10:55am

So, neues Pi-Hole inkl. Unbound (aber bislang ohne Hyperlocal) ist aufgesetzt. Hier der Vollständigkeit halber mein Vorgehen.

Vorbereitung Raspberry Pi 3B+

- Bereits in Router eingestellt: Static IP für Pi (192.168.1.5)
- Image: "2020-05-27-RASPIOS-BUSTER-LITE.ARMHF.IMG" von https://downloads.raspberrypi.org/raspios_lite_armhf/images/raspios_lite_armhf-2020-05-28/
- Auf microSD mithilfe von Raspberry Pi Imager v1.4 @ macOS
- Leere Datei "ssh" auf Volume "boot" für SSH-Zugang hinzugefügt
- microSD in Raspberry Pi 3B+ eingelegt, an Router angeschlossen, gebootet.
$ ssh-keyscan -t ed25519 192.168.1.5 >> ~/.ssh/known_hosts
$ ssh pi@192.168.1.5
$ sudo raspi-config
- Advanced Options → Expand Filesystem
- Localisation Options → Change Timezone → Europe → Berlin
- Finish, Reboot
$ ssh pi@192.168.1.5
$ sudo apt update && sudo apt upgrade
$ sudo reboot
$ ssh pi@192.168.1.5
$ passwd
- [Vergabe eines starken Passworts]
$ sudoedit /etc/sudoers.d/010_pi-nopasswd
- "NOPASSWD" -> "PASSWD", STRG+X, Y, Enter
$ sudoedit /etc/systemd/timesyncd.conf
- "#NTP" -> "NTP=213.136.94.10 80.241.218.68 78.46.223.134"

Installation Pi-Hole

$ curl -sSL https://install.pi-hole.net | bash
- Alles im Folgenden ungenannte mit "Ok"/"Yes" bestätigt
- Upstream DNS Provider: Custom -> "103.86.96.100, 103.86.99.100" (NordVPN DNS)
- Select Protocols: "IPv6" deselektiert
$ pihole -a -p
- [Vergabe eines starken Passworts]
- Browser: 192.168.1.5/admin -> Group Management -> Adlists -> Copy&Paste des Inhalts von https://v.firebog.net/hosts/lists.php?type=nocross
- Browser: 192.168.1.5/admin -> Tools -> Update Gravity -> Update -> Warten bis "Success!"
- FreshTomato Browser GUI -> Advanced -> DHCP/DNS -> Use internal DNS [Y]
- FreshTomato Browser GUI -> Advanced -> DHCP/DNS -> Intercept DNS port [Y]
- FreshTomato Browser GUI -> Advanced -> DHCP/DNS -> Dnsmasq Custom Configuration: "dhcp-option=6,192.168.1.5 # PiHole's IPv4 address"
- FreshTomato Browser GUI -> Advanced -> DHCP/DNS -> Save
- FreshTomato Browser GUI -> VPN Tunneling -> Client 1 -> Advanced -> Accept DNS configuration: "Disabled" (war: "Strict")
- FreshTomato Browser GUI -> VPN Tunneling -> Client 1 -> Advanced -> Save
- FreshTomato Browser GUI -> Reboot -> Warten auf Router-Reboot

Installation Unbound

$ sudo apt install unbound
$ wget -O root.hints https://www.internic.net/domain/named.root
$ sudo mv root.hints /var/lib/unbound/
$ sudo mkdir /var/log/unbound
$ sudo touch /var/log/unbound/unbound.log
$ sudo chown unbound /var/log/unbound/unbound.log 
$ sudoedit /etc/unbound/unbound.conf.d/pi-hole.conf
- Hier Vorlage von https://docs.pi-hole.net/guides/unbound/ eingefügt
- Änderungen: "# " vor logfile entfernt, "verbosity: 2"
$ sudo service unbound start
$ dig pi-hole.net @127.0.0.1 -p 5335
$ dig sigfail.verteiltesysteme.net @127.0.0.1 -p 5335
- Hier SERVFAIL erwartet
$ dig sigok.verteiltesysteme.net @127.0.0.1 -p 5335
- Hier NOERROR erwartet
- Pi-Hole GUI: http://192.168.1.5/admin -> Settings -> DNS -> Custom 1 (IPv4) -> 127.0.0.1#5335
- Pi-Hole GUI: http://192.168.1.5/admin -> Settings -> DNS -> Alle anderen Haken der Upstream DNS Server entfernen
- Pi-Hole GUI: http://192.168.1.5/admin -> Settings -> DNS -> Save

Quellen:

themadlad · August 6, 2020, 12:09pm

Hatte jetzt für mehrere Minuten ein Problem mit mail.XXXXX.de (aus Datenschutzgründen URL geändert). Im Log zu sehen waren Einträge wie:

Aug 06 14:05:44 unbound[1461:0] info: resolving mail.XXXXX.de. A IN
Aug 06 14:05:44 unbound[1461:0] info: resolving posteo.de. A IN
Aug 06 14:05:44 unbound[1461:0] info: response for mail.XXXXX.de. A IN
Aug 06 14:05:44 unbound[1461:0] info: reply from <de.> 77.67.63.105#53
Aug 06 14:05:44 unbound[1461:0] info: query response REC_LAME: recursive but not authoritative server
Aug 06 14:05:44 unbound[1461:0] info: mark as REC_LAME
Aug 06 14:05:44 unbound[1461:0] info: response for posteo.de. A IN
Aug 06 14:05:44 unbound[1461:0] info: reply from <de.> 81.91.164.5#53
Aug 06 14:05:44 unbound[1461:0] info: query response REC_LAME: recursive but not authoritative server
Aug 06 14:05:44 unbound[1461:0] info: mark as REC_LAME
Aug 06 14:05:44 unbound[1461:0] info: response for mail.XXXXX.de. A IN
Aug 06 14:05:44 unbound[1461:0] info: reply from <de.> 194.146.107.6#53
Aug 06 14:05:44 unbound[1461:0] info: query response REC_LAME: recursive but not authoritative server
Aug 06 14:05:44 unbound[1461:0] info: mark as REC_LAME
Aug 06 14:05:44 unbound[1461:0] info: response for posteo.de. A IN
Aug 06 14:05:44 unbound[1461:0] info: reply from <de.> 195.243.137.26#53
Aug 06 14:05:44 unbound[1461:0] info: query response REC_LAME: recursive but not authoritative server
Aug 06 14:05:44 unbound[1461:0] info: mark as REC_LAME
Aug 06 14:05:44 unbound[1461:0] info: response for mail.XXXXX.de. A IN
Aug 06 14:05:44 unbound[1461:0] info: reply from <de.> 194.0.0.53#53
Aug 06 14:05:44 unbound[1461:0] info: query response REC_LAME: recursive but not authoritative server
Aug 06 14:05:44 unbound[1461:0] info: mark as REC_LAME
Aug 06 14:05:44 unbound[1461:0] info: response for posteo.de. A IN
Aug 06 14:05:44 unbound[1461:0] info: reply from <de.> 194.246.96.1#53
Aug 06 14:05:44 unbound[1461:0] info: query response REC_LAME: recursive but not authoritative server
Aug 06 14:05:44 unbound[1461:0] info: mark as REC_LAME
Aug 06 14:05:44 unbound[1461:0] info: response for mail.XXXXX.de. A IN
Aug 06 14:05:44 unbound[1461:0] info: reply from <de.> 194.246.96.1#53
Aug 06 14:05:44 unbound[1461:0] info: query response REC_LAME: recursive but not authoritative server
Aug 06 14:05:44 unbound[1461:0] info: mark as REC_LAME
Aug 06 14:05:44 unbound[1461:0] info: response for posteo.de. A IN
Aug 06 14:05:44 unbound[1461:0] info: reply from <de.> 194.146.107.6#53
Aug 06 14:05:44 unbound[1461:0] info: query response was ANSWER
Aug 06 14:05:44 unbound[1461:0] info: response for mail.XXXXX.de. A IN
Aug 06 14:05:44 unbound[1461:0] info: reply from <de.> 77.67.63.105#53
Aug 06 14:05:44 unbound[1461:0] info: query response was ANSWER

Das Problem löste sich nach ein paar Minuten.

themadlad · August 7, 2020, 8:12pm

War heute den ganzen Tag unterwegs, komme nach Hause und begegne jeder Menge SERVFAILs. Hier z.B. die Anfragen für www.inoreader.com (mittels grep aus unbound-log extrahiert):

Aug 07 08:38:32 unbound[1461:0] info: resolving www.inoreader.com. A IN
Aug 07 08:38:32 unbound[1461:0] info: response for www.inoreader.com. A IN
Aug 07 08:38:32 unbound[1461:0] info: response for www.inoreader.com. A IN
Aug 07 08:38:32 unbound[1461:0] info: resolving www.inoreader.com. A IN
Aug 07 08:38:32 unbound[1461:0] info: resolving inoreader.com. DS IN
Aug 07 08:38:32 unbound[1461:0] info: response for inoreader.com. DS IN
Aug 07 22:03:33 unbound[1461:0] info: resolving www.inoreader.com. A IN
Aug 07 22:07:22 unbound[1461:0] info: resolving www.inoreader.com. A IN
Aug 07 22:07:45 unbound[1461:0] info: resolving www.inoreader.com. A IN
Aug 07 22:08:42 unbound[1461:0] info: resolving www.inoreader.com. A IN
Aug 07 22:09:48 unbound[1461:0] info: resolving www.inoreader.com. A IN

Wie man sehen kann war heute morgen um 08:38 Uhr die Welt noch in Ordnung, jetzt am Abend sehe ich auch bei mehreren Versuchen nur noch "resolving", aber bekomme scheinbar keine "response" mehr?

Natürlich ist der SERVFAIL auch mittels dig nachvollziehbar:

pi@raspberrypi:~ $ dig @127.0.0.1 -p 5335 www.inoreader.com

; <<>> DiG 9.11.5-P4-5.1+deb10u1-Raspbian <<>> @127.0.0.1 -p 5335 www.inoreader.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 36871
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1472
;; QUESTION SECTION:
;www.inoreader.com.		IN	A

;; Query time: 0 msec
;; SERVER: 127.0.0.1#5335(127.0.0.1)
;; WHEN: Fri Aug 07 22:13:23 CEST 2020
;; MSG SIZE  rcvd: 46

themadlad · August 7, 2020, 8:18pm

Mit der neuen Installation (ohne Hyperlocal) kommt es derzeit nicht zu derselben Flut an Log-Einträgen. Insgesamt sieht alles recht geordnet und nachvollziehbar aus, aber die vielen SERVFAILs bleiben

Bucking_Horn · August 8, 2020, 12:32pm

Ich kann immer noch keine Rekursion sehen. Für die weiterführende Analyse müsste man ja herausfinden, mit welchem DNS-Server es welche Probleme gibt.

Vielleicht werden die aber auch nur durch Dein grep versteckt. Ich bin bisher davon ausgegangen, dass Du zeitlich zusammemhängende Logauszüge zeigst. Zeilennummern per -n in grep wären nicht schlecht, um eine gefilterte Ausgabe auf einen Blick zu verdeutlichen.
Wie sieht denn das Kommando genau aus, mit dem Du Log-Auszüge erzeugt hast?

themadlad · August 8, 2020, 2:27pm

Das habe ich auch Nur im letzten Post war es mit grep. Das hat es in meinen Augen etwas anschaulicher gemacht, was sich verändert hat (nur noch resolving-Aufrufe, keine response mehr.)

Aufruf für den letzten Eintrag mit grep war:
cat /var/log/unbound/unbound.log | grep inoreader
und ansonsten eben nur
cat /var/log/unbound/unbound.log

Danke, das werde ich künftig bedenken.

Ich scheue mich etwas davor, zu viel log zu zeigen, da darin natürlich viele Elemente meiner privaten Kommunikation erkennbar sind. Hast du eine gute Idee, wie ich einen besseren Einblick ermöglichen kann?

themadlad · August 8, 2020, 2:31pm

Wo ist denn die Rekursion wie erkennbar? Vielleicht kann ich dann im log genauer danach schauen.

Bucking_Horn · August 8, 2020, 2:38pm

Das lässt sich nicht pauschal beantworten

Wir haben das vor einiger Zeit mal mit einem User hier versucht, der aber im Gegensatz zu Dir nur eine einzige Domäne beharrlich nicht auflösen konnte, letztlich ohne Lösung.

Du kannst Dir aus Hostname „vuplus-support.org“ wird nicht aufgelöst - #27 by Bucking_Horn also vielleicht ein paar Anregungen holen; die rekursive Abfrage ist da gut zu erkennen (und ein kompakteres grep auch ).

Allerdings kommen wir langsam an den Punkt, wo das mit Pi-hole selbst nicht mehr viel zu tun hat. Eventuell macht eine Anfrage an unbound mehr Sinn.
Aber zunächst schauen wir mal, ob wir die Rekursion überhaupt sehen.

EDIT:
Und vielleicht doch noch einmal der Hinweis, dass ich im Unterschied zu Dir (NordVPN) keinen VPN-Dienst verwende.
Hast Du auf Deinem Router vielleicht doch die Möglichkeit, nur Deine Pi-hole-Maschine von der VPN-Verwendung auszunehmen, um zu sehen, ob das einen Unterschied macht?

@mibere, @yubiuser: Verwendet ihr einen VPN-Service?

yubiuser · August 8, 2020, 9:14pm

Ja, gelegentlich.

Ich nutze wireguard von mobilen Clients zu meinem Router. Über den Tunnel gehen nur Pakete mit Ziel Pihole, sodass ich praktisch einen Split-Tunnel habe. Da das VPN am Router terminiert, gibt es mit de m Pihole keine Probleme, da die Pakete "scheinbar" über eth0 ankommen. Vom Pihole geht es dann zu unbound, dann raus ins Internet. Zurück den umgekehrten Weg.
SERVFAIL habe ich noch nicht beobachtet.

Bucking_Horn · August 8, 2020, 9:20pm

Dann hast Du ein anderes Szenario, das man nicht direkt vergleichen kann:
Bei Dir steht der VPN-Server in Deinem Netz, unbound löst upstream über die normale Internet-Verbindung auf.

themadlad nutzt einen VPN-Dienst, d.h. sein Router ist der transparente VPN-Client und der Server steht bei NordVPN. unbound läuft hier wie der restliche Verkehr durch den VPN-Tunnel.

themadlad · August 9, 2020, 7:43am

So wie es aussieht habe ich die Möglichkeit mithilfe von "Routing Policy" IPs oder IP-Ranges in den VPN einzuschließen. Leider konnte ich noch keine passable Möglichkeit finden, um alles durch den VPN zu leiten und dabei einzelne MAC-Adressen / IPs auszuschließen (siehe z.B. auch Diskussion hier). Wenn da jemand eine gute Idee hat... aber testweise wäre es möglich, allen Geräten in meinem Netzwerk feste IPs zu geben und dann nur diese zu tunneln.

EDIT: Habe mittlerweile umgesetzt, dass alle IPs in meinem Netzwerk static sind und alle - außer das pi-Hole - den VPN-Tunnel nutzen:

Hat jemand einen guten Vorschlag, wie ich verifizieren kann, ob mein pi-hole nun tatsächlich nicht über VPN geht? Also quasi die public IP prüfen? Die Vorschläge, die ich bisher gesehen habe waren:

curl http://ipecho.net/plain
curl ifconfig.me

Aber ich erhalte nur Connection refused als Antwort.

Und noch etwas: Im log-File meines Tomato-Routers sehe ich folgendes:

Aug  9 13:29:59 unknown daemon.warn dnsmasq[10566]: Maximum number of concurrent DNS queries reached (max: 150)
Aug  9 13:30:14 unknown daemon.warn dnsmasq[10566]: Maximum number of concurrent DNS queries reached (max: 150)
Aug  9 13:31:37 unknown daemon.warn dnsmasq[10566]: Maximum number of concurrent DNS queries reached (max: 150)
Aug  9 13:31:51 unknown daemon.warn dnsmasq[10566]: Maximum number of concurrent DNS queries reached (max: 150)
Aug  9 13:31:58 unknown daemon.warn dnsmasq[10566]: Maximum number of concurrent DNS queries reached (max: 150)
Aug  9 13:32:04 unknown daemon.warn dnsmasq[10566]: Maximum number of concurrent DNS queries reached (max: 150)
[...hier gibt es eine Reihe anderer Einträge...]
Aug  9 13:50:49 unknown daemon.warn dnsmasq[10566]: Maximum number of concurrent DNS queries reached (max: 150)
Aug  9 13:51:01 unknown daemon.warn dnsmasq[10566]: Maximum number of concurrent DNS queries reached (max: 150)
Aug  9 13:52:36 unknown daemon.warn dnsmasq[10566]: Maximum number of concurrent DNS queries reached (max: 150)
Aug  9 13:52:42 unknown daemon.warn dnsmasq[10566]: Maximum number of concurrent DNS queries reached (max: 150)
Aug  9 13:52:48 unknown daemon.warn dnsmasq[10566]: Maximum number of concurrent DNS queries reached (max: 150)
Aug  9 13:52:55 unknown daemon.warn dnsmasq[10566]: Maximum number of concurrent DNS queries reached (max: 150)
Aug  9 13:53:01 unknown daemon.warn dnsmasq[10566]: Maximum number of concurrent DNS queries reached (max: 150)
Aug  9 13:53:08 unknown daemon.warn dnsmasq[10566]: Maximum number of concurrent DNS queries reached (max: 150)
Aug  9 13:53:23 unknown daemon.warn dnsmasq[10566]: Maximum number of concurrent DNS queries reached (max: 150)
[...dann scheint das Problem erst ein mal wieder vorbei zu sein...]

Das scheint nicht unbekannt zu sein... leider in dem Fall ohne Lösung. @Bucking_Horn, du hattest vorgeschlagen, auf eine Schleife zu analysieren. Hältst du das in meinem Fall auch für eine realistische Problemursache? Und wie könnte ich eine solche finden?

Solche log-Einträge erscheinen, wie oben angedeutet, in Blocks. Das Problem besteht dann also meistens eine Zeit lang und löst sich dann wieder für eine Weile auf. Ich werde darauf nun zusätzlich ein Auge haben.

Bucking_Horn · August 9, 2020, 12:28pm

Ja, aber normalerweise sehen wird das in Pi-holes dnsmasq.
Deine Ausgabe stammt vom Router.
Verwendest Du Conditional Forwarding in Pi-hole?
Lassen sich diese Anfragen auf einen einzelnen Client zurückführen?

Und viel wichtiger:
Können Deine Clients jetzt noch DNS-Anfragen über Pi-hole auflösen?

themadlad · August 9, 2020, 12:57pm

Stimmt. Es müsste sich dabei, wenn ich es richtig verstehe, um die Anfragen vom Router (bzw. von anderen Geräten durch den Router) ans pi-hole handeln.

Nicht, dass ich wüsste - alles wurde so eingerichtet wie in der Anleitung oben beschrieben. Wie kann ich das prüfen?

Ich weiß nicht, wie ich nachverfolgen kann, welcher Client welche Anfragen stellt. Hast du eine gute Idee? Bisher ist mir keiner bekannt.

Das scheint an sich zu funktionieren.

Gerade konnte ich nicht mehr auf diese Foren-Website zugreifen.

Das unbound-log zeigte mir (grep -n -A3 "pi-hole.net" /var/log/unbound/unbound.log | tail -n 100):

1038193-Aug 09 14:47:17 unbound[644:0] info: reply from <net.> 192.26.92.30#53
1038194-Aug 09 14:47:17 unbound[644:0] info: query response REC_LAME: recursive but not authoritative server
1038195-Aug 09 14:47:17 unbound[644:0] info: mark as REC_LAME
1038196:Aug 09 14:47:17 unbound[644:0] info: response for pi-hole.net. DS IN
1038197-Aug 09 14:47:17 unbound[644:0] info: reply from <net.> 192.31.80.30#53
1038198-Aug 09 14:47:17 unbound[644:0] info: query response REC_LAME: recursive but not authoritative server
1038199-Aug 09 14:47:17 unbound[644:0] info: mark as REC_LAME
1038200:Aug 09 14:47:17 unbound[644:0] info: response for pi-hole.net. DS IN
1038201-Aug 09 14:47:17 unbound[644:0] info: reply from <net.> 192.12.94.30#53
1038202-Aug 09 14:47:17 unbound[644:0] info: query response REC_LAME: recursive but not authoritative server
1038203-Aug 09 14:47:17 unbound[644:0] info: mark as REC_LAME
1038204:Aug 09 14:47:17 unbound[644:0] info: response for pi-hole.net. DS IN
1038205-Aug 09 14:47:17 unbound[644:0] info: reply from <net.> 192.54.112.30#53
1038206-Aug 09 14:47:17 unbound[644:0] info: query response REC_LAME: recursive but not authoritative server
1038207-Aug 09 14:47:17 unbound[644:0] info: mark as REC_LAME
1038208:Aug 09 14:47:17 unbound[644:0] info: response for pi-hole.net. DS IN
1038209-Aug 09 14:47:17 unbound[644:0] info: reply from <net.> 192.31.80.30#53
1038210-Aug 09 14:47:17 unbound[644:0] info: query response REC_LAME: recursive but not authoritative server
1038211-Aug 09 14:47:17 unbound[644:0] info: mark as REC_LAME
1038212:Aug 09 14:47:17 unbound[644:0] info: response for pi-hole.net. DS IN
1038213-Aug 09 14:47:17 unbound[644:0] info: reply from <net.> 192.52.178.30#53
1038214-Aug 09 14:47:17 unbound[644:0] info: query response REC_LAME: recursive but not authoritative server
1038215-Aug 09 14:47:17 unbound[644:0] info: mark as REC_LAME
1038216:Aug 09 14:47:17 unbound[644:0] info: response for pi-hole.net. DS IN
1038217-Aug 09 14:47:17 unbound[644:0] info: reply from <net.> 192.12.94.30#53
1038218-Aug 09 14:47:17 unbound[644:0] info: query response REC_LAME: recursive but not authoritative server
1038219-Aug 09 14:47:17 unbound[644:0] info: mark as REC_LAME
1038220:Aug 09 14:47:18 unbound[644:0] info: response for pi-hole.net. DS IN
1038221-Aug 09 14:47:18 unbound[644:0] info: reply from <net.> 192.12.94.30#53
1038222-Aug 09 14:47:18 unbound[644:0] info: query response REC_LAME: recursive but not authoritative server
1038223-Aug 09 14:47:18 unbound[644:0] info: mark as REC_LAME
1038224:Aug 09 14:47:18 unbound[644:0] info: response for pi-hole.net. DS IN
1038225-Aug 09 14:47:18 unbound[644:0] info: reply from <net.> 192.31.80.30#53
1038226-Aug 09 14:47:18 unbound[644:0] info: query response REC_LAME: recursive but not authoritative server
1038227-Aug 09 14:47:18 unbound[644:0] info: mark as REC_LAME
1038228:Aug 09 14:47:18 unbound[644:0] info: response for pi-hole.net. DS IN
1038229-Aug 09 14:47:18 unbound[644:0] info: reply from <net.> 192.26.92.30#53
1038230-Aug 09 14:47:18 unbound[644:0] info: query response REC_LAME: recursive but not authoritative server
1038231-Aug 09 14:47:18 unbound[644:0] info: mark as REC_LAME
1038232:Aug 09 14:47:18 unbound[644:0] info: response for pi-hole.net. DS IN
1038233-Aug 09 14:47:18 unbound[644:0] info: reply from <net.> 192.31.80.30#53
1038234-Aug 09 14:47:18 unbound[644:0] info: query response REC_LAME: recursive but not authoritative server
1038235-Aug 09 14:47:18 unbound[644:0] info: mark as REC_LAME
1038236:Aug 09 14:47:18 unbound[644:0] info: response for pi-hole.net. DS IN
1038237-Aug 09 14:47:18 unbound[644:0] info: reply from <net.> 192.52.178.30#53
1038238-Aug 09 14:47:18 unbound[644:0] info: query response REC_LAME: recursive but not authoritative server
1038239-Aug 09 14:47:18 unbound[644:0] info: mark as REC_LAME
1038240:Aug 09 14:47:18 unbound[644:0] info: response for pi-hole.net. DS IN
1038241-Aug 09 14:47:18 unbound[644:0] info: reply from <net.> 192.54.112.30#53
1038242-Aug 09 14:47:18 unbound[644:0] info: query response REC_LAME: recursive but not authoritative server
1038243-Aug 09 14:47:18 unbound[644:0] info: mark as REC_LAME
1038244:Aug 09 14:47:18 unbound[644:0] info: response for pi-hole.net. DS IN
1038245-Aug 09 14:47:18 unbound[644:0] info: reply from <net.> 192.35.51.30#53
1038246-Aug 09 14:47:18 unbound[644:0] info: query response REC_LAME: recursive but not authoritative server
1038247-Aug 09 14:47:18 unbound[644:0] info: mark as REC_LAME
1038248:Aug 09 14:47:18 unbound[644:0] info: response for pi-hole.net. DS IN
1038249-Aug 09 14:47:18 unbound[644:0] info: reply from <net.> 192.35.51.30#53
1038250-Aug 09 14:47:18 unbound[644:0] info: query response REC_LAME: recursive but not authoritative server
1038251-Aug 09 14:47:18 unbound[644:0] info: mark as REC_LAME
1038252:Aug 09 14:47:18 unbound[644:0] info: response for pi-hole.net. DS IN
1038253-Aug 09 14:47:18 unbound[644:0] info: reply from <net.> 192.41.162.30#53
1038254-Aug 09 14:47:18 unbound[644:0] info: query response REC_LAME: recursive but not authoritative server
1038255-Aug 09 14:47:18 unbound[644:0] info: mark as REC_LAME
1038256:Aug 09 14:47:18 unbound[644:0] info: response for pi-hole.net. DS IN
1038257-Aug 09 14:47:18 unbound[644:0] info: reply from <net.> 192.35.51.30#53
1038258-Aug 09 14:47:18 unbound[644:0] info: query response REC_LAME: recursive but not authoritative server
1038259-Aug 09 14:47:18 unbound[644:0] info: mark as REC_LAME
1038260:Aug 09 14:47:18 unbound[644:0] info: response for pi-hole.net. DS IN
1038261-Aug 09 14:47:18 unbound[644:0] info: reply from <net.> 192.54.112.30#53
1038262-Aug 09 14:47:18 unbound[644:0] info: query response REC_LAME: recursive but not authoritative server
1038263-Aug 09 14:47:18 unbound[644:0] info: mark as REC_LAME
1038264:Aug 09 14:47:18 unbound[644:0] info: response for pi-hole.net. DS IN
1038265-Aug 09 14:47:18 unbound[644:0] info: reply from <net.> 192.35.51.30#53
1038266-Aug 09 14:47:18 unbound[644:0] info: query response REC_LAME: recursive but not authoritative server
1038267-Aug 09 14:47:18 unbound[644:0] info: mark as REC_LAME
1038268:Aug 09 14:47:18 unbound[644:0] info: response for pi-hole.net. DS IN
1038269-Aug 09 14:47:18 unbound[644:0] info: reply from <net.> 192.35.51.30#53
1038270-Aug 09 14:47:18 unbound[644:0] info: query response REC_LAME: recursive but not authoritative server
1038271-Aug 09 14:47:18 unbound[644:0] info: mark as REC_LAME
1038272:Aug 09 14:47:18 unbound[644:0] info: response for pi-hole.net. DS IN
1038273-Aug 09 14:47:18 unbound[644:0] info: reply from <net.> 192.41.162.30#53
1038274-Aug 09 14:47:18 unbound[644:0] info: query response REC_LAME: recursive but not authoritative server
1038275-Aug 09 14:47:18 unbound[644:0] info: mark as REC_LAME
1038276:Aug 09 14:47:18 unbound[644:0] info: response for pi-hole.net. DS IN
1038277-Aug 09 14:47:18 unbound[644:0] info: reply from <net.> 192.26.92.30#53
1038278-Aug 09 14:47:18 unbound[644:0] info: query response REC_LAME: recursive but not authoritative server
1038279-Aug 09 14:47:18 unbound[644:0] info: mark as REC_LAME
1038280:Aug 09 14:47:18 unbound[644:0] info: response for pi-hole.net. DS IN
1038281-Aug 09 14:47:18 unbound[644:0] info: reply from <net.> 192.41.162.30#53
1038282-Aug 09 14:47:18 unbound[644:0] info: query response REC_LAME: recursive but not authoritative server
1038283-Aug 09 14:47:18 unbound[644:0] info: mark as REC_LAME
1038284:Aug 09 14:47:19 unbound[644:0] info: response for pi-hole.net. DS IN
1038285-Aug 09 14:47:19 unbound[644:0] info: reply from <net.> 192.41.162.30#53
1038286-Aug 09 14:47:19 unbound[644:0] info: query response REC_LAME: recursive but not authoritative server
1038287-Aug 09 14:47:19 unbound[644:0] info: mark as REC_LAME
--
1038289:Aug 09 14:47:19 unbound[644:0] info: Could not establish a chain of trust to keys for pi-hole.net. DNSKEY IN
1038290-Aug 09 14:47:27 unbound[644:0] info: resolving www.apple.com. A IN
1038291-Aug 09 14:47:27 unbound[644:0] info: resolving www.apple.com. A IN
1038292-Aug 09 14:47:27 unbound[644:0] info: resolving www.apple.com. A IN

Mein Tomato-Router zeigte:

Aug  9 14:40:12 unknown daemon.warn dnsmasq[1210]: Maximum number of concurrent DNS queries reached (max: 150)
Aug  9 14:40:29 unknown daemon.warn dnsmasq[1210]: Maximum number of concurrent DNS queries reached (max: 150)
Aug  9 14:40:35 unknown daemon.warn dnsmasq[1210]: Maximum number of concurrent DNS queries reached (max: 150)
Aug  9 14:42:01 unknown daemon.warn dnsmasq[1210]: Maximum number of concurrent DNS queries reached (max: 150)
Aug  9 14:42:15 unknown daemon.warn dnsmasq[1210]: Maximum number of concurrent DNS queries reached (max: 150)
Aug  9 14:42:27 unknown daemon.warn dnsmasq[1210]: Maximum number of concurrent DNS queries reached (max: 150)
Aug  9 14:43:56 unknown daemon.warn dnsmasq[1210]: Maximum number of concurrent DNS queries reached (max: 150)
Aug  9 14:44:11 unknown daemon.warn dnsmasq[1210]: Maximum number of concurrent DNS queries reached (max: 150)
Aug  9 14:44:22 unknown daemon.warn dnsmasq[1210]: Maximum number of concurrent DNS queries reached (max: 150)
Aug  9 14:44:58 unknown daemon.info dnsmasq-dhcp[1210]: DHCPREQUEST(br0) 192.168.1.28 70:70:0d:75:6a:65 
Aug  9 14:44:58 unknown daemon.info dnsmasq-dhcp[1210]: DHCPNAK(br0) 192.168.1.28 70:70:0d:75:6a:65 static lease available
Aug  9 14:44:58 unknown daemon.info dnsmasq-dhcp[1210]: DHCPREQUEST(br0) 192.168.1.28 70:70:0d:75:6a:65 
Aug  9 14:44:58 unknown daemon.info dnsmasq-dhcp[1210]: DHCPNAK(br0) 192.168.1.28 70:70:0d:75:6a:65 static lease available
Aug  9 14:44:58 unknown daemon.info dnsmasq-dhcp[1210]: DHCPDISCOVER(br0) 70:70:0d:75:6a:65 
Aug  9 14:44:58 unknown daemon.info dnsmasq-dhcp[1210]: DHCPOFFER(br0) 192.168.1.22 70:70:0d:75:6a:65 
Aug  9 14:44:59 unknown daemon.info dnsmasq-dhcp[1210]: DHCPREQUEST(br0) 192.168.1.22 70:70:0d:75:6a:65 
Aug  9 14:44:59 unknown daemon.info dnsmasq-dhcp[1210]: DHCPACK(br0) 192.168.1.22 70:70:0d:75:6a:65 XXXX
Aug  9 14:45:10 unknown daemon.warn dnsmasq[1210]: Maximum number of concurrent DNS queries reached (max: 150)
Aug  9 14:45:22 unknown daemon.warn dnsmasq[1210]: Maximum number of concurrent DNS queries reached (max: 150)
Aug  9 14:45:29 unknown daemon.warn dnsmasq[1210]: Maximum number of concurrent DNS queries reached (max: 150)
Aug  9 14:45:36 unknown daemon.warn dnsmasq[1210]: Maximum number of concurrent DNS queries reached (max: 150)
Aug  9 14:45:45 unknown daemon.warn dnsmasq[1210]: Maximum number of concurrent DNS queries reached (max: 150)
Aug  9 14:45:53 unknown daemon.warn dnsmasq[1210]: Maximum number of concurrent DNS queries reached (max: 150)
Aug  9 14:45:59 unknown daemon.warn dnsmasq[1210]: Maximum number of concurrent DNS queries reached (max: 150)
Aug  9 14:46:05 unknown daemon.warn dnsmasq[1210]: Maximum number of concurrent DNS queries reached (max: 150)
Aug  9 14:46:11 unknown daemon.warn dnsmasq[1210]: Maximum number of concurrent DNS queries reached (max: 150)
Aug  9 14:46:17 unknown daemon.warn dnsmasq[1210]: Maximum number of concurrent DNS queries reached (max: 150)
Aug  9 14:46:23 unknown daemon.warn dnsmasq[1210]: Maximum number of concurrent DNS queries reached (max: 150)
Aug  9 14:46:29 unknown daemon.warn dnsmasq[1210]: Maximum number of concurrent DNS queries reached (max: 150)
Aug  9 14:46:47 unknown daemon.warn dnsmasq[1210]: Maximum number of concurrent DNS queries reached (max: 150)
Aug  9 14:46:53 unknown daemon.warn dnsmasq[1210]: Maximum number of concurrent DNS queries reached (max: 150)
Aug  9 14:47:45 unknown daemon.warn dnsmasq[1210]: Maximum number of concurrent DNS queries reached (max: 150)
Aug  9 14:47:59 unknown daemon.warn dnsmasq[1210]: Maximum number of concurrent DNS queries reached (max: 150)
Aug  9 14:48:14 unknown daemon.warn dnsmasq[1210]: Maximum number of concurrent DNS queries reached (max: 150)
Aug  9 14:48:33 unknown daemon.info dnsmasq-dhcp[1210]: DHCPDISCOVER(br0) cc:3a:61:49:8c:a1 
Aug  9 14:48:33 unknown daemon.info dnsmasq-dhcp[1210]: DHCPOFFER(br0) 192.168.1.21 cc:3a:61:49:8c:a1 
Aug  9 14:48:33 unknown daemon.info dnsmasq-dhcp[1210]: DHCPREQUEST(br0) 192.168.1.21 cc:3a:61:49:8c:a1 
Aug  9 14:48:33 unknown daemon.info dnsmasq-dhcp[1210]: DHCPACK(br0) 192.168.1.21 cc:3a:61:49:8c:a1 XXXX

Nach etwa 10 Minuten hatte sich das Problem wieder gelöst.

EDIT 1: Was sich allerdings nicht gelöst hat ist die Anfrage nach einem universitätsnahen Mail-Frontend (hier ersetzt durch 'secret-mailgui'):

--
1020993:Aug 09 14:41:29 unbound[644:0] info: resolving mail.secret-mailgui.de. A IN
1020994:Aug 09 14:41:29 unbound[644:0] info: response for mail.secret-mailgui.de. A IN
1020995:Aug 09 14:41:29 unbound[644:0] info: reply from <secret-mailgui.de.> 129.143.2.10#53
1020996-Aug 09 14:41:29 unbound[644:0] info: query response was LAME
1020997:Aug 09 14:41:30 unbound[644:0] info: response for mail.secret-mailgui.de. A IN
1020998:Aug 09 14:41:30 unbound[644:0] info: reply from <secret-mailgui.de.> 193.196.199.1#53
1020999-Aug 09 14:41:30 unbound[644:0] info: query response was LAME
1021000:Aug 09 14:41:30 unbound[644:0] info: response for mail.secret-mailgui.de. A IN
1021001:Aug 09 14:41:30 unbound[644:0] info: reply from <secret-mailgui.de.> 129.143.253.133#53
1021002-Aug 09 14:41:30 unbound[644:0] info: query response was LAME
1021003-Aug 09 14:41:30 unbound[644:0] info: response for whatsapp.net. DS IN
1021004-Aug 09 14:41:30 unbound[644:0] info: reply from <net.> 192.35.51.30#53
--
1025674:Aug 09 14:43:09 unbound[644:0] info: resolving mail.secret-mailgui.de. A IN
1025675-Aug 09 14:43:15 unbound[644:0] info: resolving discourse-cdn.pi-hole.net. A IN
1025676-Aug 09 14:43:15 unbound[644:0] info: resolving discourse-cdn.pi-hole.net. A IN
1025677-Aug 09 14:43:15 unbound[644:0] info: response for discourse-cdn.pi-hole.net. A IN
--
1029103:Aug 09 14:44:49 unbound[644:0] info: resolving mail.secret-mailgui.de. A IN
1029104-Aug 09 14:44:51 unbound[644:0] info: resolving login.live.com. A IN
1029105-Aug 09 14:44:51 unbound[644:0] info: resolving ns3-34.azure-dns.org. A IN
1029106-Aug 09 14:44:51 unbound[644:0] info: resolving ns4-34.azure-dns.info. A IN
--
1034525:Aug 09 14:46:02 unbound[644:0] info: resolving mail.secret-mailgui.de. A IN
1034526-Aug 09 14:46:03 unbound[644:0] info: response for whatsapp.net. DS IN
1034527-Aug 09 14:46:03 unbound[644:0] info: reply from <net.> 192.35.51.30#53
1034528-Aug 09 14:46:03 unbound[644:0] info: query response REC_LAME: recursive but not authoritative server
--
1040248:Aug 09 14:48:00 unbound[644:0] info: resolving mail.secret-mailgui.de. A IN
1040249-Aug 09 14:48:00 unbound[644:0] info: response for edgekey.net. DS IN
1040250-Aug 09 14:48:00 unbound[644:0] info: reply from <net.> 192.12.94.30#53
1040251-Aug 09 14:48:00 unbound[644:0] info: query response REC_LAME: recursive but not authoritative server
--
1042785:Aug 09 14:48:59 unbound[644:0] info: resolving mail.secret-mailgui.de. A IN
1042786-Aug 09 14:48:59 unbound[644:0] info: response for mozaws.net. DS IN
1042787-Aug 09 14:48:59 unbound[644:0] info: reply from <net.> 192.41.162.30#53
1042788-Aug 09 14:48:59 unbound[644:0] info: query response REC_LAME: recursive but not authoritative server
--
1043689:Aug 09 14:49:21 unbound[644:0] info: resolving mail.secret-mailgui.de. A IN
1043690-Aug 09 14:49:21 unbound[644:0] info: response for pi-hole.net. DS IN
1043691-Aug 09 14:49:21 unbound[644:0] info: reply from <net.> 192.48.79.30#53
1043692-Aug 09 14:49:21 unbound[644:0] info: query response REC_LAME: recursive but not authoritative server
--
1044158:Aug 09 14:51:01 unbound[644:0] info: resolving mail.secret-mailgui.de. A IN
1044159-Aug 09 14:51:15 unbound[644:0] info: resolving autopush.prod.mozaws.net. A IN
1044160-Aug 09 14:51:15 unbound[644:0] info: response for autopush.prod.mozaws.net. A IN
1044161-Aug 09 14:51:15 unbound[644:0] info: reply from <prod.mozaws.net.> 205.251.194.102#53
--
1044961:Aug 09 14:59:09 unbound[644:0] info: resolving mail.secret-mailgui.de. A IN
1044962:Aug 09 14:59:09 unbound[644:0] info: response for mail.secret-mailgui.de. A IN
1044963:Aug 09 14:59:09 unbound[644:0] info: reply from <secret-mailgui.de.> 193.196.199.1#53
1044964-Aug 09 14:59:09 unbound[644:0] info: query response was LAME
1044965:Aug 09 14:59:09 unbound[644:0] info: response for mail.secret-mailgui.de. A IN
1044966:Aug 09 14:59:09 unbound[644:0] info: reply from <secret-mailgui.de.> 129.143.2.10#53
1044967-Aug 09 14:59:09 unbound[644:0] info: query response was LAME
1044968:Aug 09 14:59:09 unbound[644:0] info: response for mail.secret-mailgui.de. A IN
1044969:Aug 09 14:59:09 unbound[644:0] info: reply from <secret-mailgui.de.> 129.143.253.133#53
1044970-Aug 09 14:59:09 unbound[644:0] info: query response was LAME
1044971-Aug 09 14:59:25 unbound[644:0] info: resolving api.jdownloader.org. AAAA IN
1044972-Aug 09 14:59:25 unbound[644:0] info: response for api.jdownloader.org. AAAA IN

EDIT 2: Nach einem reboot des pi war das Problem wieder weg.
EDIT 3: Nach anderthalb Stunden besteht das Problem wieder, mit demselben Host.

mibere · August 9, 2020, 4:36pm

Dann komm ich noch mit einem Versuch um die Ecke...

Erweitere die unbound-Konfigurationsdatei um diese Einträge

server:
  outgoing-range: 8192
  num-queries-per-thread: 4096
  so-reuseport: yes

sudo nano /etc/security/limits.conf, diese vier Zeilen hinzufügen

root    soft    nofile  100000
root    hard    nofile  100000
*       soft    nofile  25000
*       hard    nofile  25000

sudo nano /etc/sysctl.conf, und dies hinzufügen

fs.file-max = 524288
net.core.rmem_default = 2097152
net.core.rmem_max = 2097152
net.core.wmem_default = 2097152
net.core.wmem_max = 2097152
net.core.somaxconn = 256
net.core.optmem_max = 32768
net.core.netdev_max_backlog = 1024

sudo sysctl -p

sudo shutdown -r now

themadlad · August 9, 2020, 7:22pm

Und weiterhin das pi-hole aus der VPN-Verbindung ausnehmen? Das Mail-Frontend mag momentan echt relativ durchgehend nicht...

Ich setze das schonmal so um, danke für den Vorschlag. Auch wenn ich kaum verstehe, was da geschieht :>

Bucking_Horn · August 10, 2020, 7:56am

Wenn Du mit der VPN-Ausnahme für Pi-hole immer noch SERVFAILs in dem (für Dich) üblichen Umfang gesehen hast, können wir den NordVPN-Dienst als möglichen Faktor ausschliessen.

themadlad · August 11, 2020, 12:37pm

Ja, das hat leider nicht geholfen. Tatsächlich scheine ich jetzt mehr REC_LAME und INSECURE Antworten zu erhalten... ich mache das daher wieder rückgängig und schließe das pi-hole wieder ein bzw. erweitere den VPN-Dienst auf alle Geräte.

themadlad · August 11, 2020, 12:38pm

Leider sehe ich auch hier keine Verbesserung der Problematik. Wieder rückgängig machen oder noch einmal etwas verändern?

mibere · August 11, 2020, 12:46pm

Überlasse ich dir Ich verwende genau diese Einstellungen auf meinem System.

themadlad · March 4, 2021, 2:29pm

Kurzes Update, falls jemand ähnliche Probleme hat: Nach Umstieg auf einen besseren Router (vorher: ASUS RT-N16 mit TomatoWRT - jetzt: ASUS RT-AC86U mit MerlinWRT) sind die Probleme nicht mehr vorhanden. Das Pi-Hole ist nach wie vor dasselbe. Durch die unterschiedliche Konfiguration kann ich jedoch nicht ausschließen, dass es mehr an der Konfiguration der Geräte, als an den Geräten selbst liegt.