Best Practice: AdGuard Home & unbound als DNS-Server

[plang.pl]

Ok. Das muss ich mir heute Abend mal ankucken.
Ja, das geht mittlerweile auch über den Container Manager. Der aktualisiert aber nur das Image. Also die Programmversion, nicht aber die Dateien, aus denen unbound seine Infos nimmt.

 

[alexhell]

Aber Watchtower würde es in der Nacht automatisch erledigen. Du müsstest dich darum nicht kümmern.

 

[Keen]

Die Dateien, aus denen Unbound seine Infos nimmt, müsste man das händisch ändern. Gibt's denn da so viel zu ändern? Unbound wird auch nicht allzu oft geupdatet, höchstens ein zwei mal im Jahr.

 

[alexhell]

Die zwei Dateien um die es da geht werden bisschen häufiger als zwei mal im Jahr aktualisiert.....

 

[Keen]

was genau wird da geändert?

 

[alexhell]

Es ändern sich mal die IPs der Server. Hier siehst du auch den aktuellsten Stand mit Datum.

 

[Fusion]

Die Datei wird öfter aktualisiert, als dass sich vom Inhalt wirklich was ändert. Manche IPs sind seit 1995 unverändert.

https://www.icann.org/en/system/files/files/rssac-023-04nov16-en.pdf

 

[Keen]

Diese Daten werden beim Container Update selbst geändert oder sind das diese welche das Script ändert?
Mich wundert es nur, bei mir lief jetzt 2 Jahre Pihole mit Unbound ohne das ich Daten geändert hätte, da lief auch kein Script.

 

[alexhell]

Diese Daten werden durch das Script geändert. Wie @Fusion geschrieben hat ändert sich da nicht viel. Es schadet ja aber nicht, wenn man sich die neuste Datei ab und zu zieht. Es ist ja nicht mit viel Aufwand verbunden...

 

[plang.pl]

bei mir lief jetzt 2 Jahre Pihole mit Unbound ohne das ich Daten geändert hätte, da lief auch kein Script.

Das ist aber ja nur relevant, wenn der unbound im Hyperlocal Mode, wie hier beschrieben läuft. Wenn nicht, dann muss man da auch nix updaten, denn dann wird die Root-Zone Datei nicht gebraucht, die die IP-Adressen der DNS-Server beherbergt

 

[plang.pl]

@Keen
Bei mir läuft das Script fehlerfrei durch. Wenn bei dir die unbound-Daten nicht unter /volume1/docker/unbound/data liegen, musst du natürlich das Script anpassen. Wenn der Pfad nicht existiert, kann curl da auch nix hinladen.

 

[Elias Stahl]

Hallo,
Ich habe bislang pi-hole auf einem Raspi genutzt und habe nun mit meiner neuen DS224+ Adguard & unbound ausprobiert - dank der tollen Anleitung war die Installation kein Problem. Vielen Dank!

Im Unterschied zu pi-hole ist mir folgendes Aufgefallen: Wenn ich im Safari (egal oder MacOS oder iOS) ein privates Fenster öffne, werden keine Webseiten gefiltert, Adguard ist hier wirkungslos. Das war bei pi-hole nicht so. Bei Chrome oder Firefon werden die Webseiten bei privaten Fenstern korrekt gefiltert. Kennt ihr den Grund dafür?

Dann finde ich im Protokoll in der Container Ansucht auf der DiskStation folgende Protokoll Einträge, nach einem Tag mehrere Tausend davon:
[error] dnsproxy: upstream 192.168.100.1:53 failed to exchange ;2003:xxx:xxx:xxx:9209:d0ff:fe45:2537.0.100.168.192.in-addr.arpa. IN A in 20.001149328s: exchanging with 192.168.100.1:53 over udp: read udp 192.168.100.45:33701->192.168.100.1:53: i/o timeout
Ich nutze den Private inverse DNS-Server gemäß Anleitung.

Und eine letzte Frage: kann ich die Docker Verzeichnisse von volume1 auf eine externe USB-SSD verlagern? Meine HDDs in der Diskstation laufen kontinuierlich um die AdGuard Aktivitäten zu loggen, das möchte ich gerne vermeiden.

 

[plang.pl]

Der Grund kann eigentlich nur sein, dass Safarai sich am AdGuard vorbeimogelt. Da gibts Sachen wie "privates" oder "sicheres" DNS.
Safari ist ja auch nicht mehr wirklich modern. Schau doch mal, ob du die Anfragen des Safari im AdGuard siehst. Ich gehe nicht davon aus...
Und ich denke schon, dass du das Docker-Verzeichnis auf ext HDD auslagern kannst.
Und der Fehler schaut mir nach irgendeinem IPv6 Problem aus..

 

[Elias Stahl]

Danke für die schnelle Rückmeldung. Ich habe den AdGuard Container neu gestartet, nun sind die Fehlermeldungen weg.
Auch das Safari Problem konnte ich lösen, es gibt seit iOS 17 eine neue Funktion, die in privaten Safari Fenstern das Tracking verhindern soll. Wenn man diese abschaltet, wird wohl auch der hinterlegte DNS deaktiviert. AdGuard filtert dann wieder.

 

[*kw*]

Und der Fehler schaut mir nach irgendeinem IPv6 Problem aus..

Habe ich die Woche mit IPv4 auch festgestellt, obwohl ich in der Fritte (Zugangsprofile) den Tipp mit der Zwangsnutzung des Aguard-DNS umgesetzt habe.

Ich mache mal den Gegentest mit deaktiviertem Tracking.

 

[plang.pl]

Ich blockiere bei mir ausgehend nicht nur den "normalen" DNS-Port, sondern auch 5353 und 853

 

[Cavekeeper]

Da ich noch keinen funktionellen DNS-Server im Netz habe, wollte ich dieses Projekt auch mal ausprobieren. Leider scheitert es schon daran, den Adguard Container zum Laufen zu bekommen. Ich erhalte den Fehler: "tcp 0.0.0.0:3000: bind: address already in use"
Logisch, Adguard läuft als Host und will den Port 3000 für sich beanspruchen. Nun läuft aber auf genau diesem Port Grafana. Das zu ändern, wäre viel Arbeit, da ich einige Statistiken über diesen Port intern verteile.
Das heißt, ich müsste den Port 3000 von Adguard auf einen anderen mappen und den Host-Modus deaktivieren?
Wäre das sinnvoll bzw. funktioniert das im Endeffekt?

 

[alexhell]

Adguard läuft auch super im Bridge Modus. Dann kannst du den Port ohne Probleme ändern.

 

[Cavekeeper]

Ok, dann werde ich Adguard in eine Netzwerk-Bridge verbannen. Wäre das für Unbound auch sinnvoll? Dann würde ich beide in ein gemeinsames Netzwerk stecken.

 

[alexhell]

Bei mir läuft alles als Bridge. Ich lasse nichts im Host Mode laufen.