Best Practice: AdGuard Home & unbound als DNS-Server

[JohneDoe]

Müsst ihr sonst mal mit unbound checken, ob unbound das auflöst oder ob Adguard euch da was kaputt macht. Unbound hat doch die Möglichkeiten per CLI direkt eine Domain aufzulösen.

 

[Hein06]

unboundcli ist bei mir nicht installiert
bei Adguard auch nichts auffällig , Schutz abschalten hilft auch nicht

 

[JohneDoe]

Natürlich ist es das. Du hast doch unbound irgendwo laufen. Wahrscheinlich im Container. Dann wird das dort auch verfügbar sein.

 

[Hein06]

Ich habe im Container ein bash Terminal gestartet und unboundcli -- help aufgerufen :
unboundcli command not found

unboundcli commands : dns auflösen kann es wohl auch nicht

 

[Hein06]

 

[JohneDoe]

https://nlnetlabs.nl/documentation/unbound/unbound-host/

 

[Hein06]

unbound-host kennt er , muss jetzt erst mal lesen, wie ich das bedienen muss

 

[Hein06]

 

[JohneDoe]

Also löst unbound das schon mal auf. Dann muss es ja an Adguard liegen.

 

[Hein06]

wie kann ich feststellen aus welchem Land diese Ip Adressen sind, ich habe einige Länder in Adguard gesperrt : /(\.cn$|\.ru$|\.su$|\.vn$|\.top$)/

 

[JohneDoe]

Wieso tippst du das nicht direkt bei Google ein. Der erste Treffer sagt einem AWS Japan.

 

[senderversteller]

Also ich habe jetzt ein bisschen mit ChatGPT und Unbound herum gespielt. Was ich sagen kann ist, dass es weder an Adguard noch an Pi-Hole liegt.

Mein Resultat:
Wenn ich in /etc/unbound/unbound.conf.d/pi-hole.conf folgende Zeile ergänze:

val-permissive-mode: yes

dann löst Unbound korrekt auf:

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

; <<>> DiG 9.20.21-1~deb13u1-Debian <<>> om-digitalsolutions.com @127.0.0.1 +dnssec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59292
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

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

;; ANSWER SECTION:
om-digitalsolutions.com. 60     IN      A       52.69.126.39
om-digitalsolutions.com. 60     IN      A       57.180.132.229
om-digitalsolutions.com. 3599   IN      RRSIG   A 13 2 60 20260403164646 20260403144546 56240 om-digitalsolutions.com. 9pn21yjtRQNfwggMNGvilr6U3y99mW/e9bxN9ZA84gHKbyI9lemqPVbd CYmNlBBJVe+zNLUCV80kFqKKeeIaTA==

;; Query time: 407 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Fri Apr 03 17:45:47 CEST 2026
;; MSG SIZE  rcvd: 203

Dieses val-permissive-mode: yes bewirkt, dass Validierungsfehler ignoriert werden und saubere Antworten kommen. Das ist allerdings keine wirkliche saubere Lösung für den Dauerbetrieb.

Ansonsten hat mir ChatGPT allerlei empfohlen, Root-Zone und Hints aktualisieren (war vorher schon aktuell), Trust Anchor neu erstellen (hab ich getestet), EDNS-Puffer erhöhen auf 4096 (habe ich gemacht), ... und "fallback-enabled: yes" in der Auth-Zone aktivieren um im Fehlerfall über die Root Server zu gehen (Bringt allerdings nix). Ich bekomme immer SERVERFAIL, so lange val-permissive-mode nicht auf yes steht.

Keine Ahnung was an meiner Konfig defekt ist, dass diese Domain von meinem Unbound nicht aufgelöst wird, von Cloudflare und Google aber schon. Sonst habe ich eigentlich auch keine DNS Probleme bisher bemerkt, so dass ich in Ruhe weiterleben könnte. Aber irgendwas hat's da. Oder liegt es vielleicht doch an einer fehlerhaften Konfiguration an der Gegenseite?

 

[Hein06]

Die Länder waren es nicht, hatte sie alle auskommentiert. Die 57.180. .. ist wohl aus Rumänien
Adguard will es auch nicht gewesen sein.

 

[JohneDoe]

Bei mir wurde bei beiden Japan angezeigt.

 

[the other]

Moinsen,
dem "dig" Befehl könnt ihr noch ein "+nssearch" anhängen, der zeigt dann die befragten DNS Server der autoritativen Ebene.
Und mit dem Anhängen von "+nsid" wird der rekursive DNS Server angezeigt. Natürlich nur, wenn diese die Info auch zur Verfügung stellen.

Bei meiner Anfrage war zB ein amazon DNS Server der Befragte...

 

[Hein06]

Jetzt kam diese Antwort, ich denke die sind am Basteln

 

[senderversteller]

@Hein06 Das erklärt aber nicht, warum Unbound einen DNSSEC Validierungfehler bei dieser Domain zeigt. Wohl gemerkt, ich betreibe Unbound strikt im Hyper Local Mode. Du auch?

 

[Hein06]

ja , Hyper Local Mode

 

[daniel16]

Hallo zusammen,

ich beabsichtige Unbound als auch AdGuard Home via Portainer Stacks als eigene Container mit jeweils eigener IP4-Adresse (eine für Unbound und eine für Adguard Home) auf meiner DiskStation zu installieren.

Dazu würde ich ein bereits existierendes McVLAN nutzen und in der jeweiligen YAML-Datei eine entsprechende IP4-Adresse für den Unbound- und AdGuard Container vergeben (dann hätte Unbound und Adguard Home jeweils Ihre eigene IP4-Adresse).

Den entsprechenden Container würde ich nach der Installation über die FritzBox immer dieselbe IP-Adresse geben (wobei das wahrscheinlich gar nicht notwendig wäre da ich über die jeweilige YAML-Datei ja bereits die IP4-Adressen aus dem McVlan zuordne).

Als Stack-Vorlage für den Unbound- und den AdGuard-Container würde ich die in der ZIP-Datei enthalte docker-compose.yml in zwei einzelne YAML-Dateien aufspalten (Zeile 1-10 für Unbound und ab Zeile 11 – 18 für AdGuard Home – jeweils noch um die Einträge für das McVlan ergänzt).

Das müsste ja funktionieren.

Ich habe eine Fragen zur der in ZIP-Datei enthaltene unbund.conf.

In Zeile 7 der unbound.conf (habe diese mit VSCodium auf Win geöffnet) ist das Interface mit „interface: 0.0.0.0@5355“ angegeben. Ist dies – unter der Annahme das ich unbound mit einer eigenen IP4-Adresse installiere überhaupt notwendig? Ich kann doch dann direkt den Port 53 verwenden, also die bestehende Zeile 7 durch „interface: 0.0.0.0@53“ austauschen, oder?

Weitere Frage zu der unbound.conf ab Zeile 30 - # Access Control.

Meine FritzBox (FB) dient momentan als DNS-Solver im Netzwerk (also 192.168.178.0/24) wobei die FB im Bereich 192.168.178.64/26 die IP-Adressen an Geräte vergibt welche neu oder noch keine feste zugeordnete IP in meinem Netz über die FB haben.

Der Bereich 192.168.178.0/26 wird von mir genutzt um Geräten in der FB manuell eine feste IP zuzuordnen. Der Bereich 192.168.178.128/26 habe ich reserviert um diese IP-Adressen für das McVlan zu verwenden (im Moment befinden sich nahezu alle meine Docker-Container sich in diesem Bereich mit jeweils eigener IP4-Adresse).

In den Zeile 31 – 35 der unbound.conf sind IP4-Netze aufgelistet, welche den unbound nutzen dürfen.

Da ich aber im Heim nur ein IP4-Netz habe (192.168.178.0/24), würde doch eine Zeile mit dem entsprechenden Eintrag ausreichen (also Zeile 31 mit access-control: 192.168.178.0/24 allow), oder?

Evtl. dann noch eine Zeile 32 mit dem entsprechendem IPv6 Eintrag für mein IPv4-Netz?

Liege ich richtig?

Müssten die zuvor genannten Anpassungen – immer unter der Vorraussetzung das diese korrekt sind – nicht in ähnlicher Form ab Zeile 44-50 (gemacht werden?

Angenommen die bis zu diesem Punkt gemachten Aussagen/Anpassungen sind korrekt und Unbound wäre mittels Stack/ YAML mit der IP4-Addresse 192.168.178.130 (befindet sich im McVlan-Bereich) als Container installiert und läuft (!!), müsste ich im AdGuard Home (nach dem ebenfalls als Container installiert) unter Einstellungen/DNS-Einstellungen/Upstream-DNS-Server doch nur noch die IPv4-Adresse meines Unbound-Containers eintragen (also in diesem Beispiel also 192.168.178.130), ohne zusätzliche Angabe des Ports da ich den Port 53 auf der 192.168.178.130 ja nutzen kann, oder?

Sind einige Fragen die ich hier stelle. Wenn nur die Hälfte meiner hier geäußerten Vermutungen richtig sind, freue ich mich schon tierisch.

Ich möchte mich jetzt schon für eure Hilfe und Unterstüzung bedanken.

Gruß