Pihole-Unbound - kein DNSSEC

Betriebssysteme
1

Guten Tag,

Ausgangslage:
Ich habe jetzt Pihole-Unbound nach der letzten Anleitung von Tschaeggaer installiert und dafür hier https://raspi.debian.net/tested-images/
das aktuelle Bullseye-Image für den Pi 3b+ herunter geladen.
Ich wollte es zunächst mit dem OS durchführen, für das das Skript geschrieben war und später erst auf das aktuellere Bookworm wechseln.
Die Einrichtung gelang problemlos nach dem Skript.
Tolles Turotial!
IPv6 ist in der Fritzbox nicht aktiviert. Mit dessen Einrichtung muss ich mich noch näher beschäftigen.
Ansonsten wurde derDNS-Server exakt nach den Vorgaben des Skripts an beiden Stellen in der Fritzboxoberfläche eingetragen.

Das Problem:
Bei Eingabe der Testcommands zeigt sich, dass offensichtlich DNSSEC nicht(!) aktiviert ist,es fehlt das ad Flag und die Angabe Noerror beim 3. Command.
Nachfolgend die Protokollierung wobei bei Eingabe der Commands häufiger
2 Aufrufe für die letzen beiden Adressen notwendig waren, da zunächst der Server als nicht erreichbar gemeldet wurde:

root@rpi3-20230102:~# dig kuketz-blog.de @127.0.0.1 -p 5335 +short
46.38.242.112
; <<>> DiG 9.16.33-Debian <<>> sigfail.verteiltesysteme.net @127.0.0.1 -p 5335
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 36437
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;sigfail.verteiltesysteme.net. IN A
;; Query time: 3016 msec
;; SERVER: 127.0.0.1#5335(127.0.0.1)
;; WHEN: Fri Jan 13 10:26:32 CET 2023
;; MSG SIZE rcvd: 57

root@rpi3-20230102:~# dig sigok.verteiltesysteme.net @127.0.0.1 -p 5335
; <<>> DiG 9.16.33-Debian <<>> sigok.verteiltesysteme.net @127.0.0.1 -p 5335
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 21368
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;sigok.verteiltesysteme.net. IN A
;; Query time: 2036 msec
;; SERVER: 127.0.0.1#5335(127.0.0.1)
;; WHEN: Fri Jan 13 10:27:10 CET 2023
;; MSG SIZE rcvd: 55

„unbound-checkconf“ liefert NoErrors.

Ich habe recherchiert bzw. bin nochmal das Skript durchgegangen,
finde aber keine Erklärung für die Ursache,dass DNSSEC nicht funktioniert.
Kann mir bitte jemand weiter helfen?
Oder soll ich ggf.noch weitere Protokolle posten?
Ggf.welche bzw. mit welchem(n) Command(s)?

2

Wenn ich sigok.verteiltesystem.net oder sigfail.verteiltesystem.net „anpinge“ kommt aktuell eine Fehlermeldung. Demzufolge kann der dig sigok.verteiltesysteme.net auch kein ad-flag bzw NOERROR bringen.
Bitte gib mal dig kuketz-blog.de @127.0.0.1 -p 5335 ein (ohne +short), dann wirst Du sicherlich auch das ad-flag und NOERROR sehen. Gleiches dann mal mit dig mailbox.org @127.0.0.1 -p 5335. Sollte auch funktionieren.

3

Ah super. Vielen Dank matar!
Ja, das ist so wie du schreibst. Bei diesen beiden Aufrufen, die du angibst, ist alles ok.
Also war/ist es ein Fehler von sigok/sigfail.verteilsysteme.net? Allerdings hatte ich ja keine eigentliche Fehlermeldung bekommen.
Ist also damit alles „sicher geklärt“? Gibt es es sozusagen einen „Gegencheck“ auf anderem Wege, etwa auf einer Webseite? Mal interessehalber gefragt.
Oder ist der Aufruf anderer Server im Terminal eben genau das?

4

Also, ich bin sicherlich keine Spezialist zu diesem Thema, habe hier aber auch Pi-hole und Unbound laufen. Allerdings in 2 separaten Debian-VM´s auf einer Synology NAS.
Nach meinem Verständnis zeigt der positive „Gegencheck“ mit mailbox.org und kuketz-blog.de, dass deine Server korrekt installiert sind. Abgesehen davon zeigt eine schnelle Internetsuche nach „sigfail.verteiltesystem.net“ auch, dass es immer wieder mal Probleme mit der Erreichbarkeit dieser Domain gibt.
Vielleicht noch ein Hinweis: Solltest Du in Pi-hole unter Settings jetzt DNSSEC einschalten OHNE das der Pi-hole auch als DNS-Server betrieben wird bekommst Du fast nur irritierende Fehlermeldungen im Query-Log des Pi-hole. Mein Rat hierzu: Entweder den Pi-hole als DNS-Server nutzen oder DNSSEC ausgeschaltet lassen.

1 „Gefällt mir“
5

Ja, an „sigfail.verteiltesysteme.net“ erkennt man es nicht, da dort absichtlich die DNSSEC Signatur falsch ist, und bei korrekt funktionierender DNSSEC Implementierung dort „SERVFAIL“ als Status zurückgegeben werden muss.
Bei „sigok.verteiltesysteme.net“ sollte jedoch kein „SERVFAIL“ auftreten, auch nicht wenn DNSSEC nicht aktiv ist. Wenn das dort passiert ist höchstwahrscheinlich etwas Serverseitig bei denen verkehrt, sofern nur die Anleitung befolgt wurde.

An sich möglich wäre es aber auch, dass die Signaturen nicht verifiziert werden können (Möglichkeiten die mir schnell einfallen: aufgrund von beschädigten/veralteten „Root Trust Anchors“ aus dem Paket „dns-root-data“). Das lässt sich aber ausschließen, wenn es bei anderen Domains klappt, und ist eher unwahrscheinlich.

„status: SERVFAIL“ ist die eigentliche Fehlermeldung. Unbound kann die gewünschte Antwort (den A record von sigok.verteiltesysteme.net) nicht an dig ausliefern.
Der Grund in diesen Fall lässt sich vermutlich, bei aktivem Logging mit entsprechendem Level, in den Logdateien von Unbound finden. Das DNS Protokoll ist in der Hinsicht, aus meiner Sicht, nicht so „detailliert“, dass man klare Fehlermeldungen als anfragender Client erhält.

Sofern du bei einer Domain mit DNSSEC, bspw. mailbox.org, dismail.de, oder tutanota.com, ein AD Flag erhältst, sollte alles passen.
Ich wüsste auch nicht, unter welchen (Konfigurations-)Umständen Unbound ein AD Flag zurückgeben, aber eine falsche Signatur nicht zu einen „SERVFAIL“ führen sollte. Das wäre aus meiner Sicht ein ernsthaftes Problem mit der Software selbst, und nichts, um das du dich selbst kümmern könntest und müssen solltest.

6

Ganz herzlichen Dank an matar und D299!!
Eure ausführlichen und kompetenten Hinweise haben mir sehr weiter geholfen.
Super!

7

Hallo,
vorab: Ich betreibe nun schon seit mehr als drei Jahren erfolgreich den Pi.hole in meinem Netzwerk und bin äusserst zufrieden damit. Ehrlicherweise traue ich mich nicht wirklich die bestehende konfiguration zu verändern. Leider ergeben sich mir dennoch Zweifel an der Korrektheit habe mehrfach die Situation ergoogelt, bin aber weiterhin sehr unsicher, ob meine Gedanken hier richtig sind. Daher schonmal sorry und Danke für die Unterstützung bei der Klarstellung nachfolgender Punkte:

  1. Unbound ersetzt kein DNSSEC?
  2. Wie bringe ich Pihole mit Unbound und einer DNSSEC Konfiguration in Einklang? Ja, ich weiß es gibt etliche Wege aber welcher ist der stabilste und empfehlenswerteste Weg? Ich habe pihole hier auf einem Linux Mint ystem und kleinem Minirechner am laufen.
  3. Im Pi.hole habe ich unter „Upstream DNS Servers“: folgendes eingetragen: 127.0.0.1#5335
  4. Der EIntrag „Use DNSSEC“ ist nicht gesetzt
  5. In der FRitzbox steht unter DNS-Server die IP Adresse des Pi.hole
  6. Weiterhin habe ich in der Fritzbox die DNS over TLS (DoT) Funktion „Verschlüsselte Namensauflösung im Internet (DNS over TLS)“ aktiv
  7. Weiterhin habe ich in der Fritzbox unter „Auflösungsnamen der zu verwendenden DNS-Server“ folgende Adressen eingetragen:

pi.hole.fritz.box
unicast.uncensoreddns.org
anycast.uncensoreddns.org
security-filter-dns.cleanbrowsing.org

  1. Im Fritzbox Online Monitor sehe ich das die IP ADresse: 185.228.168.9 (aktuell genutzt für Standardanfragen - DoT verschlüsselt) genutzt wird. Die IP ADresse 185.228.168.9 enstpricht der Vorgabe einer der vorgeschlagenen DNS Adressen „anycast.uncensoreddns.org“

  2. Sind die vorgenannten Punkte 6 und 7 in Verbindug mit Pi.hole und Unbound überhaupt nützlich?

  3. Was mich nun wundert ist, wenn ich aus meinem heimischen Netzwerk die URL: dnsleaktest.com aufrufe und den Test durchführe, erscheint die von meinem Providser bereitgestellte dynamische IP4 Adresse. Ist das korrekt?

  4. Weiterhin wundert mich das, wenn ich die URL: browserleaks.com/dns aufrufe, 2 DNS Server angezeigt werden. In dem Fall die dynamische IP IP4 und IP6-ADresse wie unter Punkt 9. Ist das korrekt?

Würde mich auf ein paar Feedbacks freuen!
SouthernGerman

8

Im pihole-Tutroial aus dem alten Forum schreibt bummelstein:

[F] Ein Online-DNS-Test sagt mir nach Einrichtung, ich würde einen DNS-Server meines Internet-Anbieters nutzen!?
[F] Der Test gibt den Hostnamen .dip0.t-ipconnect.de, .dyn.telefonica.de etc. oder meine eigene IP-Adresse aus, ist das korrekt?
[A] Wenn man die IP-Adresse des Tests unter die Lupe nimmt, ergibt sich die Antwort. Schaut bspw. bei nsupdate.info nach der eigenen IP-Adresse. Ist das dieselbe? Wahrscheinlich schon. Und welcher DNS-Server soll benutzt werden? Genau: Unser Unbound, welches hinter unserem Router an unserem Anschluss arbeitet und daher auch unsere IP-Adresse hat. Alles super also! Der o. g. Hostname ist nur eine Kennung, die der Provider dem eigenen Anschluss zuweist.
Hinweis: Ich habe schon erlebt, dass www.nsupdate.info in Blocklisten vorkam und so durch Pi-hole blockiert wurde. Dann muss man diese Domain vorher per Webinterface in die Allowlist (Erlaubliste) aufnehmen.

Auf die anderen Fragen habe ich leider keine Antwort.

9

Wie sieht dein Netzwerk aus? Wo ist Fritte, Pi-Hole, Endgerät? Welchen DNS Server benutzt das Endgerät?

Im Zweifelsfall mal Paketdump machen mit Wireshark oder so. Fritte kann das iirc auch.
Und dann gucken wenn man DNS Auflösung testet wo die Pakete (wie) hingehen.

Der Link unter Punkt 10 sieht so aus als würde da wirklich nur die eigene IP angezeigt. Bei 11 zeigt es sowohl die eigene IP als auch verwendete DNS Server.

10

Punkt 1:
Unbound validiert selbst DNSSEC-Signaturen, wenn diese für eine Domain vorhanden sind, wenn es so konfiguriert ist.
Unter Debian ist das Standardmäßig der Fall - in der Konfiguration muss dafür folgende Option konfiguriert sein:
auto-trust-anchor-file: "/var/lib/unbound/root.key"
Auf Debian ist das in der Datei /etc/unbound/unbound.conf.d/root-auto-trust-anchor-file.conf der Fall, diese wird bei der Installation angelegt, und auch im Tutorial nicht angefasst, müsste also bei dir vorhanden sein. Die selbe Option muss nicht in deiner eigenen Konfigurationsdatei sein.

Punkt 2-4:
Irrelevant, siehe oben. Unbound validiert DNSSEC Signaturen, also muss Pi-Hole das nicht tun, da der Verkehr zwischen den beiden über das Loopback-Interface (127.0.0.1) läuft.

Punkt 5-9:
In der Fritzbox kannst du mit der „DNS-Server“ Einstellung unter „Zugangsdaten“ festlegen, welche DNS-Resolver von der Fritzbox verwendet werden. Punkt 1 dieses Artikels.

Die Fritzbox teilt Geräten über die Heimnetz Netzwerkeinstellungen einen DNS-Resolver per DHCP mit, das ist standardmäßig die Fritzbox selbst (welche Anfragen nur weiterleitet und das Ergebnis zwischenspeichert), vermutlich hast du dies aber aufgrund der Anleitung auf den Pi-Hole umgestellt. Das ist Punkt 2 des oben verlinkten Artikels.

Deswegen verwenden deine Geräte, bei Punkt 10 & 11, den Pi-Hole mit Unbound zur Auflösung der DNS Anfragen. Dabei wird die Domain durch Unbound direkt bei den zuständigen Nameservern aufgelöst, und somit erhalten diese deine IP-Adressen, bzw. auch die IPv6-Adresse vom Gerät auf dem Unbound läuft.
(Das ist mit eine Erklärung für Punkt 10 & 11, die Ergebnisse sollen also so sein, wenn du Unbound nutzen möchtest)

Deine Fritzbox aber zeigt an, dass „anycast.uncensoreddns.org“ von Ihr als DoT-Server verwendet wird, darum sendet diese Ihre, und DNS-Anfragen die an Ihre Heimnetz-IP-Adresse gerichtet sind, an eben diesen. DoT hat nämlich vorrang vor den „normalen“ DNS-Resolvern, die du bei den Zugangseinstellungen eingetragen hast.
(Die IP-Adressen für die DoT-Server werden übrigens bei deiner Konfiguration über deinen Pi-Hole aufgelöst, da die Domains für diese über die da drüber eingetragenen DNS-Resolver aufgelöst werden)

Eigentlich sind diese DoT-Server Eintragungen also nutzlos, ja. Deine Geräte verwenden alle, außer deine Fritzbox, deinen eigenen DNS-Resolver (Unbound, mit Pi-Hole welches die Anfragen zuerst filtert). Und deine Fritzbox selbst erhält, wenn deine Geräte korrekt funktionieren, keine Anfragen, die sie an die DoT-Server weiterleitet, verwendet aber selbst für Ihre eigenen DNS-Anfragen, sollte sie je welche senden, die DoT-Server (und ansonsten, wenn die Fallback Option aktiv ist und die Server nicht erreichbar, oder die Domains für die DoT-Server noch nicht aufgelöst wurden, deinen Pi-Hole mit Unbound).

Edit: Zu Punkt 7: Bietet dein Pi-Hole überhaupt DoT an? Ich glaube nicht, daher wird auch nicht pi.hole.fritz.box aus dieser Auflistung verwendet werden. Ich weiß auch nicht, ob die Fritzbox an dieser Stelle die „.fritz.box“ Domains auflösen würde.

11

Vielen Dank allen hier meiner zahlreichen Fragen antwortenten Community Mitglieder. Ich habe Eure Ratschläge jetzt mal soweit befolgt und die Änderungen in Fritzbox durchgeführt. Weiterhin habe ich mir mal noch ein paar unbound Konfigurationsvorschläge z.B. von hier angeschaut und hier und da noch ein paar Parameter übernommen. Vor allem den Punkt " Unbound Performance Tuning and Tweak" fand ich da u.a. interessant. Jedenfalls läuft seither alles gewohnt noch einen Tick flüssiger. Bin erst mal happy.
Vielen Dank

12

Inzwischen ist FritzOS 7.57 installiert. Ich verwende im internen Netz bind (9.18), als forwarder verwende ich die Fritzbox. Dort sind 2 DNS eingetragen: 5.9.164.112 und 185.95.218.42 (DigitalCourage e.V. und Digitalen Gesellschaft), beide DNSSEC.

Ein nslookup aus dem internen Netz bringt:

$ dig www.kuketz.de <IP des internen bind>

; <<>> DiG 9.18.16-1-Debian <<>> www.kuketz.de <IP interner DNS>
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 20091
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 619d605beb0145130100000064fd8dcff3bd88fb16003fac (good)
;; QUESTION SECTION:
;www.kuketz.de.                 IN      A

;; Query time: 347 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Sun Sep 10 11:35:11 CEST 2023
;; MSG SIZE  rcvd: 70

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 15691
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 619d605beb0145130100000064fd8dcff3bd88fb16003fac (good)
;; QUESTION SECTION:
;192.168.146.166.               IN      A

;; Query time: 3 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Sun Sep 10 11:35:11 CEST 2023
;; MSG SIZE  rcvd: 72

Also von AVM wirklich nicht behoben. Ich kontaktiere die auch nicht mehr, da man dann in der anscheinend unvermeidlichen Schleife „schicken Sie uns Diagnosedaten“ landet.

Ich habe mal explizit

resolver-query-timeout 20000

angegeben. Damit scheint es bisher zu funktionieren. Zu lange soll ein echter fail ja auch nicht dauern.
Ich beobachte das dann mal.

EDIT: Hat nichts gebracht.