Best Practice: AdGuard Home & unbound als DNS-Server

[MerlinM]

@ plang.pl
Der Tipp wurde vor zwei Monaten von jemanden auf Reddit gepostet. Mich würde mal interessieren, ob das bei anderen ebenfalls etwas bewirkt oder nicht.

Mal eine kurze Nachfrage zu deiner guten Anleitung. Du schreibst unter Schritt 11: Arbeitsweisen des unbound, dass DNS-over-TLS (DoT) die Variante wäre, die wir jetzt konfiguriert haben.

In deiner unbound.conf im Projektordner, müssten dann doch die Einträge unter "auth-zone" deaktiviert und die Einträge unter "forward-zone" aktiviert werden, wenn man DNS-over-TLS nutzen möchte. Hier ist es aber umgekehrt, was für den Hyperlocal-Mode sprechen würde. Oder habe ich einen Denkfehler?

 

[plang.pl]

Da hast du recht.
In der aktuellen unbound.conf in dem Projekt.zip steht folgender Passus:

# Upstream DNS
#Nur einer der folgenden beiden Blöcke darf aktiv (nicht auskommentiert) sein!
## Hyperlocal Mode
##Direktes Befragen der Root-DNS-Server ohne Notwendigkeit irgendeines 3rd Party DNS. Unverschlüsselt Port 53 UDP
    #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
    #url: https://www.internic.net/domain/root.zone
    #zonefile: "/opt/unbound/etc/unbound/auth-zone/root.zone"
## DoT (DNS-over-TLS)
##Befragen über verschlüsseltes DNS (Port 853 TCP)
    forward-zone:
    name: "."
    forward-tls-upstream: yes
    # SecureDNS.eu
    #forward-addr: 146.185.167.43@853#dot.securedns.eu
    #forward-addr: 2a03:b0c0:0:1010:e9a:3001@853#dot.securedns.eu
    # Quad9
    forward-addr: 9.9.9.9@853#dns.quad9.net
    forward-addr: 149.112.112.112@853#dns.quad9.net
    forward-addr: 2620:fe::fe@853#dns.quad9.net
    forward-addr: 2620:fe::9@853#dns.quad9.net

Eventuell hast du noch eine alte Projekt.zip
Habe die Anleitung erst vor Kurzem diesbezüglich aktualisiert

 

[update-freak]

Mal etwas zum Thema UDP Buffer Size des AdGuard Containers. Obwohl ich die Speichererhöhung nach Anleitung durchgeführt habe, tauchte die Fehlermeldung im Log des AdGuard Container trotzdem immer wieder mal auf.

Der Fehler wird bei Samsung Handys von der Funktion "Verdächtige Netzwerke erkennen" ausgelöst. Deaktiviert man diese Funktion, taucht der UDP Buffer Fehler nicht mehr auf. Man findet die Funktion unter Einstellungen/Verbindungen/WLAN und dann oben rechts auf die drei Punkte klicken und Intelligent Wi-Fi auswählen (Samsung Galaxy S25 Ultra).

Ging mir genauso, dass nach der Erhöhung noch immer die Fehlermeldung im log zu finden war.
Habe nun bei meinem Samsung Smartphone + Tablet die Einstellung deaktiviert.
Werde es jetzt beobachten und berichten ob ich den Fehler nochmal sehe

 

[update-freak]

@MerlinM Also bei mir hat die Anpassung ("Verdächtige Netzwerke erkennen" -> deaktiviert) wohl tatsächlich die Fehlermeldung beseitigt. Habe sie seit dem nicht mehr gesehen

 

[senderversteller]

Ich nutze zwar Pi-Hole mit Unbound, habe aber zu Unbound mal eine Frage und dachte es passt gut hier rein. Hoffe damit den Thread nicht zu kapern, vielleicht wurde es ja auch irgendwo hier schon mal beschrieben.

In meiner pi-hole.conf habe ich die Zeilen der forward-zone auskommentiert... ich glaube es ist im Eingangsmode als Hyperlocal Mode beschrieben.



Mein Verständnis ist, dass Unbound demnach direkt die Root-Server zuerst und ohne Umwege befragt... und dann gehts die Kette weiter runter über TLD-Server und die verwaltenden DNS.

Laut dnscheck.tools ist das so, als DNS wird mit nur meine eigene IP angezeigt. Hoffe das ist soweit korrekt.




Mir ist bewusst, dass ich die DNS Anfragen damit unverschlüsselt durchs Internet sende, da die Root-Server (noch) kein DoT oder DoH sprechen. Es kann zwar kein anderer DNS-Server protokollieren, wo ich unterwegs bin - allerdings ist ein Lauschangriff möglich.

Wie kann ein konkretes Szenario aussehen, dass jemand mitliest, was mein Resolver und die Root-Server miteinander sprechen? Muss jemand dazu explizit mich / meinen Anschluss aussuchen? Mir fehlt die Vorstellung welchen Nachteil ich mir mit dieser Methode einkaufe. Kann mir jemand auf die Sprünge helfen wie wahrscheinlich es ist, dass jemand die DNS Kommunikation mitschneidet?

 

[prudishly]

Laut dnscheck.tools ist das so, als DNS wird mit nur meine eigene IP angezeigt. Hoffe das ist soweit korrekt.

Ja, dies ist im hyperlocal Modus so korrekt

 

[Mahoessen]

Hi @plang.pl ,
nachdem adguard home seit diversen Jahren problemlos in meinem Netz werkelt, habe ich mit mal daran gesetzt dein Projekt umzusetzen.
das "alte adguardhome" gestoppt, und gemäß deiner Anleitung in #1 installieren.
Leider kommt bei mir der gleiche Fehler wie in #232 bzw. #342 (ja, bin alles durchgegangen )
Irgendwie sieht es so aus, als ob er die unbound.conf nicht mag...
Schreibrechte für everyone habe ich der log Datei und dann auch der unbound.conf gegeben, ansonsten sind die Daten ohne Änderungen wie beschrieben in den Verzeichnissen gelandet- Adguardhome läuft und lässt sich aufrufen/konfigurieren...
Ich sehe gerade nicht wo es hakt, vielleicht hast du noch einen Schubser in die richtige Richtung.

viele Grüße

edit: Projekt.zip Stand V6.1 vom 25.01.2026

 

[prudishly]

Die Fehler stehen doch schon klar beschrieben...
Einfach an die originale Unbound Doku halten und nicht erwarten, dass hier wer anders hilft

Lerneffekt ist dabei umso größer

 

[Mahoessen]

Schubser in die richtige Richtung.

erwarten, dass hier wer anders hilft

gut, dass du die Funktionsweise eines User für User Forums verstanden hast...
edit: du brauchst nicht antworten, ich hatte eine Schritt für Schritt Anleitung zum User sperren....

 

[prudishly]

Zitiere bitte richtig, bevor du Dinge aus dem Kontext reißt!
Halte dich an die offizielle Unbound Doku und schau ob du weiter kommst - reicht das nicht als Hilfestellung?
Wenn Du nicht in der Lage bist mit den Fehlermeldungen etwas anzufangen und andere noch doof anzumachen, solltest du von solchen Projekten lieber die Finger lassen!

 

[Hein06]

Ich habe Adguard und unbound seit Dezember 2023 und es hat bis jetzt gut funktioniert.
Nun bin ich aber auf ein Problem gestoßen. Ich kann die Webseite : www.om-digitalsolutions.com nicht erreichen. Wenn ich Adguard und unbound in der Fritzbox deaktiviere , funktioniert die Webseite. Adguard blockt die Adresse nicht. Im unbound log ist kein Eintrag 0 Byte ??
Win11/Chrome meldet : DNS_PROBE_FINISHED_NXDOMAIN
Die Programm Versionen von Adguard und unbound sind noch von Dezember 2023. Das Updatescript für unbound läuft jeweils am 1. des Monats.

 

[prudishly]

Adguard und Unbound vom 1.12.2023? Dann würde ich dringend mal updaten, und ja, es wird sicher geblockt, außerdem kannst du ja Adguard direkt temporär deaktivieren...

Weiterhin funktioniert die Webseite nicht

Edit: mit Quad9 erreiche ich die Website nicht, mit dem Handy im Telekomnetz klappt es...

Welche DNS-Resolver nutzt du?

 

[Hein06]

in unbound :

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"
url: https://www.internic.net/domain/root.zone
fallback-enabled: yes
for-downstream: no
for-upstream: yes
zonefile: "/opt/unbound/etc/unbound/auth-zone/root.zone"

funktioniert nicht

Fritzbox mit Standard Telekom funktioniert

Fritzbox mit verschlüsselten Servern

dns.google
one.one.one.one
1dot1dot1dot1.cloudflare-dns.com

funktioniert

 

[JohneDoe]

Ich erreiche die Seite. Ich weiß aber nicht welchen DNS server ich am Ende nutze, weil DNSCrypt immer einen anderen nutzt. Aber Quad9 ist auch dabei.
Aber Quad9 kann die auflösen:

nslookup om-digitalsolutions.com 149.112.112.112                                                                                                                                                     ─╯
Server:        149.112.112.112
Address:    149.112.112.112#53

Non-authoritative answer:
Name:    om-digitalsolutions.com
Address: 57.180.132.229
Name:    om-digitalsolutions.com
Address: 52.69.126.39

nslookup om-digitalsolutions.com 9.9.9.9                                                                                                                                                             ─╯
Server:        9.9.9.9
Address:    9.9.9.9#53

Non-authoritative answer:
Name:    om-digitalsolutions.com
Address: 52.69.126.39
Name:    om-digitalsolutions.com
Address: 57.180.132.229

 

[senderversteller]

Ich nutze Pi-Hole mit Unbound im Hyperlocal Mode und kann die Domain auch nicht auflösen.
Ich erhalte ein SERVFAIL. Wenn man die Domain leicht abwandelt kommt hingegen ein NXDOMAIN.
Liegt es vielleicht an einem DNS Problem bei der Domain selbst?

 

[Hein06]

Ich habe mal kurz Dnscrypt gegoogelt, hört sich interessant an.
Adguard und unbound (Stand 12/23) muss ich updaten, dann werde ich es mal testen.

 

[JohneDoe]

Die haben kein AAAA Record sondern nur A. Das heißt die sind nur per IPv4 erreichbar. Vielleicht liegt es ja daran.....

 

[the other]

Moinsen,
jup. Via IPv4 auch hinter pihole und unbound (auf pfsense) direkt erreichbar und auch ein nslookup und dig liefern...und ja: nur ne v4 (wie von @JohneDoe schon bemerkt.

~$ dig om-digitalsolutions.com

; <<>> DiG 9.18.39-0ubuntu0.24.04.3-Ubuntu <<>> om-digitalsolutions.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16112
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;om-digitalsolutions.com.    IN    A

;; ANSWER SECTION:
om-digitalsolutions.com. 0    IN    A    57.180.132.229
om-digitalsolutions.com. 0    IN    A    52.69.126.39

;; Query time: 1 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Fri Apr 03 15:43:23 CEST 2026
;; MSG SIZE  rcvd: 84

 

[senderversteller]

Mir ist es mit dem Pi-Hole und Unbound nicht möglich, diese IPv4 aufzulösen.
Bekomme mit dig wieder ein SERVERFAIL zurück. Woran kann das liegen?

root@pihole:~# dig om-digitalsolutions.com

; <<>> DiG 9.20.21-1~deb13u1-Debian <<>> om-digitalsolutions.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 63186
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;om-digitalsolutions.com.       IN      A

;; Query time: 0 msec
;; SERVER: 192.168.10.3#53(192.168.10.3) (UDP)
;; WHEN: Fri Apr 03 16:28:32 CEST 2026
;; MSG SIZE  rcvd: 52

 

[Hein06]

bei mir sieht das Ergebnis von dig so aus :
ig om-digitalsolutions.com

; <<>> DiG 9.18.39-0ubuntu0.24.04.3-Ubuntu <<>> om-digitalsolutions.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 39221
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;om-digitalsolutions.com. IN A

;; Query time: 264 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Fri Apr 03 16:28:22 CEST 2026
;; MSG SIZE rcvd: 52