Best Practice: AdGuard Home & unbound als DNS-Server

[plang.pl]

Voraussetzungen​

In dieser Anleitung wird vorausgesetzt, dass der Umgang mit der FileStation und Hochladen von Dateien aufs NAS bekannt ist und auch, wie man mit Archiven umgeht.

Limitierungen​

-Wenn die DS aus ist, habt ihr kein Internet! Bitte bedenken, dass ohne DNS-Server nix mehr geht. Fahrt ihr also die DS per Zeitplan runter, ist diese Vorgehensweise eher schlecht geeignet.
->man kann das Konstrukt aber auch auf einem anderen Gerät als der DS betreiben (alter Laptop, Raspberry Pi, Tiny PC etc.)

Vorwort​

Warum AdGuard Home + unbound und kein "normaler" DNS-Server
Mit der Kombi hat man einen netzwerkweiten Werbe- und Trackingblocker, der sogar (die richtigen Block-Listen vorausgesetzt) in einem gewissen Umfang vor Phishing und Malware im Heimnetz schützen kann.
Was unbound genau tut, kann man z.B. in diesem Artikel nachlesen.
Warum nicht pihole?
Einfach, weil für mich der AdGuard das bessere Gesamtpaket hat. Die Oberfläche finde ich auch schöner. Das ist aber sicherlich Geschmackssache. Letzten Endes läuft es darauf hinaus: Der pihole hat 1,2 Features, die der AdGuard nicht hat. Genauso sieht es andersherum auch aus. Man sollte beides mal getestet haben und für sich selbst den Gewinner auswählen.

HINWEIS: Keine Gewährleistung auf Vollständigkeit und 100%ige Korrektheit! Wem ein Fehler auffällt, der kann das gerne (mit freundlichem Umgangston) hier melden!

Anleitung​

Schritt 1: Docker vorbereiten
Als Erstes den „Container Manager“ aus dem Paket-Zentrum installieren. Vor DSM 7.2 heißt das Paket nicht „Container Manager“, sondern „Docker“.
Anschließend wechseln in die FileStation in den automatisch erstellten Ordner docker. In diesen Ordner muss das Archiv Projekt.zip aus dem Anhang entpackt werden. Achtung: Es muss danach so sein, dass unter dem freigegebenem Ordner docker direkt die Ordner unbound und adguard liegen.
Wichtig: Nun in den Ordner docker/unbound/data wechseln und Rechtsklick auf die Datei unbound.log machen und die „Eigenschaften“ öffnen. Da müssen wir jetzt „Everyone“ berechtigen mit Lesen und Schreiben, sonst läuft unbound ebenfalls auf einen Fehler. Dazu auf den Reiter „Berechtigung“ wechseln, „Erstellen“ drücken und oben „Everyone“ eingeben und auswählen. Dann Haken bei „Lesen“ und „Schreiben“ setzen, auf „Fertig“ und „Speichern“ drücken:


Kurze Beschreibung der enthaltenen Dateien:
-unbound-update.sh
Optional: Siehe Schritt 7.
-filters.txt
Optional: Siehe Schritt 7.
-docker-compose.yml (adguard & unbound):
Diese Datei sagt dem Docker-Dienst, mit welchen Parametern die Container erstellt werden müssen
-root.hints (unbound/data):
beinhaltet die Informationen zu den Root-DNS-Servern im Internet und verhindert, dass unbound diese erst ermitteln muss. Könnt ihr auch manuell von hier herunterladen.
-unbound.conf (unbound/data):
Hier wird auf die root-Datei verwiesen und zudem der Port für DNS von 53 auf 5355 verbogen. Grund: Port 53 soll unser AdGuard nutzen. Zudem ist dort konfiguriert, dass der unbound im sogenannten Hyperlocal Modus läuft und dadurch keine 3rd Party DNS-Server befragt, sondern alles über die Root-DNS-Server abwickelt. (Danke für den Input an @Ghost108 Thread) Der Rest ist mehr oder weniger Standard. Lediglich wurden einige Sicherheits-/Privatsphäre Optionen verschärft.
Infos zur Config: https://nlnetlabs.nl/documentation/unbound/unbound.conf/
-root.zone (unbound/data/auth-zone):
Die Root-Zonendatei, die für den Hyperlocal Modus erforderlich ist.
Alternativ kann man sich diese auch manuell von hier herunterladen
-Alle anderen Dateien unter unbound/data:
Das sind nur leere Dateien. Da steht nix drin. Wenn sie aber beim Start nicht vorhanden sind, läuft unbound auf einen Fehler.

Schritt 2: Installation des AdGuard Home und unbound-Containers (via CLI)
Unter DSM 7.2 und dem Container-Manager kann der Inhalt der Datei in dem angehängten ZIP unter /adguard/docker-compose.yml einfach eingefügt werden, wenn man im Container-Manager den Punkt "Projekte" und "Erstellen" anwählt. Dann entweder die Datei hochladen oder umstellen auf "docker-compose.yml erstellen" und nur den Inhalt einfügen.
Vor DSM 7.2:
Es muss sich via ssh als Root am NAS angemeldet werden. Wie das geht, beschreibt dieser KB-Artikel ganz gut.
Auszuführende Befehle:

cd /volume1/docker/unbound
docker-compose up -d
cd /volume1/docker/adguard
docker-compose up -d

Schritt 3: Konfiguration des AdGuard Home
Schritt 3.1: Grundkonfiguration des AdGuard Home
Ihr ruft nun im Browser folgende Adresse auf: http://IP_DER_DS:3000. Wobei ihr natürlich "IP_DER_DS" durch die IP-Adresse oder den Hostname der DS ersetzen müsst.
Hier wird die Grundkonfiguration vorgenommen. Da der Port 80 bereits vom NGINX (Reverse Proxy) des DSM belegt ist, vergeben wir einfach einen anderen (ich nehme 8080). Alles andere kann so belassen werden. Wenn gemeldet wird, dass der Port 8080 ebenfalls belegt ist, so müsst ihr einen anderen auswählen.


Unten auf „Weiter“ drücken.
Auf der nächsten Seite vergibt man einen Username und ein Passwort, mit dem man sich in Zukunft auf der Web UI des AdGuard anmelden muss, wenn man Einstellungen ändern will. Dann im „Schritt 4/5“ einfach auf „Weiter" gedrückt und im „Schritt 5/5“ auf „Übersicht öffnen“. Schon haben wir die Grundkonfiguration von AdGuard Home abgeschlossen und ihr werdet auf die Admin-Seite weitergeleitet.

Schritt 3.2: Erweiterte Konfiguration des AdGuard Home
Ihr meldet euch an der Admin Oberfläche mit den vorhin vergebenen Anmeldedaten an.
Dann klickt ihr oben auf „Einstellungen“ und „DNS-Einstellungen“ und gebt im Feld „Upstream-DNS-Server“ Folgendes ein:

# Unbound
127.0.0.1:5355

Dann weiter runterscrollen und bei „Private inverse DNS-Server“ dasselbe eintragen, auf „Anwenden“ drücken.


Anschließend können wir den ersten Erfolg vermelden, wenn wir auf „Upstreams testen“ klicken und unten rechts die grüne Meldung erscheint:


Schritt 4: Testen
Das Ganze kann man testen, wenn man eine Eingabeaufforderung öffnet und nslookup eingibt. Dort dann umschalten auf die DS als DNS-Server via server IP_DER_DS gefolgt von der Eingabe einer Domain:


Schritt 5: Anpassung der FritzBox
Schritt 5.1: Nutzung im Heimnetz
Wenn bis hierhin alles ok ist, kann man den DNS-Server vom Router nutzen lassen, sodass auch alle Clients die Domain korrekt auf die interne IP auflösen. Ich zeige das hier am Beispiel einer FritzBox. Bei anderen Routern bitte entsprechend im Handbuch / Internet nachsehen.
Unter Internet -> Zugangsdaten -> DNS-Server einmal umschalten auf „Andere DNSv4-Server verwenden“ und die Adresse eintragen. Man muss es zweimal eintragen, sonst wird es nicht akzeptiert.


Jetzt haben wir sichergestellt, dass die FritzBox selbst den AdGuard fragt. Also ist der Ablauf aktuell so: Client -> FritzBox -> AdGuard -> unbound.
Grundsätzlich war es das schon. Jedoch gibt es noch eine weitere Stelle, wo der DNS-Server eingetragen werden kann. Technisch gesehen ist es jetzt so, dass per DHCP als DNS-Server die FritzBox verteilt wird. Man kann aber auch gleich per DHCP den AdGuard als DNS-Server verteilen lassen. Dann wäre der Ablauf so: Client -> AdGuard -> unbound. Nachfolgend mal kurz zusammengefasst die Vor- und Nachteile, wenn man dies noch zusätzlich einrichtet:
Nachteile
-die im Screenshot dargestellte Option "Bei DNS-Störungen auf öffentliche DNS-Server zurückgreifen" funktioniert nicht
-falls als zweiter DNS-Server ein anderer eingetragen ist, wird dies auch nicht funktionieren
-wenn die Funktion des AdGuard beeinträchtigt ist, muss sich nach Änderung der Einstellung in der FritzBox erst jedes Gerät neu im Netzwerk anmelden, damit wieder Internet vorhanden ist
Vorteile:
-Potenziell schnellere Anfragebearbeitung
-im AdGuard sehe ich, von welchem Gerät welche Anfrage kam; bisher sehe ich dort nur die FritzBox als Client

[Optional] Schritt 5.2: FritzBox aus dem DNS rausnehmen
Ob man diesen Schritt gehen will, muss man selbst entscheiden anhand der genannten Vor- und Nachteile. Ich habe es getan. Alleine schon, wegen der Problembehebung. Manchmal kommt es vor, dass an Gerät xy die App xy nicht mehr funktioniert. Oft liegt das daran, dass von AdGuard fälschlicherweise legitime Domains geblockt werden. Wenn dem so ist, sehe ich im Log den anfragenden Client und muss nur von diesem die geblockten Anfragen durchgehen und nicht alle. Denn wie gesagt würde ohne diesen Schritt nur die FritzBox als anfragender Client im AdGuard auftauchen.
Hierzu gehen wir nach Heimnetz -> Netzwerk -> IPv4-Einstellungen:


Dort tragen wir beim Punkt „Lokaler DNS-Server“ die IP-Adresse der DS ein:


Grundsätzlich war’s das schon. Nur muss sich jedes Gerät einmal neu anmelden, damit die Einstellung greift. Am einfachsten geht das mit einem Router-Neustart. Wenn noch ein Repeater oder PowerLine etc. im Spiel ist, muss man natürlich auch dafür Sorge tragen, dass sich die dort angemeldeten Geräte ebenfalls neu mit dem Netzwerk verbinden.
Wer weiterhin Hostnamen im lokalen Netz auflösen können will, muss noch eine Sache im AdGuard anpassen. Und zwar die Upstream DNS-Server. Hierzu wechseln wir einmal auf den AdGuard, indem wir im Browser folgende Adresse aufrufen: http://IP_DER_DS:8080. Wenn ihr einen anderen Port bei der Initialeinrichtung gewählt habt, so müsst ihr diesen natürlich ändern in der URL.
Anmelden mit den vergebenen Daten und wir wechseln zu Einstellungen -> DNS-Einstellungen und geben bei „Upstream-DNS-Server“ noch folgendes mit an (hier am Beispiel meines Heimnetzes):

# Fritz!Box
[/1.1.10.in-addr.arpa/]10.1.1.1
[/fritz.box/]10.1.1.1

Weil 10.1.1.1 meine FritzBox ist. Im Standard verwendet die FritzBox das Netz 192.168.178.0. Dann müsstet ihr folgendes eintragen:

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

Dann unten auf “Anwenden” drücken:


Die eben getätigte Einstellung bewirkt, dass bei IP-Adressen, die sich im Heimnetz befinden, ebenfalls die FritzBox zur Namensauflösung befragt wird.
Achtung!
Nach dieser Umstellung ist die FritzBox ggfs. nicht mehr per fritz.box erreichbar, sondern nur noch per IP. Möchte man das ändern, bitte einen Blick in die erweiterte Konfiguration (Link siehe Schritt 7) werfen.

[Workaround] Schritt 6: Kernel-Fehler bei älteren DSen
Da die DSen teils mit einem uralten Linux-Kernel laufen, kann es zu Problemen mit dem unbound Container in der neuesten Version kommen. Die DSen bleiben leider i.d.R. auf dem Kernel-Stand, mit dem sie ausgeliefert werden. Da hilft auch ein DSM-Update nix.
Wenn im unbound Log diverse Fehler auftreten, der Container nicht startet oder funktional ist, gibt es aktuell 2 mir bekannte Workarounds:
Schritt 6.1: die unbound.conf anpassen
Einfach die unbound.conf unter /docker/unbound/data mit einem Texteditor öffnen und Folgende Zeile löschen und auskommentieren: so-rcvbuf: 1m. Der Error im Container Log bei diesem Bug schaut in etwa so aus:

unbound[1:0] warning: so-rcvbuf 1048576 was not granted. Got 425984. To fix: start with root permissions(linux) or sysctl bigger net.core.rmem_max(linux) or kern.ipc.maxsockbuf(bsd) values.

Beim Löschen / Auskommentieren des Eintrags, ist der Cache entsprechend kleiner.
Schritt 6.2: Ältere Version von unbound verwenden
Wenn man den latest-Tag nutzt, erhält man seit einiger Zeit ein Image, welches auf Debian Bookworm (v12) und nicht mehr Dedian Bullseye (v11) basiert. Auch damit kommen teils die alten Kernel nicht zurecht. Da Synology da nix unternimmt, hilft es nur, das Ganze von der DS auszulagern oder auf eine ältere Version zu gehen. Das wäre dann der Tag 1.17.1. D.h. in der docker-compose.yml unter /docker/unbound muss die Zeile image: mvance/unbound:latest gegen image: mvance/unbound:1.17.1 ausgetauscht werden. Dann erhält man keine neueren unbound-Versionen mehr. Anschließend muss der unbound-Container gelöscht werden und erneut mit

cd /volume1/docker/unbound
docker-compose up -d

hochgebracht werden. Siehe auch Schritt 2.

OT: Die Version des Linux-Kernels auf der DS kann man übrigens via ssh mit dem Befehl uname -r ermitteln.

[Optional] Schritt 7: Dem Setup "Beine machen"
In einem anderen Thread (aufgrund der Begrenzungen in der Thread-Länge), habe ich ein paar Möglichkeiten aufgezeigt, was noch verbessert werden kann: Klick
Ich meine, dass man dort zumindest die automatisierten Updates der unbound-Dateien einrichten sollte, damit man nicht irgendwann ne fehlerhalfte DNS-Auflösung hat.

[Optional] Schritt 8: Nutzung zur Domainauflösung im internen Netzwerk
Lokale Nutzung von https mit gültigen Zertifikaten: siehe weitere Anleitung

[Optional] Schritt 9: AdGuard Home Sync einrichten
Ein Replica des Containers einrichten: siehe weitere Anleitung

[Optional] Schritt 10: IPv6 deaktivieren
Soll kein IPv6 verwendet werden, muss in der unbound.conf Datei noch folgendes ergänzt werden (direkt am Anfang der Datei, unter der Zeile server:):

do-ip6: no
local-zone: ip6.arpa. refuse
prefer-ip6: no

Danach einmal den unbound Container neustarten.
Ebenfalls muss man dann IPv6 im AdGuard ausschalten. Das geht einfach über die Weboberfläche:




[Optional] Schritt 11: Statt dem Hyperlocal Mode im unbound dns-over-https nutzen
Das jetzt beschriebene ist eine alternative Arbeitsweise des unbound. Statt dem Hyperlocal Mode, wo der unbound keine 3rd Party DNS Server befragt, kann man auch dns-over-https machen (also verschlüsselte Anfragen an 3rd Party Nameserver). Wer was bei sich nutzen will, bleibt jedem selbst überlassen. Vorgehensweise: Post #44 von mir in diesem Thread



Wenn es hierzu fragen gibt, könnt ihr euch gerne in diesem Thread melden!

Spoiler: Agenda

Ein Compose Script für beide Container. Macht es einfacher.

v5.1.2

Spoiler: Changelog

24-04-17 | v5.1.2
-Fehler / Unklarheiten bezüglich unbound-Update Script beseitigt
-Hinweis, dass Anleitung Fehler enthalten könnte
24-04-11 | v5.1.1
-Artikel zu unbound wurde offline genommen -> stattdessen auf die Wayback Machine verlinkt
24-04-04 | v5.1
-Schritte zum Deaktivieren von IPv6 besser beschrieben
24-03-20 | v5
-Thread aufgeteilt in 2 Threads, da die Begrenzung der Thread-Größe erreicht war
->Schritte überarbeitet und besser beschrieben + strukturiert
24-03-15 | v4
-Beschreibungen an vielen Stellen ausgebaut / erweitert / verknüpft
-Verständlichkeit / Formulierungen / Formatierungen an einigen Stellen verbessert
-meine Filterliste zum Einfügen bei euch aktualisiert
-Punkt zum "Reparieren" der Auflösung von fritz.box hinzugefügt
-weitere Ports aufgezählt, um DNS-Anfragen vorbei am AdGuard zu unterbinden
24-02-11 | v3.5
-in der unbound Config serve-expired-ttl ergänzt (86400 -> ein Tag)
24-01-22 | v3.4
-Vorwort ergänzt
-Einheitliche Formatierung für alle "Best Pracice Threads" umgesetzt
-Unklarheuten / undeutliche Formulierungen beseitigt / verbessert
23-12-06 | v3.3.1
-Schritt 10 ergänzt (Link zur neuen Anleitung für AdGuard Home Sync)
23-12-01 | v3.3
-Rechtschreib- / Grammatik- / Logikfehler behoben
-Formatierungsfehler behoben
-Schritt 7.1 besser beschrieben
-Ergänzt: "Bei Fragen bitte melden"
23-11-10 | v3.2.1
-Projekt zip neu erstellt und hochgeladen, da leere Ordner nicht mit gezippt waren (im adguard-Verzeichnis)
23-10-21 | v3.2
-Script zur Aktualisierung der unbound-Dateien angepasst
->Der Docker Container wird nun über die DSM API anstatt dem Docker Daemon neu gestartet, um Error Logs zu verhindern
23-10-14 | v3.1
-Link zur Erklärung von Hyperlocal hinterlegt
-Link zu Infos zu der Config-Datei hinterlegt
-Problem bei älteren Kernels / älteren DSen mit Workarounds aufgenommen
-Fehler im Update-Script behoben
23-10-10 | v3.0.1
-Umstellung von Hyperlocal auf dns-over-https mit in die Anleitung inkludiert
-Fehler in Config-File behoben, dass zu Errors im unbound-Log führte
23-10-07 | v3
-Schritt 8.1 (Vorbeimogeln am AdGuard verhindern) ergänzt
-Schritt 8.2 (Automatisierte Updates) ergänzt
-Neue Config-Datei für unbound: abgespeckt (massiv kleiner) + Performance-Verbesserungen + Hyperlocal Modus aktiviert
-Rechtschreib- und Grammatikfehler verbessert
-Formatierungen + Formulierungen verbessert
-Überschriften ergänzt
-Schritte neu strukturiert und mit logischen "Überschritten" versehen
23-09-22 | v2.1
-Schritt 7.3 (Reverse-Hostnameauflösung) ergänzt
23-08-29 | v2
-Schritt 7 ergänzt, dadurch verschieben sich die Folgeschritte um eine Nummer nach hinten
-Punkt "Agenda" ergänzt (eher für mich selbst)
-Herausgabe Teile meiner Konfig-Datei für den AdGuard, die direkt viele Blocklisten bei euch einspielt
-Guide für DSM 7.2 und den Container-Manager angepasst
-Formatierungen verbessert

 

[plang.pl]

Update:
Hab mal Teile meiner Config mit reingestellt. Da sind 47 Blocklisten inkludiert (falls ich richtig gezählt habe) und auch diverse Custom-Filterregeln, die entweder fälschlicherweise blockierte Seiten freigeben oder unnötige / gefährliche Dienste sperren.
Stand heute habt ihr damit alleine mit den dynamischen Sperrlisten 4.581.054 Domains geblockt. Dazu kommen noch die RegEx Regeln aus den benutzerdefinierten Einträgen.
Ich werde demnächst auch noch eine aktualisierte Config. des unbound hier anhängen, die vor allem in Bezug auf Performance noch mal einige Änderungen mitbringt. Auch geplant ist eine Anleitung zum Einrichten eines AdGuard HA-Setups bzw. einem Sync zwischen 2 Standorten, wie ich ihn derzeit praktiziere.
Auch habe ich dank eines Users hier die Fehlermeldungen mit der UDP Buffer Size des AdGuard Containers deutlich verringert. Siehe oben Schritt 7.1

 

[geheim5000]

Da hab ich mal ne Frage die vill. nicht ganz 100% passt.

ich habe aktuell pihole mit unbound laufen, und weil ich Probleme mit Docker hat, läufts in einer VM. DHCP macht die DS.

Jetzt lese ich so wie hier wieder das inzwischen viele auf AdGuard setzen, ist ein Wechsel zu empfehlen?

 

[alexhell]

Am Ende machen beide das Gleiche. Ich finde Adguard sieht schöner aus und lässt sich besser bedienen. Wenn dein PiHole so läuft wie es soll, dann weiß ich nicht, ob ein Wechsel unbedingt sein muss. Es wird sich nicht viel ändern.

 

[plang.pl]

Ich finde AdGuard auch einfach schöner und moderner. DHCP kann AdGuard auch machen. Das kann aber glaube ich pihole auch.
https://www.virtualizationhowto.com/2023/03/adguard-home-vs-pihole-best-adblocker/
https://schroederdennis.de/allgemein/pihole-vs-adguard-home-welcher-dns-blocker-gewinnt-ist-besser/

 

[geheim5000]

ja DHCP kann pihole auch, wollte den DHCP nur nicht auf dem Raspi laufen haben, darum auf der DS.
Gut jetzt ist alles auf der DS

 

[plang.pl]

Also wenn ich die Möglichkeit hätte (die ich auch tatsächlich habe und nutze) - würde ich nicht alles, was geht auf die DS packen. Sondern eher möglichst viel auslagern, was nix mit Nutzdaten zu tun hat. Raspberry, Tiny PC, Server, wie auch immer. Nur weil eine DS alles kann, sollte sie noch lange nicht alles tun.

 

[alexhell]

Ich habe auch nur Sachen auf der DS laufen, die auf die Daten auf der NAS zugreifen. Also sowas wie paperless, Plex, calibre oder jDownloader... Forgejo läuft zwar auch auf der NAS aber eher wegen Backup. Das meiste lagere ich aber aus. Die DS soll wirklich mehr ein Datengrab sein.

 

[geheim5000]

ist bei mir eher gekommen, weil der raspi iwie kacke im Serverschrank stand. dann hab ich das ausgelagert auf die DS

und DHCP war aus der Not herraus, weil Probleme mit öfteren Routerwechsel.

Ansonsten, ja so eine Spielwiese wie plang stand bzw. steht auf der Wunschliste. Aktuell hält mich aber echt der Stromverbrauch davon ab

 

[Ronny1978]

Sondern eher möglichst viel auslagern, was nix mit Nutzdaten zu tun hat. Raspberry, Tiny PC, Server, wie auch immer. Nur weil eine DS alles kann, sollte sie noch lange nicht alles tun.

Das sehe ich auch so. Onbound und DHCP läuft auf meiner OpnSense Firewall (Mini PC), Adguard auf Proxmox auf einen anderem Mini PC. Man sollte immer irgendwo ein Backup haben. Wenn alles auf der DS läuft und die streikt, geht gar nichts mehr im Haus. Dann hat man Freude mit Frau und Kindern, wenn das Internet und Netzwerk nicht mehr geht .

 

[Maginos]

/etc/sysctl.conf

Linux ist sehr sparsam mit dem UDP Buffer. Um das zu ändern, muss man in der /etc/sysctl.confund in der /etc.defaults/sysctl.conf folgendes ergänzen. So hat der Buffer 3MB und die Fehlermeldung sollte weg sein oder zumindest deutlich seltener auftreten. Funktional bringt diese Meldung aber keine Einschränkungen mit sich.

Danke @plang.pl für den Hinweis, diese Fehlermeldungen scheinen einige Nutzer in letzter Zeit zu haben und keiner weiß so richtig, wie man den Fehler wegbekommt.

Ich hab die Zeilen mit net.core in meine

/etc/sysctl.conf

eingefügt und hoffe, dass der Fehler dadurch verschwindet. Die

/etc.defaults/sysctl.conf

Datei habe ich allerdings nicht gefunden. Macht das was aus?

Hab Adguard einmal als Docker unter Ubuntu laufen und einmal als LXC ebenfalls unter Ubuntu.

Danke schon mal für die Hilfe!

 

[plang.pl]

Den /etc.defaults gibt es nur auf der DS

 

[Maginos]

Alles klar, danke!

 

[Wiesel6]

In den Screenshot unter den Netzwerkeinstellungen fehlt bei dir IPv6.
Hast du IPv6 komplett deaktiviert? Was mich stutzig macht, ist das Screenshot von der Adguard Installation. Dort ist die IPv6 Adresse im Screenshot zu sehen.

 

[plang.pl]

Ja, bei mir ist IPv6 komplett deaktiviert. Was aber den Docker-Daemon anscheinend nicht daran hindert, Link-Local IPv6 Adressen an den Container zu vergeben.

 

[daschmidt94]

hab alles eingerichtet wie du, nur sehe ich die Clientnamen nicht sondern nur die IP Adresse. Ist das bei dir auch so?

 

[plang.pl]

Ich sehe auch keine Clientnamen. Nur die IP-Adressen. Allerdings sieht man Namen, die der AdGuard selbst rückauflösen kann (also DNS-Einträge):


Wenn man also die Clientnamen als DNS-Record setzt, dann geht das. Anders geht es leider nicht, da der AdGuard soweit ich weiß keine Funktion bietet, einen Reverse Lookup über das DNS der Fritte auszuführen

 

[daschmidt94]

Hab etwas experimentiert. Wenn alle Einstellungen von unbound und bei privat inverse DNS Server die Ip der Fritzbox angegeben wird klappt es.

 

[plang.pl]

Also steht nun bei "Private inverse DNS-Server" nur die Fritte drin bei dir?

 

[daschmidt94]

Ja so sobald ich es mit unbound und Fritte versuche klappt das leider nicht