Best Practice: AdGuard Home & unbound als DNS-Server

[plang.pl]

Jap. Hab ich grad auch getestet. Deshalb halte ich es für keine Optimallösung.
Ich muss mal kucken, ob man die inversen DNS-Server mit einer "Bedingung" versehen kann, so wie die upstream Server. Habs mit auf die ToDo List geschrieben

 

[plang.pl]

Nachtrag: Ich würde das so gar nicht nutzen, denn sonst hast du im Heimnetz keine funktionierende Reverse Auflösung mehr. Zumindest, so lange in der Fritte der AdGuard als DNS nicht nur im Bereich DHCP eingetragen ist.

 

[daschmidt94]

hab ihn bei DHCP und DNS eingestellt aber verstehe das nicht wirklich

 

[plang.pl]

Naja wenn du ihn nur per DHCP verteilst, dann fragen alle Clients den AdGuard. Wenn du ihn aber auch in der Fritte hinterlegst, dann fragt auch die Fritte den AdGuard und nicht mehr den Provider-DNS. Somit passiert folgendes, wenn ein Client eine IP-Adresse rückauflösen will: Er fragt den AdGuard - dieser fragt die die Fritte (weil du das jetzt so eingestellt hast bei inverse DNS-Server) - die Fritte fragt wiederum den AdGuard. Technisch gesehen ist das also ein Loop.
Man müsste da eine Regel bauen, so wie bei den upstream-DNS Servern eben auch sodass nur Geräte im Heimnetz über die Fritte aufgelöst werden sollen.

 

[update-freak]

Hi zusammen, bei mir scheint es noch Probleme mit den Berechtigungen bzgl. unbound.log zu geben.

[1694979968] unbound[1:0] error: Could not open logfile /dev/null: Permission denied
[1694979968] unbound[1:0] warning: subnetcache: serve-expired is set but not working for data originating from the subnet module cache.
[1694979968] unbound[1:0] warning: subnetcache: prefetch is set but not working for data originating from the subnet module cache.
[1694979968] unbound[1:0] info: start of service (unbound 1.18.0).

Habe Everybody bereits Schreib- und Leserechte gegeben aber im log heißt es noch immer dass es nicht geht.
Weiß jemand woran das liegen könnte?

 

[plang.pl]

Hast du die Datei auch erstellt? Also mein Zip entpackt? Den Fehler gibt es, wenn die Datei nicht exitiert oder wenn die Rechte nicht stimmen

 

[update-freak]

an sich hab ich die zip entpackt, die Dateien in volume1/docker/unbound/data geschoben, Everyone Lese+Schreibrechte gegeben und die Docker compose in Portainer ausgeführt.

Hatte auch versucht die Rechte mit dem Terminal zu vergeben. Die Datei (*.log) hatte aber schon die richtigen Rechte.
Komisch finde ich noch, dass ich keine Ports mit diesem Ansatz bekomme.

Installiere ich Unbound mittels

docker run -d --name=Unbound \
-p 3553:53/udp \
-p 3553:53/tcp \
--restart always \
mvance/unbound:latest

bekomme ich Ports.

Bei beiden Ansätzen habe ich aber keine Schreibrechte

 

[plang.pl]

Was meinst du mit Ports?
In meinem Ccompose läuft das im Host-Netz. Da muss man keine Ports exposen

 

[update-freak]

mit Ports meine ich die Info 3553:53 im screenshot.

In AdGuard konnte ich ihn dnan über

# Unbound
127.0.0.1:3553
# Fritz!Box
[/178.168.192.in-addr.arpa/]192.168.178.1
[/fritz.box/]192.168.178.1

einbinden.
Könnte ich bei deinem Setup dann nur 127.0.0.1 angeben?

 

[plang.pl]

Genau so habe ich es doch auch beschrieben. Das muss dann über localhost laufen. Beide Container laufen dann ganz normal im Netz des Hosts, so wie es z.B. auch DSM-Pakete tun. Die Config-Datei, die ich dem unbound mitgebe (wie im Beitrag 1 auch beschrieben), biegt den Port des unbound von 53 auf 5353 um. Da brauchst man nix exposen, weil es wie gesagt im Host-Netz läuft

 

[update-freak]

alles klar. Danke für die Erklärung dazu.
Eine Frage habe ich noch: Im Video: https://www.youtube.com/watch?v=w32rn_jLb6E wird erklärt dass man die root.hints regemäßig (aber mindestens alle 6 Monate) updaten sollte.
Dort wurde auch das Skript wie folgt vorgestellt:

#!/bin/bash
if wget -O root.hints https://www.internic.net/domain/named.root ; then
    rm /var/lib/unbound/root.hints
    mv root.hints /var/lib/unbound/
    service unbound restart
fi

Macht es noch Sinn die root.hints zu updaten oder wird das automatisch übernommen (komisch ist auch, dass auf der Gitseite vom Video die Anmerkungen zu dem Skript mittlerweile fehlen)?

 

[plang.pl]

Ja, das kann man so machen. I.d.R. ändert sich aber an den root-Servern nix

 

[plang.pl]

@daschmidt94 Ich hab mir das mal angesehen. Auch, wenn in der Web-Ui steht "private inverse DNS-Server" hab ich dem Braten nicht getraut. Aber unbound fragt die dort hinterlegten Server tatsächlich nur dann, wenn eine IP aus einem privatem Adressbereich aufgelöst werden soll. Ansonsten werden die upstream DNS Server gefragt. Somit kannst du dort problemlos die Fritte hinterlegen. In manchen Fällen ist das aber dennoch etwas unschön und manchmal funktioniert diese Auflösung aus irgendwelchen Gründen nicht richtig. Bei mir spielt zum Beispiel eine lubuntu VM den DNS-Server (mit AdGuard und unbound in Docker). Wenn ich normalerweise "nslookup" starte, wird der DNS-Server angezeigt als meine Domain, da diese auf den Server auflöst (weil dort auch der Reverse Proxy läuft, aber andere Geschichte). Wenn ich die Fritte bei den privaten DNS-Servern eintrage, löst die IP logischerweise nicht mehr auf meine Domain auf. Die Fritte löst aber komischerweise nicht mal den Hostname auf. So sieht das dann aus (ganz oben meine Domain geschwärzt):


Zuerst öffne ich nslookup, wenn der unbound eingetragen ist. Dann öffne ich nslookup erneut, wenn die Fritte eingetragen ist. Mit dieser Einstellung löse ich testweise die 8.8.8.8 rückwärts auf, was AdGuard korrekt als nicht-private IP erkennt und den unbound fragt. Der wiederum löst korrekt auf den Google DNS auf.
Grob zusammengefasst: Wenn dir die Hostnameauflösung im AdGuard wichtig ist, dann kannst du die Fritte bei private inverse DNS-Server eintragen. Danke dir jedenfalls für den Denkanstoß an mich. Ich werde das Ganze mit in die Anleitung aufnehmen. Dann kann jeder selbst entscheiden, wie er es haben will.

 

[plang.pl]

Aber unbound fragt die dort hinterlegten Server tatsächlich nur dann, wenn eine IP aus einem privatem Adressbereich aufgelöst werden soll

Fehler meinerseits: Das müsste natürlich AdGuard heißen. Zum Bearbeiten leider zu spät. Aber ich denke, man weiß, was gemeint ist.

 

[plang.pl]

Es gibt Neuigkeiten:
-Hyperlocal Mode des unbound aktiviert (#Privatsphäre #Sicherheit) + Performance-/Sicherheitssettings verbessert
->wenn das Projekt schon läuft, muss man, um das zu aktivieren:
-->die unbound.conf austauschen
-->den Ordner auth-zone unter unbound erstellen und die Datei aus dem zip hineinkopieren
-->den unbound Container neu starten
-Neuer Optionaler Schritt: Umgehen des AdGuard im Heimnetz verhindern
-Neuer Optionaler Schritt: Config-Dateien des unbound automatisch Updaten
-Ansonsten die Schritte neu gegliedert und alles ein wenig aufgehübscht

Danke nochmal an @Ghost108 für das Aufmerksammachen auf den Hyperlocal Mode und den Input (https://www.synology-forum.de/threads/adguard-setzt-sporadisch-aus.129064/post-1108322)

 

[Ghost108]

@plang.pl

Wenn möglich, würde ich auch in der unbound.conf folgenden Parameter setzen:

# Send minimum amount of information to upstream servers to enhance privacy (best privacy).
qname-minimisation: yes

 

[plang.pl]

Das habe ich weggelassen, wie so viele andere Parameter auch, deren default-Wert "true" ist, um die Config-Datei zu verkleinern.

 

[Benares]

Hallo @plang.pl,

mir erschließt sich der Sinn und Zweck von AdGuard & Unbound noch nicht so ganz. Wenn ich es richtig verstanden habe, werden dann nur noch die root- und für einen Namen zuständigen DNS-Server angefragt und die Last nicht mehr verteilt. Wenn das jeder machen würde, bräche m.E. das DNS-System, das ursprünglich mal als verteiltes System konzipiert wurde, irgendwann mal zusammen. Das Ziel, nicht nur mehr einen einzigen DNS-Server anzufragen, und damit die Privacy zu erhöhen, ist mir schon klar, aber der Weg dahin ist m.E. der falsche.

Es gibt ja Millionen von DNS-Servern und jeder kann jeden Namen auflösen, wenn nicht selbst, dann halt durch Nachfragen bei den zuständigen DNS-Servern. Dabei cached er alle Ergebnisse und gibt sie während der Laufzeit der ursprünglich mitgeteilten TTL bei weiteren Anfragen halt als "Non-authoritative answer" aus seinem Cache weiter, ohne das Gesamtsystem weiter zu belasten. Auch jeder DNS-Client macht das so. So verteilt sich die Last wunderbar, wenn zusätzlich jeder Provider so viele DNS-Server bereitstellt, wie es für seinen Kundenstamm braucht.

Meines Erachtens wäre es besser, die Anfragen auf viele öffentliche DNS-Server zu verteilen. Das hätte den gleichen Effekt bez. Privacy ohne nur die root- und SOA-Server zu belasten.

 

[plang.pl]

Grundsätzlich ging es mir selbst eher um die Fähigkeit, Tracking-/Werbe-/Malware-Domains von der Auflösung auszuschließen.
Ein Windows-Server verwendet auch in der Standard-Konfig. die Root-Server. Zumindest, wenn keine upstreams konfiguriert sind oder diese nicht schnell genug antworten.
Wenn das alle machen würden - machen sie aber nicht. Ich muss aber auch zugeben, dass ich mich mit diesem Gedankenansatz noch gar nicht befasst habe-

 

[Ghost108]

Meines Erachtens wäre es besser, die Anfragen auf viele öffentliche DNS-Server zu verteilen. Das hätte den gleichen Effekt bez. Privacy ohne nur die root- und SOA-Server zu belasten.

Wo hätte es denn den selben "Privacy Effekt" wenn du die öffentlichen DNS-Server anfragst?