Best Practice: AdGuard Home & unbound als DNS-Server

Ja, das vermute ich auch. Wegen solchen Fehlern betreibe ich alles, was möglich ist, nicht mehr auf der DS in Docker, sondern auf einem Linux-Server.
 
Mal so eine Ftagein die runde,

was habt ihr bei Bootstrap-DNS-Server eingetragen ?
 
Ich habs auf Standard gelassen, also
Code:
9.9.9.10
149.112.112.10
Ist aber bei mir irrelevant, da ich keine DoH Upstreams hinterlegt habe.
Hier in der Anleitung auch irrelevant, da wenn überhaupt, die DoH Auflösung über den unbound läuft.
 
Habe ich so übernommen:

Code:
80.241.218.68
159.69.114.157
9.9.9.10
149.112.112.10
2620:fe::10
2620:fe::fe:10
 
  • Like
Reaktionen: *kw*
Guten morgen zusammen,

der Fehler lag natürlich vor dem Monitor :cautious:
Ich hatte Berechtigungsprobleme.

Foilgende Fehlermeldung kommt noch

[1697262042] 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.
[1697262042] 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.


wurde gelöscht in der conf
 
  • Like
Reaktionen: update-freak
Glaube ich habe noch einen kleinen Fehler gefunden, denn es müsste meiner Meinung nach wie folgt heißen:

Code:
curl --output /volume1/docker/unbound/data/root.hints https://www.internic.net/domain/named.root
curl --output /volume1/docker/unbound/data/auth-zone/root.zone https://www.internic.net/domain/root.zone
docker restart unbound

Trotz meines alten Kernels läuft es jetzt mit der vorherigen Version von Unbound:
Code:
version: "3"
services:
  unbound:
    container_name: Unbound
    image: mvance/unbound:1.17.1
    network_mode: "host"
    restart: always
    volumes:
      - /volume1/docker/unbound/data:/opt/unbound/etc/unbound
 
Ah ok, da ich einen neueren Kernel habe ( 4.4.302+ #69057 ), gibt es mit der aktuellen unbound Version wohl keiner Probleme.
 
Zuletzt bearbeitet:
Glaube ich habe noch einen kleinen Fehler gefunden
Aber genauso, wie du schreibst, sieht das Script doch bereits aus?

Ich habe den Initialpost aktualisiert:
-Link zur Erklärung von Hyperlocal hinterlegt (den Heise-Artikel, den @Ghost108 gepostet hat)
-Link zu Infos zu der Config-Datei hinterlegt
-Problem bei älteren Kernels / älteren DSen mit Workarounds aufgenommen
 
  • Like
Reaktionen: update-freak
bei der zweiten Zeile müsste glaub
/volume1/docker/unbound/data/auth-zone/root.zone anstatt
/volume1/docker/unbound/data/auth-zone/root.hints
stehen
 
Zuletzt bearbeitet von einem Moderator:
  • Like
Reaktionen: plang.pl
Stimmt. Die Dateien werden in die falschen Verzeichnisse kopiert. Habe quasi die Zeilen vertauscht :ROFLMAO:
Danke dir. Werde ich gleich korrigieren
 
  • Like
Reaktionen: update-freak
Ich nutzte immer welche, die DoH können. Im Hyperlocal brauchst ja keine öffentlichen hinterlegen
 
Weil du in dem Fall der DNS Server bist. Das ist ja der Sinn der Sache. Nicht über öffentliche Server zu laufen
 
  • Like
Reaktionen: Tuxnet und *kw*
Hab das Script unbound-update.sh aktualisiert.
Der Docker Container wird nun über die DSM API neu gestartet und nicht mehr über den Docker Daemon, um Fehlermeldungen im DSM und Error Logs zu vermeiden.
 
  • Like
Reaktionen: update-freak
 

Kaffeautomat

Wenn du das Forum hilfreich findest oder uns unterstützen möchtest, dann gib uns doch einfach einen Kaffee aus.

Als Dankeschön schalten wir deinen Account werbefrei.

:coffee:

Hier gehts zum Kaffeeautomat