Als het goed is binnenkort Odido, die gebruiken geen IPv6 toch? Hoe stel je een static IPv6 adres in, en kan het met de Synology?
Was alles nog maar IPv4, wat is het ingewikkeld geworden zeg.
enport_https: The HTTPS port. Used for both web UI and DNS-over-HTTPS.
Ik heb gisteren m'n interne domein aangepast (naar .internal) en een nieuw self-signed certificaat gemaakt. Deze ook in AGH geüpload en sindsdien op m'n iPhone ineens heel traag openen van webpagina's. Met Wireshark zitten kijken, ik zag tijdens het laden van webpagina TLS-handshakes tussen telefoon en AGH. Hij probeerde dus DNS-over-HTTPS te doenIf HTTPS port is configured, AdGuard Home admin interface will be accessible via HTTPS, and it will also provide DNS-over-HTTPS on '/dns-query' location.
Het was mij al eerder opgevallen in de firewall logs dat telefoon van m'n partner ook regelmatig naar de webinterface (dacht ik toen) van AGH probeerde te gaan (maar firewallregel dit tegenhield). Kon daar nooit de vinger achter krijgen, maar dat was dus ook gewoon het proberen van DoH...
Heb AGH nu maar achter NginxProxyManager gezet zodat ik hem via HTTPS kan benaderen. Wat onnozel dat je DoH niet gewoon uit kunt zetten.
[ Voor 17% gewijzigd door ThinkPad op 15-11-2025 09:43 ]
Ik heb zowel de web poort als DoH achter een caddy proxy. Zo werkt het inloggen en DOH zonder foutmeldingen met een geldig certificaat en heb ik er geen omkijken meer naar. Om DoH te activeren moest ik wel een cert opgeven, die is inmiddels verlopen maar caddy zit er toch voor.ThinkPad schreef op zaterdag 15 november 2025 @ 09:29:
Ok, (voor mij) hele irritante manco gevonden: je kan niet HTTPS voor de webinterface of DNS-over-HTTPS server apart gebruiken.
[...]
en
[...]
Ik heb gisteren m'n interne domein aangepast (naar .internal) en een nieuw self-signed certificaat gemaakt. Deze ook in AGH geüpload en sindsdien op m'n iPhone ineens heel traag openen van webpagina's. Met Wireshark zitten kijken, ik zag tijdens het laden van webpagina TLS-handshakes tussen telefoon en AGH. Hij probeerde dus DNS-over-HTTPS te doen![]()
Het was mij al eerder opgevallen in de firewall logs dat telefoon van m'n partner ook regelmatig naar de webinterface (dacht ik toen) van AGH probeerde te gaan (maar firewallregel dit tegenhield). Kon daar nooit de vinger achter krijgen, maar dat was dus ook gewoon het proberen van DoH...
Heb AGH nu maar achter NginxProxyManager gezet zodat ik hem via HTTPS kan benaderen. Wat onnozel dat je DoH niet gewoon uit kunt zetten.
1x Venus-E v153 +LilyGo HA, CT003 V117 | 5040Wp ZO + 4200Wp NW | Zonneplan, 3x25A, Easee Charge Lite | EV 98kWh
Wie is je certificaat provider? Ik heb nu self-signed, maar het is vervelend dat je dit per device moet toevoegen.Mirabis schreef op zondag 16 november 2025 @ 09:30:
[...]
Ik heb zowel de web poort als DoH achter een caddy proxy. Zo werkt het inloggen en DOH zonder foutmeldingen met een geldig certificaat en heb ik er geen omkijken meer naar. Om DoH te activeren moest ik wel een cert opgeven, die is inmiddels verlopen maar caddy zit er toch voor.
Nu heb ik gelukkig 3 clients die het moeten hebben, maar kun je bijvoorbeeld dit doen met LE, en het dan intern gebruiken? Volgens mij kan dat tegenwoordig niet meer.
.internal gaat het niet worden via LE. Die vereisen dat het domein extern benaderbaar is vanuit hun DNS servers om eigenaarschap te kunnen bewijzen.
Ik gebruik intern gewoon mijn publieke DNS naam. Die zet ik via AGH door naar mijn Caddy waarna alles gewoon goed gerouteerd wordt. Of ik nou binnen of buiten zit
you had me at EHLO
Zou je dat iets meer kunnen specificeren? Ik dacht juist dat dit niet meer kon, aangezien hij een soort koppeling maakt met de IP address tegenwoordig?lolgast schreef op zondag 16 november 2025 @ 15:12:
@HollowGamer
.internal gaat het niet worden via LE. Die vereisen dat het domein extern benaderbaar is vanuit hun DNS servers om eigenaarschap te kunnen bewijzen.
Ik gebruik intern gewoon mijn publieke DNS naam. Die zet ik via AGH door naar mijn Caddy waarna alles gewoon goed gerouteerd wordt. Of ik nou binnen of buiten zit
Ik doe dit namelijk wel voor Synology met dynamic-DNS, maar dacht juist dat dit kon doordat hij wel een IP-adres doorgeeft?
LetsEncrypt. Ik heb een publiek domein mijndomein.nl en voor alles binnenshuis dan *.lab.mijndomein.nl. Op die manier hoef ik niks met self-signed certs te doen.HollowGamer schreef op zondag 16 november 2025 @ 12:59:
[...]
Wie is je certificaat provider? Ik heb nu self-signed, maar het is vervelend dat je dit per device moet toevoegen.
Nu heb ik gelukkig 3 clients die het moeten hebben, maar kun je bijvoorbeeld dit doen met LE, en het dan intern gebruiken? Volgens mij kan dat tegenwoordig niet meer.
Draai ook AdguardHome met enkele rewrites om het werkend te maken. *.lab.mijndomein.nl gaat dan naar Caddy toe.
1x Venus-E v153 +LilyGo HA, CT003 V117 | 5040Wp ZO + 4200Wp NW | Zonneplan, 3x25A, Easee Charge Lite | EV 98kWh
Maar je exposed dus wel je webserver?Mirabis schreef op maandag 17 november 2025 @ 09:22:
[...]
LetsEncrypt. Ik heb een publiek domein mijndomein.nl en voor alles binnenshuis dan *.lab.mijndomein.nl. Op die manier hoef ik niks met self-signed certs te doen.
Draai ook AdguardHome met enkele rewrites om het werkend te maken. *.lab.mijndomein.nl gaat dan naar Caddy toe.
Als dit beter in een eigen topic moet, dan hoor ik het wel.
Exposed naar? Nee, Caddy is niet publiekelijk benaderbaar. Het gebruikt Cloudflare dns challenge. Mijn lab hosts zijn enkel via wireguard vpn te bereiken m.u.v 3 hosts die via cloudflared tunnel + zero trust auth lopen.HollowGamer schreef op maandag 17 november 2025 @ 09:28:
[...]
Maar je exposed dus wel je webserver?
Als dit beter in een eigen topic moet, dan hoor ik het wel.
1x Venus-E v153 +LilyGo HA, CT003 V117 | 5040Wp ZO + 4200Wp NW | Zonneplan, 3x25A, Easee Charge Lite | EV 98kWh
Ik heb gisteren Proxmox update uitgevoerd van 9.0.17 > 9.1.1.
Maar na de update merk ik dat ik enkel IP's zie ipv hostnames in AGH...
Toevallig nog personen die dit ervaren?
EDIT: opgelost;
Stom van me, ik had nog poort in opnsense verkeerd geconfigureerd vroeger, en hierdoor liep het dus de mist in.
[ Voor 20% gewijzigd door TheCeet op 20-11-2025 16:45 ]
Ik heb nu een VPS met Ubuntu en Ben mijn 'self' host avontuur echt begonnen. Nu heb ik er adguard home opgezet wat werkt. Ook met een domeinnaam en encrypted gaat goed met een domein foo.bar.com.
Nu wil ik alleen heel graag cliënt Ids als subdomein kunnen doen maar ik had tot nu toe alleen een ssl voor foo.bar.com niet sub.foo.bar.com of een wildcard. Hoofdzakelijk heb ik certbot gebruikt met een dns challenge. Wanneer ik een ssl cert voor zowel foo.bar.com als *.foo.bar.com aanvraag lijkt alles goed te gaan maar adguard home zegt dat de fullchain.cer of .pem invalid zijn.
Ik heb al veel verschillende dingen geprobeerd maar ik doe verder hetzelfde als hoe ik het oorspronkelijke foo.bar.com heb aangevraagd en ingesteld.
Iemand die wildcard/subdomeinen met encryption goed werkend hebben en me hierbij kunnen helpen?
Je kan ook meerdere subdomains maken. Dus zoiets als foo.example.com, bar.example.com, etc. waar dus iedere subdomains staat voor een applicatie.
Dit houdt mij ook tegen Adguard te installeren op een VPS. Intern heb ik allemaal subdomains of zelfs .test domeinen voor applicaties.
Excuses voor mijn berichten ik had een hele domme fout, ik had de certificaten wel aangepast maar niet de server url/domein... Ofwel hij probeerde foo.bar.com te valideren met bar.foo.com, daardoor kwam er invalid. Probleem opgelost, gelukkig heb ik hier niet bijna een hele dag aan getroubleshoot gisteren.HollowGamer schreef op woensdag 26 november 2025 @ 08:47:
@PaulHelper Je gaat hier drie lagen diep, ik denk niet dat dit kan/mag. Mocht het wel kunnen via workarounds, dan zou ik er persoonlijk niet voor kiezen.
Je kan ook meerdere subdomains maken. Dus zoiets als foo.example.com, bar.example.com, etc. waar dus iedere subdomains staat voor een applicatie.
Dit houdt mij ook tegen Adguard te installeren op een VPS. Intern heb ik allemaal subdomains of zelfs .test domeinen voor applicaties.
Dan een ander probleem,ik heb nu een valide wildcard cert met *.foo.bar.com, ik probeer nu met wildcard clientids te gebruiken. Specifiek heb ik een android client op DNS over tls, en ik doe telefoon.foo.bar.com. De DNS werkt en gebruikt adguard home maar krijgt niet de client id telefoon mee. Hoe kan dit komen?
Nog meer noob gedrag, alles aan adguard kant stond goed. Maar DNS van de subdomains *. ... reageerde niet met het de server. Dus alle requests naar die subdomains kwamen nergens uit. Na DNS omzetten werkte het meteen allemaal.
// OUD OPGELOST
Bedankt voor je reactie, maar wat maakt drie lagen diep dan ongeldig? Alles vanuit de certificaat kant lijkt gewoon goed te gaan, en in principe is er geen limiet op subdomein diepte voor zover ik weet. Zou dit dan van adguard home een bottleneck zijn en zo ja heb je daar een bron voor?
Een losse subdomein zou ik voor de toekomst misschien wel willen iets als dns.bar.com maar dan moet ik toch nog steeds diezelfde diepte houden? of ben ik dat nou, iets als client.bar.com dan zou namelijk het hoofddomein al de dns moeten zijn (en ik vind juist dat het een los subdomein is handig denk ik).
Verder is het in bijvoorbeeld een andere dns als nextdns gewoon zo in de manual en gebruik ik het ook 'Piet--Router-ddf99c.dns.nextdns.io' Hoe krijgen zij dit dan wel met encryption goed werkend? Ja natuurlijk niet adguard home maar hun eigen implementatie maar dan zou het een domme limiet van Adguard home zijn.
[ Voor 22% gewijzigd door PaulHelper op 26-11-2025 12:53 ]
you had me at EHLO
@PaulHelper Ik heb een hele tijd een wildcard certificaat gebruikt in combinatie met DNS-over-TLS op Android. Dat gaf tevens de door jouw gewenste Client ID's. Dat werkte prima, behalve dan dat ik redelijk veel bot verkeer kreeg. Het toevoegen van clients onder Client Settings was in mijn geval ook niet voldoende om dit verkeer tegen te houden. Dit moest echt onder DNS Settings. Bijvoorbeeld:
/f/image/PuGAYFmW6tdU21i3oQRm0eQc.png?f=fotoalbum_large)
Alleen was dit eigenlijk ook onvoldoende omdat (zucht...) bots willekeurige termen en woorden gaan proberen.
In Android had ik tegelijkertijd het probleem dat mijn DNS soms onbereikbaar was door mijn split horizon DNS setup. Dus bij een verandering van wifi naar mobiele data of vice versa had ik dan even geen internet
Momenteel gebruik ik buitenshuis een Wireguard tunnel met (twee) AdGuard Home als DNS server. Dat werkt vooralsnog wat betrouwbaarder.
Als je de client achter de server zet, zou het moeten werken zonder wildcard certificaat. Dus: https://example.org/dns-query/my-clientsjongenelen schreef op woensdag 26 november 2025 @ 09:33:
Wildcard cert is echt wel nodig als je client ids wil gebruiken met DoH
Voor DoT en DoQ heb je wel een wildcard nodig.
Zie voor uitleg: ClientID Github
[ Voor 5% gewijzigd door Glassertje op 26-11-2025 12:05 ]
Ook een goed idee ja. Nadeel van mijn setup is dat de eerste dns query nog niet over doh gaat (en de clientid leaked). Dat is daar beter.Glassertje schreef op woensdag 26 november 2025 @ 12:04:
[...]
Als je de client achter de server zet, zou het moeten werken zonder wildcard certificaat. Dus: https://example.org/dns-query/my-client
Voor DoT en DoQ heb je wel een wildcard nodig.
Zie voor uitleg: ClientID Github
you had me at EHLO
Ik dacht namelijk altijd dat het een soort regel was, dat je dat niet wilt (enkel een subdomains). Als dat niet klopt dan hoor ik het graag, ik doe gelukkig niets daarmee voor mijn werk.
Multi-level domeinen (en certificaten) zijn overigens bijzonder gewenstquote: RFC10353.1. Name space definitions
Domain names in messages are expressed in terms of a sequence of labels. Each label is represented as a one octet length field followed by that number of octets. Since every domain name ends with the null label of
the root, a domain name is terminated by a length byte of zero. The high order two bits of every length octet must be zero, and the remaining six bits of the length field limit the label to 63 octets or less.
To simplify implementations, the total length of a domain name (i.e., label octets and label length octets) is restricted to 255 octets or less.
Je zou je dus ook kunnen voorstellen, en dit is niet ongewoon in grotere enterprises, dat je ook verdelingen op regio gaat maken. Denk dan aan *.ams.eu.nodes.example.com. Dat heeft direct als consequentie dat je kunt zien (als beheerder) waar een node zich bevindt en aan welke wet- en regelgeving je jezelf moet houden. Maar ook in welke regio er een storing is, als deze voorkomt.
Ook certificaten zijn in dit geval belangrijk. Het is wederom niet ongewoon om mTLS voor dergelijke machines te gebruiken zodat er geverifieerd kan worden dat de machine echt is die de machine zegt dat die is. En dan heb ik het nog niet over tunnels, jump hosts en weet ik wat. Certificaten kunnen dan echt enorm veel waarde toevoegen, hoe diep dan ook.
Om toch nog even terug te pakken op AdGuard Home. Ik heb hier dus wel een wildcard certificaat voor gebruikt. Het is natuurlijk mogelijk om bijvoorbeeld *.dns.example.com aan te vragen, maar ik heb destijds gekozen voor *.p.example.com waar de p voor private staat. Dit subdomein ging dan langs de gebruikelijke Cloudflare reverse proxy zodat er ook niet-HTTP(S) verkeer overheen kon. Het is dan wel een beetje security through obsecurity, maar dat heb ik voor lief genomen.
Je Android toestellen willen dan bijvoorbeeld niet op de WiFi.
/edit
Het is een lijst die je niet meer moet gebruiken - wat ze zelf aangeven. Je Adguard zal nu alle data van die URL's ophalen.... en dat zijn er nogal wat
# This list is deprecated since 1st of jan 2024
# Please update your oisd blocklist URL
# Visit https://oisd.nl
#
dbl.oisd.nl
dbl.oisd.nl
dblmobile.oisd.nl
shnfpdbl.oisd.nl
dblzero.oisd.nl
dbl2.oisd.nl
hosts.oisd.nl
hostsmobile.oisd.nl
pac.oisd.nl
[ Voor 54% gewijzigd door Vorkie op 30-11-2025 10:10 ]
/f/image/zPMdOffAi7r3F7rAxgBtn2Bv.png)
edit: Volgens OISD.nl staat npo.nl op geen enkele block list…
[ Voor 9% gewijzigd door ronaldtb op 30-11-2025 10:50 ]
Er is een verschil tussen het al dan niet op een blocklist staan en adult content filteren. En dat laatste doe jij zo te zien.ronaldtb schreef op zondag 30 november 2025 @ 10:24:
edit: Volgens OISD.nl staat npo.nl op geen enkele block list…
Voeg een uitzondering toe voor de specifieke client (beste optie), je gehele netwerk of schakel de blocklost uit (slechtste optie).
Ongevraagde verzoeken per DM beantwoord ik niet, sorry
Dat klopt en dat weet ik, maar dan staat dat er bij. Dit werd echt geblokkeerd door de OISD NSFW list.jurroen schreef op maandag 1 december 2025 @ 02:28:
[...]
Er is een verschil tussen het al dan niet op een blocklist staan en adult content filteren. En dat laatste doe jij zo te zien.
Voeg een uitzondering toe voor de specifieke client (beste optie), je gehele netwerk of schakel de blocklost uit (slechtste optie).
Update: De laatste paar dagen geen problemen meer gehad met podcasts en ook de kinderen hebben geen problemen meer met de NPO Zapp app.
[ Voor 12% gewijzigd door ronaldtb op 03-12-2025 07:48 ]
Mijn bedoeling is vnl. om andere upstream DNS-servers af te dwingen afhankelijk van of papa en mama surfen of de (opgroeiende) kids waarbij voor die laatste safesearch e.d. verplicht is.
Om te vermijden dat ze de boel belazeren (wat ze uiteraard wél kunnen via hun mobiele verbinding, oeps!) staan de standaard-instellingen van AGH op kids-proof.
Doe ik hetzelfde request maar dan vanaf het IPv4-adres van de client, dan werkt het zoals verwacht.
Ik zie dat er wel een aantal issues zijn met IPv6, zowel in deze draad als op de AGH-Github, maar louter daarvoor op de desbetreffende client(s) IPv6 terug uitzetten is toch een stap te ver.
Iemand hier die wél IPv6-cliëntinstellingen aan de praat gekregen heeft?
Heb gisteren geupdate, merk dat de Average processing speed omhoog is gegaan. Van 0.5ms naar 15ms.
/f/image/6IHTbOpb7FnFYqBUdQscw42f.png?f=fotoalbum_medium)
Bekend issue blijkbaar: https://github.com/AdguardTeam/AdGuardHome/issues/8148
Volgende keer wacht ik wel eventjes met updaten.
Edit, backup terug gezet vanuit Tuxis PBS server. Heb ik gelijk de backup getest, volgende keer maar even een snapshot maken voordat ik upgrade.
[ Voor 8% gewijzigd door Harmen op 05-12-2025 15:07 ]
Whatever.
https://github.com/Adguar...me/releases/tag/v0.107.71
[ Voor 7% gewijzigd door FLA NL op 08-12-2025 16:31 ]
Deze fix cache issues. Had ze zelf niet, maar kennelijk kwam het bij sommige setups voor.
[ Voor 14% gewijzigd door Tweakx op 09-12-2025 11:41 ]
Ik heb dit anders gedaan.Tweakx schreef op dinsdag 9 december 2025 @ 11:40:
Vraagje! Ik heb een Zyxel modem/router van Odido. Bij DNS Waarden zet ik als IP 1 het IP-adres wat Adguard in HA aangeeft. Helaas wordt deze automatisch weer op 1.1.1.1 gezet. Wat is hiervoor een fix? Als ik 1.1.1.1 als IP 2 neerzet gooit die deze ook weer naar 1 helaas.
Als DHCP geef ik de lokale Adguard instance op, en de WAN laat ik zijn hoe het is. Daardoor weet je ook welke cliënt een request doet, anders komt het allemaal bij het WAN samen.
Dank! Ga ik proberen.HollowGamer schreef op dinsdag 9 december 2025 @ 11:42:
[...]
Ik heb dit anders gedaan.
Als DHCP geef ik de lokale Adguard instance op, en de WAN laat ik zijn hoe het is. Daardoor weet je ook welke cliënt een request doet, anders komt het allemaal bij het WAN samen.
Als je wilt, kan ik altijd meer delen over mijn setup.
Heel graag! Ik kom er nog niet helemaal uit. Hij geeft bij DHCP aan dat het IP adres van HA nog niet is vrijgegeven/vernieuwd.HollowGamer schreef op dinsdag 9 december 2025 @ 12:08:
[...]
Als je wilt, kan ik altijd meer delen over mijn setup.
Kom morgen bij je terug. Als het een static is, alles even uitrekken en dan na 10 minuten weer inschakelen.Tweakx schreef op dinsdag 9 december 2025 @ 14:12:
[...]
Heel graag! Ik kom er nog niet helemaal uit. Hij geeft bij DHCP aan dat het IP adres van HA nog niet is vrijgegeven/vernieuwd.
Werkt helaas niet! Maar met DCHP wijs je alleen een static IP toe, toch? Het verkeer gaat niet ineens via dat IP? Of begrijp ik het verkeerd?HollowGamer schreef op dinsdag 9 december 2025 @ 23:24:
[...]
Kom morgen bij je terug. Als het een static is, alles even uitrekken en dan na 10 minuten weer inschakelen.
Dit heb ik ingesteld op het modem van Odido (statische DHCP):Tweakx schreef op woensdag 10 december 2025 @ 09:10:
[...]
Werkt helaas niet! Maar met DCHP wijs je alleen een static IP toe, toch? Het verkeer gaat niet ineens via dat IP? Of begrijp ik het verkeerd?
/f/image/TkhL76vMA8rauQr3hXDZNrEv.png?f=fotoalbum_large)
Deze gaan naar mijn NAS (beide poorten):
/f/image/zgLunAoSoPe5xs9oeJpifhml.png?f=fotoalbum_large)
Het belangrijkste is dat je op de AGH-server niet terugloopt naar de router. Ik heb daar beide DNS-servers ingesteld op 127.0.0.1. Daar stel je ook de upstream DNS-servers op naar 1.1.1.1 bijvoorbeeld.
Mocht je meer willen weten, laat mij gerust weten.
Bedankt! Ik ga vanmiddag even ernaar kijkenHollowGamer schreef op woensdag 10 december 2025 @ 10:01:
[...]
Dit heb ik ingesteld op het modem van Odido (statische DHCP):
[Afbeelding]
Deze gaan naar mijn NAS (beide poorten):
[Afbeelding]
Het belangrijkste is dat je op de AGH-server niet terugloopt naar de router. Ik heb daar beide DNS-servers ingesteld op 127.0.0.1. Daar stel je ook de upstream DNS-servers op naar 1.1.1.1 bijvoorbeeld.
Mocht je meer willen weten, laat mij gerust weten.
Het werkt! Bij toegestane gebruikers had ik een IP staan en die klopte niet meer, daardoor werkte het geheel niet. Dank!HollowGamer schreef op woensdag 10 december 2025 @ 10:01:
[...]
Dit heb ik ingesteld op het modem van Odido (statische DHCP):
[Afbeelding]
Deze gaan naar mijn NAS (beide poorten):
[Afbeelding]
Het belangrijkste is dat je op de AGH-server niet terugloopt naar de router. Ik heb daar beide DNS-servers ingesteld op 127.0.0.1. Daar stel je ook de upstream DNS-servers op naar 1.1.1.1 bijvoorbeeld.
Mocht je meer willen weten, laat mij gerust weten.
De totale gemiddelde procestijd zit op 42 ms.
[ Voor 8% gewijzigd door zunrob op 17-12-2025 22:13 ]
De meeste responses zijn moeilijk te bepalen. Ik zit op 10ms, maar bij lokaal development kunnen die weer veel hoger liggen.zunrob schreef op woensdag 17 december 2025 @ 22:10:
Ik merk de laatste tijd wat vertraging bij het browsen. Nu kijk ik net in het systeem zie ik bij upstream een responsetijd van bijna 1 seconde staan bij 'ip-adres-router:53'. Ik gebruik een Fritzbox 4060, maar weet niet zo goed hoe ik dit kan verminderen?
De totale gemiddelde procestijd zit op 42 ms.
Wat zijn precies je device specs, gebruik je caching (ook voor blokkeren), en welke heb je upstream ingesteld? Die van Quad9 is bijvoorbeeld vrij langzaam.
Mijn reguliere upstream servers zijn snel (9 ms), alleen in die lijst staat dus ook het ip-adres van mijn router met poort 53 ertussen. Dat snap ik eigenlijk niet, ik heb dus nooit toegevoegd. Dat is diegene die zo langzaam is.HollowGamer schreef op woensdag 17 december 2025 @ 22:27:
[...]
De meeste responses zijn moeilijk te bepalen. Ik zit op 10ms, maar bij lokaal development kunnen die weer veel hoger liggen.
Wat zijn precies je device specs, gebruik je caching (ook voor blokkeren), en welke heb je upstream ingesteld? Die van Quad9 is bijvoorbeeld vrij langzaam.
om de IP's te vertalen naar hostnames?
Verwijderd
Daar is Adguard Home dacht ik niet voor bedoeld.Verwijderd schreef op dinsdag 23 december 2025 @ 14:05:
Ik zou graag Adguard willen proberen in plaats van Pi-hole. Nu bestaat mijn denied list uit slechts 1 regex, namelijk .*. Hiermee blokkeer ik al het verkeer, maar laat alleen verkeer toe naar domeinen op mijn toegestane lijst. Is dit ook op Adguard gemakkelijk in te regelen? Begin 2020 gekozen voor Pi-Hole omdat het daar wat gemakkelijker ging, maar ik ben mijn keuze aan het heroverwegen.
Geen idee wat je wilt met een allowlist, maar dat was niet je vraag.
Verwijderd
Op de allowlist wil ik de domeinen kwijt die ik wil kunnen benaderen, eventueel met regex. Bij Pi-hole blokkeer ik initieel alles door .* op mijn blokkeerlijst te plaatsen. Domeinen die ik toegankelijk wil hebben, staan op de allowlist.HollowGamer schreef op dinsdag 23 december 2025 @ 15:09:
[...]
Daar is Adguard Home dacht ik niet voor bedoeld.
Geen idee wat je wilt met een allowlist, maar dat was niet je vraag.
Maar jammer dat dat niet kan.
Maar als je een beetje gaat internetteren weet je toch van te voren niet op welke sites je terecht wilt komen?Verwijderd schreef op dinsdag 23 december 2025 @ 17:12:
[...]
Domeinen die ik toegankelijk wil hebben, staan op de allowlist.
Ik kan zo 1,2,3 niet zien waarom je niet alles zou kunnen blokkeren.
Verwijderd
Wij bezoeken vrijwel altijd dezelfde websites en de gebruikte services zijn ook vrijwel altijd hetzelfde. In eerste instantie veel instelwerk, maar werkt prima.Baf schreef op dinsdag 23 december 2025 @ 17:36:
[...]
Maar als je een beetje gaat internetteren weet je toch van te voren niet op welke sites je terecht wilt komen?
Je bent dan ook gewoon gedekt wanneer Meta of Alphabet weer een ander (sub)domein gaat gebruiken. Bij enkel een blocklist loop je altijd achter de feiten aan. Bovendien biedt het ook iets aan extra veiligheid. Urls bij phishingmails werken niet. Mijn partnet klikte eens op rab0bank.nl, maar door alleen whitelists toe te staan, werkte dat niet.
Bedankt. Destijds kreeg ik het niet lekker aan de praat. Ik zal er eens naar kijken!Mawlana schreef op dinsdag 23 december 2025 @ 17:56:
https://adguard-dns.io/kb/general/dns-filtering-syntax/
Ik kan zo 1,2,3 niet zien waarom je niet alles zou kunnen blokkeren.
Het klinkt paranoïde en te controleert (ook voor de andere). Maar okay, ik geloof niet dat dit werkt aangezien steeds meer over dynamische DNS adressen gaat.Verwijderd schreef op dinsdag 23 december 2025 @ 18:54:
[...]
Wij bezoeken vrijwel altijd dezelfde websites en de gebruikte services zijn ook vrijwel altijd hetzelfde. In eerste instantie veel instelwerk, maar werkt prima.
Je bent dan ook gewoon gedekt wanneer Meta of Alphabet weer een ander (sub)domein gaat gebruiken. Bij enkel een blocklist loop je altijd achter de feiten aan. Bovendien biedt het ook iets aan extra veiligheid. Urls bij phishingmails werken niet. Mijn partnet klikte eens op rab0bank.nl, maar door alleen whitelists toe te staan, werkte dat niet.
[...]
Bedankt. Destijds kreeg ik het niet lekker aan de praat. Ik zal er eens naar kijken!
Verwijderd
Eerste kan ik inkomen, tweede niet. Wij voegen beiden domeinen toe aan de whitelist. Dus dat controleren valt best mee. Ik weet ook niet waar zij tegen aanloopt. Ik gebruik GrapheneOS en zij iOS. Dus dat mogen we beiden lekker zelf doen.HollowGamer schreef op dinsdag 23 december 2025 @ 19:21:
[...]
Het klinkt paranoïde en te controleert (ook voor de andere).
[ Voor 16% gewijzigd door Verwijderd op 23-12-2025 19:57 ]
https://github.com/Adguar...ome/wiki/Hosts-Blocklists
De link van Mawlana is van AdGuard DNS cloud oplossing.
Je gaat tegen issues als iCloud aanlopen, maar ook security updates. Dus of je nu echt zoveel meer beschermd bent, twijfel ik heel erg aan.Verwijderd schreef op dinsdag 23 december 2025 @ 19:54:
[...]
Eerste kan ik inkomen, tweede niet. Wij voegen beiden domeinen toe aan de whitelist. Dus dat controleren valt best mee. Ik weet ook niet waar zij tegen aanloopt. Ik gebruik GrapheneOS en zij iOS. Dus dat mogen we beiden lekker zelf doen.
Ik zou persoonlijk de anti phishing filters aanzetten van Adguard Home, en die laten updaten elke 4 uur (als het echt zo belangrijk is, die van mij is om de 24 uur).
Het is helaas niet meer de jaren 90, tegenwoordig heeft een allow list meer nadelen dan voordelen. Verder geeft het wel een soort controle, want je weet immers wie wat mag bezoeken. Vind dat nogal vreemd, hopelijk is het voor andere geen problemen wat ze willen doen.
[ Voor 9% gewijzigd door HollowGamer op 23-12-2025 23:13 ]
Verwijderd
Problemen vallen heel erg mee. Updates komen gewoon binnen en iCloud gebruiken we niet. Voor backups hebben we een thuisserver staan, kunnen we onafhankelijk van de aanbieder op backuppen.HollowGamer schreef op dinsdag 23 december 2025 @ 23:11:
[...]
Je gaat tegen issues als iCloud aanlopen, maar ook security updates. Dus of je nu echt zoveel meer beschermd bent, twijfel ik heel erg aan.
Ik zou persoonlijk de anti phishing filters aanzetten van Adguard Home, en die laten updaten elke 4 uur (als het echt zo belangrijk is, die van mij is om de 24 uur).
Het is helaas niet meer de jaren 90, tegenwoordig heeft een allow list meer nadelen dan voordelen. Verder geeft het wel een soort controle, want je weet immers wie wat mag bezoeken. Vind dat nogal vreemd, hopelijk is het voor andere geen problemen wat ze willen doen.
Verder beiden een desktop met Linux erop. Zij Debian, ik Arch. Dus daarvan staan de packagerepo's ook gewoon op de whitelist. Dus updates komen daar ook binnen.
En die anderen? Mensen die bij ons op de wifi komen, kunnen inderdaad niets met Whatsapp of Google. Dat weten ze ook. Maar goed, dat is niet ons probleem. Wanneer ik bij vrienden plain op de wifi zit, kom ik ook vaak niet bij alles wat ik zelf gebruik/bezoek door hun allowlist. Meeste gasten hebben 4g/5g of een eigen Pi-hole draaien met remote verbinding via vpn.
Ik heb nu onderstaande erin staan maar wie weet is dit wel helemaal fout.
tls://one.one.one.one
https://dns.cloudflare.com/dns-query
tls://dns.quad9.net
https://dns.quad9.net/dns-query
Ik gebruik altijd de https of quick. Voor nu heb ik er drie: ad, 1.1.1.1, Quad9.qwasd schreef op vrijdag 30 januari 2026 @ 18:42:
Wat gebruiken jullie als upstream servers?
Ik heb nu onderstaande erin staan maar wie weet is dit wel helemaal fout.
[...]
Ik gebruik de DNScrypt Proxy in OPNsense en heb er dus 127.0.0.1:5335 staan.qwasd schreef op vrijdag 30 januari 2026 @ 18:42:
Wat gebruiken jullie als upstream servers?
Ik heb nu onderstaande erin staan maar wie weet is dit wel helemaal fout.
[...]
Dat moet je toch ergens anders invullen? Krijg nu geen loop?Villager schreef op vrijdag 30 januari 2026 @ 19:08:
[...]
Ik gebruik de DNScrypt Proxy in OPNsense en heb er dus 127.0.0.1:5335 staan.
Adguard krijgt DNS requests op poort 53 en stuurt requests door naar DNScrypt welke luistert op 0.0.0.0:5335. Gaat prima hoor.HollowGamer schreef op vrijdag 30 januari 2026 @ 20:44:
[...]
Dat moet je toch ergens anders invullen? Krijg nu geen loop?
maar in dnscrypt moet je dan ook weer een upstream server zetten. kan je deze stap niet overslaan en de upstream rechtstreeks in adguard zetten. ik heb ook wel met dnscrypt gewerkt maar zie niet 1-2-3 voordelen tov dns over https vanuit adguardVillager schreef op vrijdag 30 januari 2026 @ 21:16:
[...]
Adguard krijgt DNS requests op poort 53 en stuurt requests door naar DNScrypt welke luistert op 0.0.0.0:5335. Gaat prima hoor.
In DNScrypt heb ik geen DNS servers ingesteld. Dat doet hij zelf op basis van de instellingen die je zet.tomdh76 schreef op zaterdag 31 januari 2026 @ 14:03:
[...]
maar in dnscrypt moet je dan ook weer een upstream server zetten. kan je deze stap niet overslaan en de upstream rechtstreeks in adguard zetten. ik heb ook wel met dnscrypt gewerkt maar zie niet 1-2-3 voordelen tov dns over https vanuit adguard
ok, maar dan zou je die servers net zo goed toch in adguard kunnen zetten.Villager schreef op zaterdag 31 januari 2026 @ 14:51:
[...]
In DNScrypt heb ik geen DNS servers ingesteld. Dat doet hij zelf op basis van de instellingen die je zet.
Jeptomdh76 schreef op zaterdag 31 januari 2026 @ 15:35:
[...]
ok, maar dan zou je die servers net zo goed toch in adguard kunnen zetten.
Enige wat DNSCrypt in mijn ogen doet is het nóg simpeler maken, maar je geeft ook controle uit handen. De DoH/TLS servers van Cloudflare of Adguard instellen in AGH levert hetzelfde op met een schakel minder
Dat is zeker zo, Maar je maakt het daarmee ook redelijk 'statisch'. DNScrypt kiest zelf de juiste DNS servers en dat kan dus steeds een andere 'set' van DNS servers zijn. Geeft in mijn ogen wat betere privacy. En volgens mij krijg je ook steeds de, op dat moment, snelste servers. De extra stap geeft nauwelijks vertraging. Ik heb in Adguard een gemiddelde responstijd van rond de 10ms.lolgast schreef op zaterdag 31 januari 2026 @ 16:02:
[...]
Jep![]()
Enige wat DNSCrypt in mijn ogen doet is het nóg simpeler maken, maar je geeft ook controle uit handen. De DoH/TLS servers van Cloudflare of Adguard instellen in AGH levert hetzelfde op met een schakel minder
Ik probeer niks te pushen ofzo. Het is gewoon een optie om het in te richten en dit is hoe ik het heb gedaan
[ Voor 9% gewijzigd door Villager op 01-02-2026 07:22 ]
en gebruik je geen enkele blok list in dnscrypt? Waar ik een beetje tegen aan liep is dat ik van mijn kids wel eens hoorde dat iets geblokt was, dan moest ik gaan kijken in adguard, dnscrypt en ook nog zenarmor waar het geblokt werd.Villager schreef op zondag 1 februari 2026 @ 07:18:
[...]
Dat is zeker zo, Maar je maakt het daarmee ook redelijk 'statisch'. DNScrypt kiest zelf de juiste DNS servers en dat kan dus steeds een andere 'set' van DNS servers zijn. Geeft in mijn ogen wat betere privacy. En volgens mij krijg je ook steeds de, op dat moment, snelste servers. De extra stap geeft nauwelijks vertraging. Ik heb in Adguard een gemiddelde responstijd van rond de 10ms.
Ik probeer niks te pushen ofzo. Het is gewoon een optie om het in te richten en dit is hoe ik het heb gedaan
Als je in AGH meerdere upstream servers invult heb je diezelfde set aan potentiële DNS servers toch? Het is aan jou om te kiezen of je op basis van loadbalancing gebruik van ze wilt maken of de beste/snelste.Villager schreef op zondag 1 februari 2026 @ 07:18:
[...]
Dat is zeker zo, Maar je maakt het daarmee ook redelijk 'statisch'. DNScrypt kiest zelf de juiste DNS servers en dat kan dus steeds een andere 'set' van DNS servers zijn. Geeft in mijn ogen wat betere privacy. En volgens mij krijg je ook steeds de, op dat moment, snelste servers. De extra stap geeft nauwelijks vertraging. Ik heb in Adguard een gemiddelde responstijd van rond de 10ms.
Ik probeer niks te pushen ofzo. Het is gewoon een optie om het in te richten en dit is hoe ik het heb gedaan
Hoe dan ook, zoveel mensen, zoveel wensen. Ik gebruik mijn eigen Technitium als upstream server waardoor ik überhaupt niet afhankelijk ben van Cloudflare/Cisco/Google. En die is net als AGH behoorlijk inzichtelijk
Nee, ik gebruik de blocklists van AGH. En gebruik dus ook Unbound niet meer. Maakt het een stuk simpeler zo. Zenarmor heb ik ook verwijderd. Heb nog nooit enig verschil gemerkt als het aan stond. Ook de logfiles lieten niets bijzonders zien. Kennelijk voegt het voor mij dus niks toe.tomdh76 schreef op zondag 1 februari 2026 @ 11:28:
[...]
en gebruik je geen enkele blok list in dnscrypt? Waar ik een beetje tegen aan liep is dat ik van mijn kids wel eens hoorde dat iets geblokt was, dan moest ik gaan kijken in adguard, dnscrypt en ook nog zenarmor waar het geblokt werd.
[ Voor 15% gewijzigd door Villager op 01-02-2026 11:46 ]
In AGH kan je ook gewoon de DNS rootservers plaatsen als upstream natuurlijk. Ben je ook niet afhankelijk van nog een extra docker?lolgast schreef op zondag 1 februari 2026 @ 11:39:
[...]
Als je in AGH meerdere upstream servers invult heb je diezelfde set aan potentiële DNS servers toch? Het is aan jou om te kiezen of je op basis van loadbalancing gebruik van ze wilt maken of de beste/snelste.
Hoe dan ook, zoveel mensen, zoveel wensen. Ik gebruik mijn eigen Technitium als upstream server waardoor ik überhaupt niet afhankelijk ben van Cloudflare/Cisco/Google. En die is net als AGH behoorlijk inzichtelijk
https://www.iana.org/domains/root/servers voor de lijst.
ik heb nu een dagje dnscrypt staan (op opnsense) en dan in adguard 127.0.0.1:5350 als enig upstream server maar bij mij is responstijd 75 ms. Terwijl ik de dnscrypt logs als snelste provider 'he' zie staan (rtt: 3ms). Ik heb in dnscrypt ipv4, ipv6, use dnscrypt servers en dns-over https servers aangevinkt. Verder niets gespecificeerd. In adguard staat het op volume balanceren. Is er nog iets wat ik zou moeten aanpassen?Villager schreef op zondag 1 februari 2026 @ 07:18:
[...]
Dat is zeker zo, Maar je maakt het daarmee ook redelijk 'statisch'. DNScrypt kiest zelf de juiste DNS servers en dat kan dus steeds een andere 'set' van DNS servers zijn. Geeft in mijn ogen wat betere privacy. En volgens mij krijg je ook steeds de, op dat moment, snelste servers. De extra stap geeft nauwelijks vertraging. Ik heb in Adguard een gemiddelde responstijd van rond de 10ms.
Ik probeer niks te pushen ofzo. Het is gewoon een optie om het in te richten en dit is hoe ik het heb gedaan
En je cache settings in DNScrypt?tomdh76 schreef op dinsdag 3 februari 2026 @ 20:25:
[...]
ik heb nu een dagje dnscrypt staan (op opnsense) en dan in adguard 127.0.0.1:5350 als enig upstream server maar bij mij is responstijd 75 ms. Terwijl ik de dnscrypt logs als snelste provider 'he' zie staan (rtt: 3ms). Ik heb in dnscrypt ipv4, ipv6, use dnscrypt servers en dns-over https servers aangevinkt. Verder niets gespecificeerd. In adguard staat het op volume balanceren. Is er nog iets wat ik zou moeten aanpassen?
die stond op 512, heb hem nu op 1024 gezet. Heb je cache ook nog aan in Adguard?Villager schreef op dinsdag 3 februari 2026 @ 20:30:
[...]
En je cache settings in DNScrypt?
[Afbeelding]
vraag: wat is het effect/nut om die op te hogen van 512 naar 1024MB ?Villager schreef op dinsdag 3 februari 2026 @ 20:30:
[...]
En je cache settings in DNScrypt?
[Afbeelding]
(draai zelf ook dnscrypt in opnsense i.c.m. AGH)
Ja..tomdh76 schreef op dinsdag 3 februari 2026 @ 21:18:
[...]
die stond op 512, heb hem nu op 1024 gezet. Heb je cache ook nog aan in Adguard?
bij mijn weten werkt dit niet.Vorkie schreef op zondag 1 februari 2026 @ 11:44:
[...]
In AGH kan je ook gewoon de DNS rootservers plaatsen als upstream natuurlijk. Ben je ook niet afhankelijk van nog een extra docker?
https://www.iana.org/domains/root/servers voor de lijst.
AGH is forwarder en als je de IP's van rootserver gebruikt moet dit verwerkt worden door resolver (zoals Unbound, of andere)
Ik heb op Adguard Dashboard pagina 2 waarden die de responsetijden weergeven.tomdh76 schreef op dinsdag 3 februari 2026 @ 20:25:
[...]
ik heb nu een dagje dnscrypt staan (op opnsense) en dan in adguard 127.0.0.1:5350 als enig upstream server maar bij mij is responstijd 75 ms. Terwijl ik de dnscrypt logs als snelste provider 'he' zie staan (rtt: 3ms). Ik heb in dnscrypt ipv4, ipv6, use dnscrypt servers en dns-over https servers aangevinkt. Verder niets gespecificeerd. In adguard staat het op volume balanceren. Is er nog iets wat ik zou moeten aanpassen?
Onder Algemene Statistieken > Gemiddelde procestijd: 6 ms
en onder Gemiddelde upstream responstijd> Gemiddelde upstream responstijd voor de afgelopen 24 uren
127.0.0.1:5335 32 ms
Zelf gebruik ik wel de filter die kijkt op Android SDK niveau, en staat de DNS prive-modes uit. Zou moeten kijken of ik geen VPN of de Synlogy kan installeren, Tailscale lijkt me wel leuk als ik ook extern zit.
Ik heb gewoon een Ubuntu container met Wireguard + PiVPN en laat m'n mobiel altijd automatisch een verbinding naar huis opzetten met de 'WG tunnel' App, zodra ik de deur uitstap. Kan dus altijd veilig en advertentievrij internet op en hoef daarvoor verder niks op m'n mobiel in te stellen . Maar Tailscale zal ook prima werken, al ben je dan wel weer afhankelijk van een clouddienst.HollowGamer schreef op vrijdag 6 februari 2026 @ 22:17:
Ik merkte trouwens wel echt het verschil. Dacht dat het niet veel deed, totdat ik op 5G SofaScore ging openen, en meteen een ad kreeg.
Zelf gebruik ik wel de filter die kijkt op Android SDK niveau, en staat de DNS prive-modes uit. Zou moeten kijken of ik geen VPN of de Synlogy kan installeren, Tailscale lijkt me wel leuk als ik ook extern zit.
[ Voor 3% gewijzigd door Villager op 07-02-2026 14:06 ]
DHCP DNS:
- 1 DNS ip adres mogelijk
- alle devices individueel traceerbaar in AdGuard
WAN DNS:
- 2 DNS ip adressen mogelijk
- fallback naar openbare DNS
- Adguard ziet alleen Fritzbox, dus geen instellingen of logging per device mogelijk
Ik heb nu ingesteld dat de DHCP DNS het ip adres van de Fritzbox router is. De WAN DNS heb ik ingesteld op AdGuard (zowel de NAS als de Raspberry Pi). In deze opstelling heb ik maximale betrouwbaarheid, maar dus geen logging op device niveau.
Kan iemand mij vertellen wat best practice is, hoe hebben anderen dit geregeld?
Ik heb het per device via mijn modem als DHCP optie.Roog1317 schreef op zondag 8 februari 2026 @ 11:42:
Ik draai al een tijdje AdGuard Home naar tevredenheid op mijn Synology NAS. Dit weekend heb ik een 2de installatie op een Raspberry Pi toegevoegd aan mijn netwerk. Mijn voornaamste argument voor een 2de DNS server is redundantie. Verder heb ik een Fritzbox 7690 router. Hier kun je DNS op niveau van DHCP en WAN instellen.
DHCP DNS:
- 1 DNS ip adres mogelijk
- alle devices individueel traceerbaar in AdGuard
WAN DNS:
- 2 DNS ip adressen mogelijk
- fallback naar openbare DNS
- Adguard ziet alleen Fritzbox, dus geen instellingen of logging per device mogelijk
Ik heb nu ingesteld dat de DHCP DNS het ip adres van de Fritzbox router is. De WAN DNS heb ik ingesteld op AdGuard (zowel de NAS als de Raspberry Pi). In deze opstelling heb ik maximale betrouwbaarheid, maar dus geen logging op device niveau.
Kan iemand mij vertellen wat best practice is, hoe hebben anderen dit geregeld?
Er is niet echt een best practice denk ik, het is afhankelijk van je netwerk en wensen.
WAN (en dus automatisch alle vlans) Doh via Quad9 en Cloudflare (dus encrypted dns op mijn Unifi Cloud Gateway Fiber).Roog1317 schreef op zondag 8 februari 2026 @ 11:42:
Ik draai al een tijdje AdGuard Home naar tevredenheid op mijn Synology NAS. Dit weekend heb ik een 2de installatie op een Raspberry Pi toegevoegd aan mijn netwerk. Mijn voornaamste argument voor een 2de DNS server is redundantie. Verder heb ik een Fritzbox 7690 router. Hier kun je DNS op niveau van DHCP en WAN instellen.
DHCP DNS:
- 1 DNS ip adres mogelijk
- alle devices individueel traceerbaar in AdGuard
WAN DNS:
- 2 DNS ip adressen mogelijk
- fallback naar openbare DNS
- Adguard ziet alleen Fritzbox, dus geen instellingen of logging per device mogelijk
Ik heb nu ingesteld dat de DHCP DNS het ip adres van de Fritzbox router is. De WAN DNS heb ik ingesteld op AdGuard (zowel de NAS als de Raspberry Pi). In deze opstelling heb ik maximale betrouwbaarheid, maar dus geen logging op device niveau.
Kan iemand mij vertellen wat best practice is, hoe hebben anderen dit geregeld?
Voor de vlans waar ik Adguard Home wil gebruiken dns server gedefinieerd. Ik heb niet op alle vlans Adguard Home nodig en als er toch iets aan de hand is met de Adguard Home servers houden de Gateway en bepaalde vlans / onderliggende services wel een internetverbinding.
[ Voor 8% gewijzigd door qwasd op 08-02-2026 16:40 ]
Ik gebruik keepalived met 2 raspberry pi's en AGH. Met 1 virtueel ip zijn beide Pi's. Verbonden. Als de ene niet reageert, dan reageert de andere. @stormfly heeft de config hier in het topic gepost.Roog1317 schreef op zondag 8 februari 2026 @ 11:42:
Ik draai al een tijdje AdGuard Home naar tevredenheid op mijn Synology NAS. Dit weekend heb ik een 2de installatie op een Raspberry Pi toegevoegd aan mijn netwerk. Mijn voornaamste argument voor een 2de DNS server is redundantie. Verder heb ik een Fritzbox 7690 router. Hier kun je DNS op niveau van DHCP en WAN instellen.
DHCP DNS:
- 1 DNS ip adres mogelijk
- alle devices individueel traceerbaar in AdGuard
WAN DNS:
- 2 DNS ip adressen mogelijk
- fallback naar openbare DNS
- Adguard ziet alleen Fritzbox, dus geen instellingen of logging per device mogelijk
Ik heb nu ingesteld dat de DHCP DNS het ip adres van de Fritzbox router is. De WAN DNS heb ik ingesteld op AdGuard (zowel de NAS als de Raspberry Pi). In deze opstelling heb ik maximale betrouwbaarheid, maar dus geen logging op device niveau.
Kan iemand mij vertellen wat best practice is, hoe hebben anderen dit geregeld?
Dat heb ik inderdaad ook zo draaien (2x AGH via Docker). Het werkt behoorlijk goed, maar met 1 beperking: het is afhankelijk van het host ip adres. Dus als je host wel draait, maar de Master AGH container functioneert niet goed, dan komt de Slave niet in actie. En dus loopt de DNS resolving dan alsnog spaak. Ik heb van alles geprobeerd, maar krijg een extra controle hierop niet aan de praat.Glassertje schreef op maandag 9 februari 2026 @ 14:45:
[...]
Ik gebruik keepalived met 2 raspberry pi's en AGH. Met 1 virtueel ip zijn beide Pi's. Verbonden. Als de ene niet reageert, dan reageert de andere. @stormfly heeft de config hier in het topic gepost.
Ik gebruik geen docker op de pizordaz schreef op maandag 9 februari 2026 @ 16:09:
[...]
Dat heb ik inderdaad ook zo draaien (2x AGH via Docker). Het werkt behoorlijk goed, maar met 1 beperking: het is afhankelijk van het host ip adres. Dus als je host wel draait, maar de Master AGH container functioneert niet goed, dan komt de Slave niet in actie. En dus loopt de DNS resolving dan alsnog spaak. Ik heb van alles geprobeerd, maar krijg een extra controle hierop niet aan de praat.
Beide pi's zijn in keepalived BACKUP zodat ik nopreempt optie kan gebruiken. Zo heb je dan geen onnodige VIP-wissels. Vind het niet nodig als de 1e AGH install terug reageert, dat die dan weer overspringt. Dit gebeurd pas als de andere AGH niet reageert. En tot nu toe werkt het vlekkeloos.
Dat is wel mogelijk hoor, maar dan moet je zelf een healthcheck scriptje maken voor AGH. In bijvoorbeeld /etc/keepalived/check_service.sh. Die moet executable zijn.zordaz schreef op maandag 9 februari 2026 @ 16:09:
[...]
Dat heb ik inderdaad ook zo draaien (2x AGH via Docker). Het werkt behoorlijk goed, maar met 1 beperking: het is afhankelijk van het host ip adres. Dus als je host wel draait, maar de Master AGH container functioneert niet goed, dan komt de Slave niet in actie. En dus loopt de DNS resolving dan alsnog spaak. Ik heb van alles geprobeerd, maar krijg een extra controle hierop niet aan de praat.
1
2
3
4
5
6
7
8
9
10
11
| #!/bin/bash HOST=127.0.0.1 PORT=3000 nc -z "$HOST" "$PORT" >/dev/null 2>&1 if [ $? -eq 0 ]; then exit 0 # OK else exit 1 # FAIL fi |
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
| vrrp_script chk_service { script "/etc/keepalived/check_service.sh" interval 2 timeout 2 fall 2 rise 2 } vrrp_instance VI_1 { state MASTER interface eth0 virtual_router_id 51 priority 200 advert_int 1 virtual_ipaddress { 10.0.0.100 } track_script { chk_service } } |
gemiddelde procestijd is bij mij 19 ms en 127.0.0.1:5335 445 ms. Vooral deze laatste vind ik vrij traag. Misschien dat het aan Ipv6 ligt. Die heb jij uit staan en gebruik ik wel.Villager schreef op donderdag 5 februari 2026 @ 17:49:
[...]
Ik heb op Adguard Dashboard pagina 2 waarden die de responsetijden weergeven.
Onder Algemene Statistieken > Gemiddelde procestijd: 6 ms
en onder Gemiddelde upstream responstijd> Gemiddelde upstream responstijd voor de afgelopen 24 uren
127.0.0.1:5335 32 ms
Dank, ik ga weer eens een poging wagen. Zo'n scriptje kreeg ik indertijd dus niet werkend (het deed gewoon niets), wat ik ook probeerde.lolgast schreef op maandag 9 februari 2026 @ 16:38:
[...]
Dat is wel mogelijk hoor, maar dan moet je zelf een healthcheck scriptje maken voor AGH. In bijvoorbeeld /etc/keepalived/check_service.sh. Die moet executable zijn.Bash:/etc/keepalived/keepalived.conf:
1 2 3 4 5 6 7 8 9 10 11 #!/bin/bash HOST=127.0.0.1 PORT=3000 nc -z "$HOST" "$PORT" >/dev/null 2>&1 if [ $? -eq 0 ]; then exit 0 # OK else exit 1 # FAIL fiBash:Er zijn vast slimmere manieren om AGH te monitoren, maar dit kwam nu bij mij even uit de hoge hoed
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 vrrp_script chk_service { script "/etc/keepalived/check_service.sh" interval 2 timeout 2 fall 2 rise 2 } vrrp_instance VI_1 { state MASTER interface eth0 virtual_router_id 51 priority 200 advert_int 1 virtual_ipaddress { 10.0.0.100 } track_script { chk_service } }
Had je het script wel executable gemaakt?zordaz schreef op dinsdag 10 februari 2026 @ 10:29:
[...]
Dank, ik ga weer eens een poging wagen. Zo'n scriptje kreeg ik indertijd dus niet werkend (het deed gewoon niets), wat ik ook probeerde.
chmod +x ...
Hier staat die ingesteld op 7 dagen weergave.tomdh76 schreef op maandag 9 februari 2026 @ 19:38:
[...]
gemiddelde procestijd is bij mij 19 ms en 127.0.0.1:5335 445 ms. Vooral deze laatste vind ik vrij traag. Misschien dat het aan Ipv6 ligt. Die heb jij uit staan en gebruik ik wel.
Unbound reactie is 154ms.
Maar in AGH 9ms (ivm caching)
Heb ook al wat zitten spelen met settings maar het wil maar niet zakken wat ik probeer.
Indien in Unbound ervantussen haal, en upstream dan Cloudlfare, en na paar dagen heb ik 1ms.
[ Voor 6% gewijzigd door TheCeet op 10-02-2026 13:26 ]
Mee eens.Villager schreef op dinsdag 10 februari 2026 @ 10:32:
Ik heb de setup met een failover van de Adguard home server al vaker voorbij zien komen. Maar als je Adguard Home op je OPNsense systeem draait dan is daar toch geen noodzaak voor? Immers, geen OPNsense = geen Internet.
Alhoewel de AGH plugin voor OPNsense in het verleden weleens "brak" na een OPNsense versie update.
Dus ja er is voor allebei wel iets te zeggen.
Hopelijk heb ik hier alle Adguard Home experts bijelkaar om een juiste setup op te zetten.
Hardware:
NanoPi Neo 512M met 16GB opslag. Deze heb ik 2x.
Software: DietPi (vooraf via dietpi.txt een en ander instellen: static ip, hostname).
De bedoeling. Aangezien ik 2x NanoPi Neo hebt 2x Adguard Home 2x draaien 1x primair en 1x secundair.
Het meest simpele is 1x Adguard Home en van DietPi software Adguard Home gekozen. Dat werkt. Maar dan heb redundantie. Dat is nou net wel de bedoeling als er 1 aan het updaten is of plots offline gaat.
Nu heb ik door het topic zitten te neuzen. Mij is niet helemaal duidelijk wat nu beste / simpelste is met redundantie.
Adguard via docker-ce of via de Adguard Home software van keuze van DietPi (nummer 126)?
Adguard-sync of keepalive?
Blog - Glasnet status (privé log) - Nette LAN - RIPE Atlas Probe
Ondersteund je DHCP niet het opgeven van 2 DNS servers? Dan vul je daar simpelweg je beide NanoPi instances in.
AdguardHome Sync is geen HA software, het is een replicatietool van de configuratie. Als een Adguard Home instance uitvalt gaat AGH Sync niets voor je doen
Als je DHCP server geen 2 DNS servers ondersteund is keepalived een goede oplossing in mijn ogen
DHCP goeie aanvulling. Zag dat in Adguard Home zit maar DHCP blijft lekker via de router (Draytek) en in de Draytek kan ik 2x DNS kwijt (nu dus die van ControlD ipv Quad9). Maar dat gaat dus 2x de NamoPi worden (als AGH erop heb geïnstalleerd).
Kortom 2x apart optuigen. 2x nog wat handmatig extra blocklists toevoegen ( Hagezi ) en klaar dus?
Blog - Glasnet status (privé log) - Nette LAN - RIPE Atlas Probe
Als je Adguard Home Sync draait hoef je dus in principe maar 1 node aan te passen, gaat de andere vanzelf na x-tijd. Ik heb het zelf ook draaien, maar dat is met name om te zorgen dat apparaat-specifieke blocks gelijk blijven. Blocklists komt zo weinig voor dat ik dat inderdaad even met de hand op beide nodes doe