[AdGuard Home] Ervaringen & discussie

[Jazco2nd]

Deef_K schreef op zondag 4 mei 2025 @ 08:45:
Ik gebruik sinds deze week adguard premium familie via IOS en heb dan last van het feit dat de YouTube app in beperkte modus werkt. Ik kan dus geen reacties onder de video’s meer zien.

Een oplossing die ik gezien heb is de regel @@||YouTube.com^ toevoegen bij dns filtering - toelatingslijst. Dit werkt voor echter niet.

Als dns server gebruik ik de adguard dns familie bescherming. Een andere oplossing kan ik niet vinden. Heeft iemand voor mij de gouden tip?

Ik gebruik al jaren Firefox + uBlock Origin + SponsorBlock als standaardbrowser en voor YouTube, zowel op Android als op laptops en tablets.

Werkt echt perfect en extra voordeel op Android is dat je background playback hebt (native vanuit Firefox).

Zie nooit ads. Daar heb je geen Adguard voor nodig eigenlijk.
Heb op Android de YouTube app zelfs uitgeschakeld.. casten doe ik door een fimpje in YouTube (Firefox) te starten/stoppen en omdat ik ben ingelogd in SmartTube op de TV verschijnt het daar ook en kan ik het selecteren om verder te kijken. Bediening gewoon via de afstandsbediening.

[Remco Tr]

Misschien kan iemand het uitleggen die het beter begrijpt.

Probeer al een tijdje de NOS app aan de praat te krijgen adguard icm unbound. Alleen unbound gooit roet in het eten. Met verschillende settings wel of geen serve expired.

Als ik unbound vervang voor technitium werkt het wel gelijk. Probleem zit hem dus niet in blocklist maar echt in de afhandeling van unbound.

Wie weet er meer?

[R-R-L]

Sinds enkele weken heb ik AdGuard Home draaien, goddelijk hoeveel fijner het internet thuis nu is.

Loop nu tegen het probleem dat ik blijkbaar mijn gastennetwerk onbruikbaar heb gemaakt. Dit zit vooral in een beperking van de KPN Box 12 software, het gastennetwerk neemt de DNS van het hoofdnetwerk over en is niet aanpasbaar.

Ik zag dat ik AdGuard Pro ook als DHCP in kan stellen. Hoe pak ik dat aan?
- Voor de DHCP interface lijkt het mij dat ik de end0 met daarin de IP adressen van de KPN router moet hebben
- Ik krijg dan standaard de 100-200 IP reeks. Kan ik die gewoon aanpassen naar 0-100?
- En opvolgend daarop, haal ik de IP reservering in de KPN Box er af, zodat alles automatisch de nieuwe DHCP pakken bij de eerstvolgende connectie?

En dan nog het punt hoe de vraag tot stand kwam, wat moet ik aanpassen om het gastennetwerk weer aan de praat te krijgen? Daarin denk ik aan de volgende opties zonder al goed uitgezocht te hebben of en hoe het kan:
- Gastennetwerk as-is behouden en alles via KPN routeren
- Gastennetwerk via de aparte IP-reeks maar dan via AdGuard
- Gastennetwerk een eigen reserveerde IP-reeks op het hoofdnetwerk geven, maar dan de boel dichttimmeren zodat het niet bij apparatuur op het hoofdnetwerk komt, wat de hele reden van mijn gastennwerk is

Veel vragen voor materie die voor mij nieuw maar erg interessant is.

[ThinkPad]

Remco Tr schreef op dinsdag 6 mei 2025 @ 12:05:
Misschien kan iemand het uitleggen die het beter begrijpt.

Probeer al een tijdje de NOS app aan de praat te krijgen adguard icm unbound. Alleen unbound gooit roet in het eten. Met verschillende settings wel of geen serve expired.

Als ik unbound vervang voor technitium werkt het wel gelijk. Probleem zit hem dus niet in blocklist maar echt in de afhandeling van unbound.

Wie weet er meer?

Daar liep @alex3305 ook tegenaan, hij laat als oplossing nos.nl resolven door z'n provider DNS: alex3305 in "[AdGuard Home] Ervaringen & discussie"

[ Voor 61% gewijzigd door ThinkPad op 06-05-2025 12:56 ]

[alex3305]

ThinkPad schreef op dinsdag 6 mei 2025 @ 12:55:
[...]

Daar liep @alex3305 ook tegenaan, hij laat als oplossing nos.nl resolven door z'n provider DNS: alex3305 in "[AdGuard Home] Ervaringen & discussie"

@Remco Tr Ik heb echt geen idee wat voor trucs NOS uithaalt of het doel daarvan is, maar inmiddels heb ik Unbound er maar helemaal tussenuit gehaald . Mede omdat ook andere NPO websites hetzelfde gedrag begonnen te vertonen. En ik had geen zin om handmatig uit te vogelen welke hostnames daar allemaal bij horen. Ook had mijn vrouw er met haar iPhone geen last van. Ik met de Android app wel, maar met de browser nooit. En op mijn pc werkte het ook altijd. Oh en soms ging het dagen goed, en dan dagen meerdere keren per dag fout.

Ik heb het idee dat hun CDN / WAF een of andere truc uithaalt met de TTL en dat AdGuard's optmistic caching daar over valt. Aan de andere kant heb ik optimistic caching ook een tijdje uitgehad en bleef ik toch nog af en toe problemen houden. Dus YMMV.

Met een KPN / Google / Cloudflare DNS als upstream server werkt het overigens prima. Waarschijnlijk omdat 'genoeg' mensen deze server gebruiken dat caching problemen niet opvallen.

[Glassertje]

@Remco Tr @alex3305 Ik gebruik de NOS app al langer dan ik unbound gebruik op Android en heb er nooit problemen mee.

zowel met de unbound.conf van pihole unbound als iedere andere config die ik gebruikt heb.

Ook met de unbound versie uit Raspberry OS (dacht 1.17.1), als nu de laatste Unbound 1.23.0.

[ Voor 58% gewijzigd door Glassertje op 06-05-2025 20:20 ]

[alex3305]

@Glassertje Ik geloof je best kerel, maar ik heb echt een andere ervaring. Unbound op mijn ASUS router gaf dezelfde problemen als een Unbound Docker container. Maar alleen bij NOS / NPO apps. Als ik vervolgens wifi uitzette op mijn telefoon, en uiteraard niet via een VPN verbond naar mijn thuisnetwerk, werkte de NOS app direct.

Inmiddels gebruik ik de NOS app overigens niet meer omdat de ontwikkelaars daar weer eens de toegankelijkheid van de app compleet verneukt hebben.

[ThinkPad]

alex3305 schreef op dinsdag 6 mei 2025 @ 20:53:
[...]
Inmiddels gebruik ik de NOS app overigens niet meer omdat de ontwikkelaars daar weer eens de toegankelijkheid van de app compleet verneukt hebben.

offtopic:
https://noslite.nl/

[FLA NL]

Het probleem met de NOS app heb ik ook zonder unbound en in Adguard home optimistic caching aan. Ik had wel altijd de minimum TTL op 10 staan. Dit maar is uitgezet (0) en kijken hoe dat gaat.

[stormfly]

Remco Tr schreef op dinsdag 6 mei 2025 @ 12:05:
Misschien kan iemand het uitleggen die het beter begrijpt.

Probeer al een tijdje de NOS app aan de praat te krijgen adguard icm unbound. Alleen unbound gooit roet in het eten. Met verschillende settings wel of geen serve expired.

Als ik unbound vervang voor technitium werkt het wel gelijk. Probleem zit hem dus niet in blocklist maar echt in de afhandeling van unbound.

Wie weet er meer?

Ik heb KPN DNS als resolver, daar werkte NOS ook niet meer via adguard. Toen heb ik de onderstaande custom filtering rules gemaakt om de NPO data door te laten. De onderste lijkt nog het meest relevant.

@FLA NL

code:

@@||topspin.npo.nl^$important
@@||atconnect.npo.nl^$important
@@||atconnect-npo-nl-cddc.at-o.net^$important
@@||nmonpoendpoint.2cnt.net^$important
@@||o314617.ingest.sentry.io^$important

atconnect.npo.nl is mogelijk je struikelblok: Het eerste stuk (npo.nl) is ondertekend (DS + RRSIG: OK). Maar de doelzone ( via CNAME atconnect-npo-nl-cddc.at-o.net) is niet ondertekend, dus zodra je het eindresultaat opvraagt, valt DNSSEC weg.

code:

harden-referral-path: yes
Als NS-sets of glue onbetrouwbaar zijn (bij at-o.net), kan dit validering breken.

code:

Harden  the  referral  path by performing additional queries for
              infrastructure data.  Validates the replies if trust anchors are
              configured and the zones are signed.  This enforces DNSSEC vali-
              dation on nameserver NS sets and the nameserver  addresses  that
              are encountered on the referral path to the answer.  [b]Default no[/b],
              because  it  burdens  the  authority  servers, and it is not RFC
              standard, and could lead to performance problems because of  the
              extra  query  load  that is generated.  Experimental option.  If
              you enable it  consider  adding  more  numbers  after  the  tar-
              get-fetch-policy to increase the max depth that is checked to.

---

code:

server:
    # Sta een ‘algorithm‑downgrade’ toe als er meerdere DS‑algoritmes zijn.
    # Daarmee gedraag je je zoals KPN/Google: één geldige keten is genoeg.
    harden-algo-downgrade: no

stormfly in "[Pi-Hole] Ervaringen & discussie"

Misschien helpt dit onderstaande, overigens is de default no als je deze regel nog niet in je configuratie hebt staan. Anders is de volgende stap je Unbound logs activeren verbosity 2 en dan even door spitten.

[ Voor 56% gewijzigd door stormfly op 06-05-2025 23:13 ]

[FLA NL]

Ik gebruik als upstream mijn router waar dnssec validatie op aan staat. Die gebruikt vervolgens als upstream met DNS over TLS, Quad9 en Dns0.eu. Alhoewel ik wel een Odido verbinding heb zal het dus niet liggen en hoe zij de dnssec afhandeling doen. De reden dat ik mijn router als upstream heb is om DNS Rebinding tegen te gaan.

Ik heb overigens ook getest met Technitium DNS als upstream in Adguard te gebruiken. Maar als je die zo instelt dat die ook expired records terug geeft zoals Adguard dat doet met optimistic caching dan krijg ik ook dat probleem met de NOS. Wat in het geval van Adguard ook zag is dat de gecachte records andere IP adressen teruggaven dan toen ze uiteindelijk wel ververst waren. Na een aantal keer refreshen doet de NOS app het vaak weer en ik heb het vermoeden dat dat de tijdsduur van de TTL van 10 seconden is, die Adguard standaard terug geeft bij expired records als optimistic caching aanstaat. Bij unbound zou je hetzelfde gedrag kunnen krijgen als je serve-expired hebt aanstaan.

[ Voor 5% gewijzigd door FLA NL op 06-05-2025 23:32 ]

[stormfly]

FLA NL schreef op dinsdag 6 mei 2025 @ 23:00:
Ik gebruik als upstream mijn router waar dnssec validatie op aan staat. Die gebruikt vervolgens als upstream met DNS over TLS, Quad9 en Dns0.eu. Alhoewel ik wel een Odido verbinding heb zal het dus niet liggen en hoe zij de dnssec afhandeling doen. De reden dat ik mijn router als upstream heb is om DNS Rebinding tegen te gaan.

Ik heb overigens ook getest met Technitium DNS als upstream in Adguard te gebruiken. Maar als je die zo instelt dat die ook expired records terug geeft zoals Adguard dat doet met optimistic caching dan krijg ik ook dat probleem met de NOS. Wat in het geval van Adguard ook zag is dat de gecachte records andere IP adressen teruggaven dan toen ze uiteindelijk wel ververst waren. Na een aantal keer refreshen doet de NOS app het vaak weer en ik heb het vermoeden dat dat de tijdsduur van de TTL van 10 seconden is, die Adguard standaard terug geeft bij expired records als optimistic caching aanstaat. Bij unbound zou je hetzelfde gedrag kunnen krijgen als je serve-expired hebt aanstaan.

Interessante gedachte maar als TCP sessie eenmaal staat zet je die niet weer op na 10seconden. Die webservers blijven bereikbaar ook na het verlopen van de 10 seconden.

Ik heb gekeken en de default TTL is 60 seconden voor atconnect.npo.nl ik maak daar zelf 300 seconden van in adguard om minder lookups te hoeven doen.

Hier werkt het goed met KPN DNS en AGH plus de custom filters + min TTL =300. filters die ik gedeeld heb in mijn vorige post.

[FLA NL]

Ik merk het probleem vooral bijvoorbeeld de volgende dag als ik na langere tijd gebruik maak van de NOS app, het is nooit plotseling dat het uitvalt. Dus dan denk ik niet dat die TCP sessie er dan al is. Mijn gevoel zegt dat het een soort caching icm load balancing probleem is met de NOS omdat ik bij 1 van de domeinen plots een andere reeks ip adressen zag verschijnen. Het is nu weer even stabiel lijkt het als het weer een keer voorkomt zal ik je custom filters is instellen.

Ik ben overigens meer een hobbyist op dit gebied dus misschien dat ik de plank mis sla

[Videopac]

alex3305 schreef op vrijdag 15 november 2024 @ 11:54:
Nav. de post van @EverLast2002 gisteren, en omdat mijn NOS problemen toch niet opgelost waren met Technitium, ben ik maar weer teruggegaan naar Unbound. Maar ik laat nu de NOS dus maar via de DNS van mijn provider lopen:

Upstream DNS servers

code:

# Unbound
10.100.100.20
# Workaround 
[/nos.nl/]192.168.1.1
# Internal routing
[//lan/internal/example.com/]192.168.1.1

Niet mooi. Maar voorlopig even functioneel.

Ik heb/had ook wat vage klachten bij gebruik van Unbound: o.a. de nos app, (NPO) internetradiostrams via Lyrion Music server en ook de Daikin warmtepomp app. Ik heb het vermoeden dat er een soort "intelligentie" is die bepaalde TTL-waardes i.c.m. onbekende DNS servers "verdacht" vind.

Ik had 3 AGH DNS servers draaien, waarvan 1 met unbound. Nadat ik die uitzette waren al mijn problemen opgelost.

[ Voor 6% gewijzigd door Videopac op 07-05-2025 21:46 ]

[alex3305]

@stormfly Ik gebruik mijn router's DNS als upstream die dan weer KPN als upstream gebruikt en ook zonder jouw custom filtering rules werkt het dan prima. Ik vind jouw analyse wel sterk overigens. Aangezien het alweer een tijdje geleden was, was mij de hostname ontschoten, maar ik verdachte destijds ook atconnect.npo.nl. Vandaar dat de NOS website wel werkt en de app niet. Maar embedded video's dan weer niet altijd.

Overigens deel ik jouw vermoeden niet dat de problemen komen door problemen met de ondertekening of validatie daarvan. Mijn beide Unbound servers hadden namelijk deze configuratie opties niet gespecificeerd (Docker container en ASUS). Daarnaast snap ik dan niet waarom het na een aantal pogingen dan toch nog zou werken en dan ook een tijdje blijft werken. En zelfs als ik de door jouw gesuggereerde domeinen blokkeer in AdGuard Home blijft NOS app werken. Althans dat ik haal ik uit mijn oude notities . Idem voor het feit dat de app wel goed werkt als ik alleen .nos.nl laat afhandelen door de KPN dns.

Ik blijft het vermoeden houden dat de app ergens een lookup doet die niet werk en dat na een aantal pogingen toevallig de juiste server bereikt wordt waardoor het wel werkt. Dat zou ook verklaren dat soms de app het maar een paar seconden niet doet en andere keren het langer duurt. En ik heb het idee dat dat ergens door hun nameservers komt. Die hebben ook een zeer vergelijkbare TTL van de interval van de problemen:

❯ dig NS +noall +answer +multiline nos.nl @192.168.1.4
nos.nl.                 37365 IN NS ns-1511.awsdns-60.org.
nos.nl.                 37365 IN NS ns-823.awsdns-38.net.
nos.nl.                 37365 IN NS ns-311.awsdns-38.com.
nos.nl.                 37365 IN NS ns-1582.awsdns-05.co.uk.

Cloudflare doet ook iets geks met deze records en cacht ze ook mega lang:

❯ dig NS +noall +answer +multiline nos.nl @1.1.1.1
nos.nl.                 172800 IN NS ns-1511.awsdns-60.org.
nos.nl.                 172800 IN NS ns-1582.awsdns-05.co.uk.
nos.nl.                 172800 IN NS ns-311.awsdns-38.com.
nos.nl.                 172800 IN NS ns-823.awsdns-38.net.

Andere providers hebben een zeer vergelijkbare TTL. Maar nogmaals, ik denk dat dit probleem daar ook voorkomt, maar niet opgemerkt wordt door de grote hoeveelheid gebruikers.

Overigens werkt het op iPhone nu ook slecht volgens mijn vrouw. Dat was in november afgelopen jaar niet.

[Videopac]

Kroonkurk schreef op donderdag 21 mei 2020 @ 20:37:
Volgens jouw log heb je dus een niet-officieel certificaat.
Regel dus ergens een gratis subdomeinnaam, bijvoorbeeld bij https://freedns.afraid.org/
Maak daar dus een subdomein aan, als voorbeeld: jouwserver.surfnet.ca
Zet dat subdomein naar jouw i.p. adres van de webserver. Maak een certificaat aan via LetsEncrypt voor dat subdomein en je hebt een geldig certificaat.

Begrijp ik goed dat ik dit moet regelen voordat ik DoH in kan stellen?
Ik snap hier bijzonder weinig van.
Ik heb een subdomein aangemaakt (denk ik) maar "Zet dat subdomein naar jouw i.p. adres van de webserver": ik heb geen idee hoe ik dit moet doen (en wat ik dan eigenlijk doe).

[Kroonkurk]

Probeer eerst maar DoH zonder datgene wat ik ooit heb opgeschreven.
Werkt het dan niet, dan kan je alsnog een certificaat aanmaken.

Als je bij freedns.afraid.org een subdomein hebt aangemaakt, dan kan je bij freedns.afraid.org bij Dynamic DNS je IP adres updaten aan de gekozen subdomeinnaam.
En dan via LetsEncrypt een geldig certificaat aanmaken.

[ThinkPad]

EverLast2002 schreef op zaterdag 17 juni 2023 @ 14:14:
[...]
- in System > Settings > General daar heb ik 9.9.9.9 en 1.0.0.1 staan, verder geen AGH ip adressen.
Dat veld is bedoeld voor OPNsense zelf zodat ie kan resolven wanneer je een update/upgrade doet. Heeft niks met je clients in je netwerk te maken.

Even hier op inhaken, want het dikgedrukte klopt niet helemaal. Gisteren een behoorlijke clusterfuck gecreëerd thuis vanwege dit ogenschijnlijke kleine detail

Ik heb op de clients als DNS het IP-adres van de OPNsense router. Unbound in OPNsense draait op poort 53. Via een NAT-rule buig ik de devices dan zodat ze naar AGH (draait op 53530) i.p.v. Unbound gaan. Ik dacht gisteren: hmm ik kan AGH wel op 53 zetten en Unbound naar een custom port, scheelt wellicht nog weer een paar ms. aan verwerkingstijd. Dat gedaan, maar toen begon de shitshow: OPNsense kon toen de namen van interne devices niet meer resolven. Hierdoor werden de firewall aliassen niet gevuld en werkten bepaalde firewall rules niet meer.

Kreeg het zo 123 ook niet opgelost, had onder System>General wel 127.0.0.1 gezet (en in AGH config ook als listen address toegevoegd) maar wilde niet werken. Uiteindelijk snapshot maar teruggedraaid.

[EverLast2002]

ThinkPad schreef op dinsdag 20 mei 2025 @ 09:11:
[...]

Even hier op inhaken, want het dikgedrukte klopt niet helemaal. Gisteren een behoorlijke clusterfuck gecreëerd thuis vanwege dit ogenschijnlijke kleine detail

Ik heb op de clients als DNS het IP-adres van de OPNsense router. Unbound in OPNsense draait op poort 53. Via een NAT-rule buig ik de devices dan zodat ze naar AGH (draait op 53530) i.p.v. Unbound gaan. Ik dacht gisteren: hmm ik kan AGH wel op 53 zetten en Unbound naar een custom port, scheelt wellicht nog weer een paar ms. aan verwerkingstijd. Dat gedaan, maar toen begon de shitshow: OPNsense kon toen de namen van interne devices niet meer resolven. Hierdoor werden de firewall aliassen niet gevuld en werkten bepaalde firewall rules niet meer.

Kreeg het zo 123 ook niet opgelost, had onder System>General wel 127.0.0.1 gezet (en in AGH config ook als listen address toegevoegd) maar wilde niet werken. Uiteindelijk snapshot maar teruggedraaid.

Mijn dikgedrukte opmerking klopt wel, dit wordt ook bevestigd door andere OPNsense gebruikers.

Waarschijnlijk gaat jouw setup wel werken, maar zit er ergens in je config een foutje.

Waarom wil je Unbound en AGH van poort wisselen, als het goed werkt (ga je millisecondes echt merken)?

[TheCeet]

Release v0.107.62

Security
- Go version has been updated to prevent the possibility of exploiting the Go vulnerabilities fixed in 1.24.3.

Fixed
- Clients with CIDR identifiers showing zero requests on the Settings → Client settings page (#2945).
- Command line option --update when the dns.serve_plain_dns configuration property was disabled (#7801).
- DNS cache not working for custom upstream configurations.
- Validation process for the DNS-over-TLS, DNS-over-QUIC, and HTTPS ports on the Encryption Settings page.
- Searching for persistent clients using an exact match for CIDR in the POST /clients/search HTTP API.

[TheCeet]

@cadsite Misschien hier verder gaan.

Ik vermoed dat het komt doordat je Chromecast toch nog steeds ook naar 8.8.8.8 connectie maakt voor bepaalde zaken. Hierdoor zie je ads bij VTM GO.

Hier firewall rules op de router ingesteld op de router zodat alles forced naar AdGuard gaat.
Zonet getest:
Android TV > Huis Gemaakt even genomen als test > instant start de aflevering.
App op iOS > idem hier.

Kans lijkt me klein dat het zou liggen aan de blocklists.
Mijn Android TV gebruikt ook harcoded DNS van Google, vandaar de firewall rule zodat toch alles via AGH gaat.

[Hmmbob]

Ik weet niet waarop je verder gaat, maar de Chromecasts/Android TVs hier in huis moet ik ook forceren naar mijn eigen DNS dmv firewall rules; die negeren de DNS in de DHCP ook volledig. Met een dst-nat naar Adguard werkt het perfect.

Mikrotik:

code:

/ip firewall nat
add action=dst-nat chain=dstnat comment="Intercept DNS from Cast devices" \
    dst-address-list="Google DNS" dst-port=53 in-interface=bridge-LAN \
    protocol=udp src-address-list="Cast Devices" \
    to-addresses=192.168.88.33 to-ports=53

code:

/ip firewall address-list
add address=192.168.88.111 list="Cast Devices"
add address=192.168.88.112 list="Cast Devices"
add address=192.168.88.113 list="Cast Devices"
...
add address=192.168.88.122 list="Cast Devices"
add address=8.8.4.4 list="Google DNS"
add address=8.8.8.8 list="Google DNS"

[zordaz]

Hmmbob schreef op woensdag 28 mei 2025 @ 09:05:
Ik weet niet waarop je verder gaat, maar de Chromecasts/Android TVs hier in huis moet ik ook forceren naar mijn eigen DNS dmv firewall rules; die negeren de DNS in de DHCP ook volledig. Met een dst-nat naar Adguard werkt het perfect.

Mikrotik:

code:

/ip firewall nat
add action=dst-nat chain=dstnat comment="Intercept DNS from Cast devices" \
    dst-address-list="Google DNS" dst-port=53 in-interface=bridge-LAN \
    protocol=udp src-address-list="Cast Devices" \
    to-addresses=192.168.88.33 to-ports=53

code:

/ip firewall address-list
add address=192.168.88.111 list="Cast Devices"
add address=192.168.88.112 list="Cast Devices"
add address=192.168.88.113 list="Cast Devices"
...
add address=192.168.88.122 list="Cast Devices"
add address=8.8.4.4 list="Google DNS"
add address=8.8.8.8 list="Google DNS"

Vergeet in dit soort gevallen niet om ook naar je DNS instellingen van IPv6 te kijken!

[The Source]

Sorry search levert weinig op.
Ik heb net Adguard in mijn virtualbox in Hassio geinstalleerd op mijn homeserver (windows).
Werkt leuk op mijn telefoon, wil deze op mijn router gaan instellen.
Deze homeserver crashed / reboot wel eens... wat zijn de makkelijke opties om te voorkomen dat ik dan geen internet meer heb ik mijn devices?

DNS 2 een andere externe (provider/google) instellen werkt niet heb ik begrepen.
Ik zie verschillende nog een 2de DNS draaien, maar dat lijkt me een beetje te ver gegrepen.
Zijn er anderer oplossingen?

[GioStyle]

The Source schreef op woensdag 28 mei 2025 @ 18:28:
Sorry search levert weinig op.
Ik heb net Adguard in mijn virtualbox in Hassio geinstalleerd op mijn homeserver (windows).
Werkt leuk op mijn telefoon, wil deze op mijn router gaan instellen.
Deze homeserver crashed / reboot wel eens... wat zijn de makkelijke opties om te voorkomen dat ik dan geen internet meer heb ik mijn devices?

DNS 2 een andere externe (provider/google) instellen werkt niet heb ik begrepen.
Ik zie verschillende nog een 2de DNS draaien, maar dat lijkt me een beetje te ver gegrepen.
Zijn er anderer oplossingen?

Tweede instantie op andere fysieke machine installeren en Keepalived gebruiken. Zo heb je één virtual ip adres voor DNS. Valt de eerste AdGuard uit, dan neemt de tweede het over.

[Hmmbob]

zordaz schreef op woensdag 28 mei 2025 @ 15:47:
[...]


Vergeet in dit soort gevallen niet om ook naar je DNS instellingen van IPv6 te kijken!

Goede, maar mijn router doet niets met ipv6

[glaswerk]

Ik ben bang dat ik het antwoord al weet, maar het is vast niet mogelijk om op mijn Experiabox12 8.8.8.8 om te leiden naar de AdGuard Home op mijn thuisnetwerk, om de Chromecast ernaartoe te forceren?

[ThinkPad]

Mooie tool gevonden om publieke DNS te benchmarken: GitHub: YaDNSb - Yet Another DNS Benchmark
Deze kan ook DoT / DoH benchmarken, wat de 'GRC DNS Benchmark' die je vaak langs ziet komen nog niet kan.

Moet alleen nog even een 'top50' domeinen ofzo vanuit m'n AGH hebben om een realistische test te creëren.
Heb deze tool in een Docker container draaien.

Zie ook: https://www.reddit.com/r/...ative_to_dns_performance/

@stormfly @RobertMe

[ Voor 18% gewijzigd door ThinkPad op 03-06-2025 12:36 ]

[Puller]

Ziet er interessant uit.
Ben benieuwd naar jullie benchmarks/bevindingen.
Kan het helaas nog niet uitproberen ivm vakantie

ThinkPad schreef op dinsdag 3 juni 2025 @ 12:35:
Mooie tool gevonden om publieke DNS te benchmarken: GitHub: YaDNSb - Yet Another DNS Benchmark
Deze kan ook DoT / DoH benchmarken, wat de 'GRC DNS Benchmark' die je vaak langs ziet komen nog niet kan.

Moet alleen nog even een 'top50' domeinen ofzo vanuit m'n AGH hebben om een realistische test te creëren.
Heb deze tool in een Docker container draaien.

Zie ook: https://www.reddit.com/r/...ative_to_dns_performance/

@stormfly @RobertMe

[ThinkPad]

Tsssk, een echte Tweaker heeft laptop mee op vakantie met VPN-tunnel naar huis toch? Al was het maar om op vakantie ook je AGH te kunnen gebruiken om geen reclames te zien

Onze "snelste-DNS-fetisjist" @stormfly zal het vast wel even proberen

Heb het net ook even (nouja, 'even', met bijna alles aangevinkt doet hij er wel 30 min. ofzo over) geprobeerd, zoals ik had verwacht is provider DNS toch het snelste (staat immers het dichtste bij)

[Puller]

Idd. Heb wel ipad mee en ook de bekende vpn langs huis.
Maar zit met minder mobiele verbinding en geen wifi.
Dus momentje zoeken voor dit.

[stormfly]

ThinkPad schreef op dinsdag 3 juni 2025 @ 14:58:
Tsssk, een echte Tweaker heeft laptop mee op vakantie met VPN-tunnel naar huis toch? Al was het maar om op vakantie ook je AGH te kunnen gebruiken om geen reclames te zien

Nee wel een mobiel met VPN of een iPad

Onze "snelste-DNS-fetisjist" @stormfly zal het vast wel even proberen

Heb het net ook even (nouja, 'even', met bijna alles aangevinkt doet hij er wel 30 min. ofzo over) geprobeerd, zoals ik had verwacht is provider DNS toch het snelste (staat immers het dichtste bij)

Haha ja ik moet even tijd vinden om het op te starten, het is A4D hier in de regio. Het huishouden draait in DEFCON1 modus

En ik moet zeggen dat ik ook de uitkomst al weet, omdat smokeping die al laat zien 2.8ms voor een KPN DNS lookup. Dat gaat geen enkele andere externe DNS overtreffen. Maar ik ga hem zeker bookmarken, tof dat je het deelt!

[Puller]

Plan is van de zomer over te gaan van Odido naar Delta ivm erg groot verschil in kosten komende 2 jaar.
Nu gebruik ik AGH op Opnsense N100 pctje
De Odido dns is de snelste bij mij met ca. 10ms responce tijd.
Weet iemand hoe de delta dns het doet?

[crypt0rr]

Puller schreef op dinsdag 10 juni 2025 @ 18:22:
Plan is van de zomer over te gaan van Odido naar Delta ivm erg groot verschil in kosten komende 2 jaar.
Nu gebruik ik AGH op Opnsense N100 pctje
De Odido dns is de snelste bij mij met ca. 10ms responce tijd.
Weet iemand hoe de delta dns het doet?

Afhankelijk van je wensen etc. is het aan te raden naar een DNS service als Quad9.

[TheCeet]

Kleine update, v0.107.64.

Security
- Go version has been updated to prevent the possibility of exploiting the Go vulnerabilities fixed in 1.24.5.

Fixed
- TTL override calculation (#7903).
- Validation process for DNSCrypt settings (#7856).

En de beta changelog, v0.108.0-b.73

Added
- New blocked services: ChatGPT, Claude, DeepSeek, Odysee.

Changed
- Updated dependencies.

[ Voor 26% gewijzigd door TheCeet op 28-07-2025 22:36 ]

[rens-br]

Ik heb Adguard nu al een hele tijd draaien met veel plezier in mijn netwerk. Bevalt beter dan Pi Hole, daarmee liep mijn vriendin nog wel eens te klagen dat ze allerlei zaken niet kon bereiken.

Nu probeer ik al een tijdje ook Adguard Home te gebruiken buiten mijn netwerk. In eerste instantie heb ik dat geprobeerd door Adguard Home naar buiten open te zetten, dat kreeg ik echter niet (lekker) werkend. Daarna heb ik het via wireguard geprobeerd. Dat lijkt soms te werken.. Maar soms ook niet.

Ik heb Adguard Home en Wireguard beide geïnstalleerd in twee losse docker containers. Ik dacht er vervolgens te zijn door adguard home en wireguard in hetzelfde netwerk te hangen en en in wireguard config file als dns server het interne docker ip mee te geven. Dit werkt alleen niet. Als ik de netwerken koppel werkt wireguard helemaal niet meer. Of ik krijg de melding dat de dns server niet gevonden kan worden.

Zijn er mensen met een vergelijkbare zelfde setup die wel goed en stabiel werkt?

[GioStyle]

rens-br schreef op zaterdag 2 augustus 2025 @ 21:00:
Ik heb Adguard nu al een hele tijd draaien met veel plezier in mijn netwerk. Bevalt beter dan Pi Hole, daarmee liep mijn vriendin nog wel eens te klagen dat ze allerlei zaken niet kon bereiken.

Nu probeer ik al een tijdje ook Adguard Home te gebruiken buiten mijn netwerk. In eerste instantie heb ik dat geprobeerd door Adguard Home naar buiten open te zetten, dat kreeg ik echter niet (lekker) werkend. Daarna heb ik het via wireguard geprobeerd. Dat lijkt soms te werken.. Maar soms ook niet.

Ik heb Adguard Home en Wireguard beide geïnstalleerd in twee losse docker containers. Ik dacht er vervolgens te zijn door adguard home en wireguard in hetzelfde netwerk te hangen en en in wireguard config file als dns server het interne docker ip mee te geven. Dit werkt alleen niet. Als ik de netwerken koppel werkt wireguard helemaal niet meer. Of ik krijg de melding dat de dns server niet gevonden kan worden.

Zijn er mensen met een vergelijkbare zelfde setup die wel goed en stabiel werkt?

Jouw setup heb ik een tijdlang gedraaid, maar inmiddels doet mijn router het Wireguard gedeelte. Als ik het me goed herinner had ik beide containers in hetzelfde netwerk draaien, in het config file het ip adres van de host ingevuld en in de router de juiste poort forwarden naar je Dockerhost.

[rens-br]

GioStyle schreef op zaterdag 2 augustus 2025 @ 22:23:
[...]


Jouw setup heb ik een tijdlang gedraaid, maar inmiddels doet mijn router het Wireguard gedeelte. Als ik het me goed herinner had ik beide containers in hetzelfde netwerk draaien, in het config file het ip adres van de host ingevuld en in de router de juiste poort forwarden naar je Dockerhost.

Ik maak beide containers los aan met hun eigen docker compose file, daarna hang ik ze in hetzelfde netwerk via portrainer en geef vervolgens in de docker compose file en de. conf die ik exporteer het interne IP van AH mee, maar toch werkt dat niet.

Je hebt het over iets forwarden, wat zou er geforward moeten worden?

[sjongenelen]

Dns is udp 53 port. Maar, moet je voor dns server niet een extra docker optie meegeven voor network stuff (naam ff kwijt)

[GioStyle]

rens-br schreef op zaterdag 2 augustus 2025 @ 22:56:
[...]


Ik maak beide containers los aan met hun eigen docker compose file, daarna hang ik ze in hetzelfde netwerk via portrainer en geef vervolgens in de docker compose file en de. conf die ik exporteer het interne IP van AH mee, maar toch werkt dat niet.

Je hebt het over iets forwarden, wat zou er geforward moeten worden?

Ik draai AdGuard Home op mijn Dockerhost. Al mijn clients verwijs ik (voor DNS) naar het ip adres van de Dockerhost. DNS verzoeken gaan via poort 53 en poort 53 op mijn Dockerhost is exposed met AdGuard Home container.

In WireGuard vul ik ook het ip adres (voor DNS) van de Dockerhost in, niet van de interne AdGuard Home ip adres.

En als laatst zal je in je router een poort moeten forwarden die kan babbelen met je WireGuard container. Ip adres van je Dockerhost + poortnummer die je gebruikt in je config.

[rens-br]

GioStyle schreef op zaterdag 2 augustus 2025 @ 23:31:
[...]


Ik draai AdGuard Home op mijn Dockerhost. Al mijn clients verwijs ik (voor DNS) naar het ip adres van de Dockerhost. DNS verzoeken gaan via poort 53 en poort 53 op mijn Dockerhost is exposed met AdGuard Home container.

Jep. Dat heb ik zo ook en dat werkt perfect voor intern verkeer.

In WireGuard vul ik ook het ip adres (voor DNS) van de Dockerhost in, niet van de interne AdGuard Home ip adres.

Dat heb ik ook ingesteld, als ik dan echter het. conf bestand exporteer staat daar ook het IP adres in en dan krijg ik de melding in Chrome dat de dns niet gevonden kan worden. Zet ik vervolgens de dns in de conf bestand naar bijv. 1.1.1.1 werken websites weer, maar doet de adblocker het natuurlijk niet.

En als laatst zal je in je router een poort moeten forwarden die kan babbelen met je WireGuard container. Ip adres van je Dockerhost + poortnummer die je gebruikt in je config.

Ah, bedoelde je dat. Dat heb ik inderdaad gedaan, anders werkt wireguard niet.

Wireguard heb ik werkend. AH heb ik intern ook werkend, nu nog de blokkades via Wireguard.

---

Een oplossing zoals dns over tls oid mag overigens ook, maar dat kreeg ik helaas ook niet lekker werkend.

[ Voor 4% gewijzigd door rens-br op 03-08-2025 00:39 ]

[ronaldtb]

Ik ben ook maar even in mijn configuratie gedoken.

Hier draait alles in Docker. Ik heb een WireGuard client en een docker-compose project met twee AdGuard Home clients en een AdGuard Sync client die de configuratie synchroniseert.
Al deze clients hangen direct in mijn netwerk via een macvlan configuratie. Daarom zijn de Aguard Home servers (in principe*) bereikbaar wanneer ik WireGuard activeer (ik heb in WireGuard de On-Demand optie aangezet zodat de VPN actief wordt zodra ik geen verbinding meer heb met WiFi)
Voor WireGuard heb ik port forwarding geconfigureerd. AdGuard Home zelf is niet vanaf internet bereikbaar.
Ik heb na het exporteren en toevoegen van de WireGuard configuraties aan de clients nog wel overal handmatig de DNS server adressen van de twee AdGuard Home servers toegevoegd. Die adressen kwamen niet standaard in de exports, ook al stonden ze wel in de instellingen.

* Wat mij de meeste hoofdbrekens heeft bezorgd, is dat in WireGuard de Allowed IPs standaard zeer strikt stonden. Hierdoor mochten de clients niet met de AdGuard Home servers verbinden. Ik zat toen dus met vergelijkbare problemen als jij. Met AdGuard Home servers in de configuratie kreeg ik geen verbinding, maar met openbare DNS servers wel.
Dit heb ik opgelost door van Allowed IPs 0.0.0.0/0 te maken. Dit zou ook strikter kunnen, maar ik heb zelf geen gescheiden netwerken of DMZ.

[GioStyle]

rens-br schreef op zondag 3 augustus 2025 @ 00:32:

Wireguard heb ik werkend. AH heb ik intern ook werkend, nu nog de blokkades via Wireguard.

't Enige wat mij nog te binnen schiet is: gebruik je vlan's? En zo ja, is de AdGuard Home container bereikbaar vanaf je vpn vlan?

[rens-br]

GioStyle schreef op zondag 3 augustus 2025 @ 18:40:
[...]


't Enige wat mij nog te binnen schiet is: gebruik je vlan's? En zo ja, is de AdGuard Home container bereikbaar vanaf je vpn vlan?

Nee die gebruik ik niet. Of althans niet daarvoor.

Als ik in de conf mijn IP instel van AH (192.168.0.250) kan ik ook gewoon bij mijn interne netwerk en ook op de AH admin pagina komen. Echter kan de DNS server dan niet gevonden worden. Heel erg vreemd.

Zal er wellicht toch mee te maken hebben dat het beide op dezelfde machine in docker draait ofzo?

[rens-br]

Inmiddels de oplossing gevonden na 3 avonden prutsen. Het heeft dus wel degelijk iets te maken met delen van netwerken binnen de beide containers. Je moet adguard toevoegen aan het interne netwerk van wireguard en dan het interne ip adres van adguard home gebruiken als DNS server.

Dat ziet er in beide compose files als volgt uit:

Adguard-home:

code:

name: adguardhome

services:
  adguardhome:
    container_name: adguard-home
    image: adguard/adguardhome
    ports:
      - 53:53/tcp # plain dns over tcp
      - 53:53/udp # plain dns over udp
      - 90:80/tcp # http web interface
      - 3000:3000/tcp # initial setup web interface
      - 451:443/tcp #ssl
      - 451:443/udp #ssl
      - 853:853/tcp #DNS-over-TLS⁠
    networks:
      wg:
        ipv4_address: 10.42.42.20
      adguard:
    volumes:
      - /opt/adguardhome/conf:/opt/adguardhome/conf # app configuration
      - /opt/adguardhome/work:/opt/adguardhome/work # app working directory
volumes:
  config:
    driver: local
  work:
    driver: local 
    
networks:
    adguard:
        name: adguard
    wg:
        external: true

Wireguard:

code:

volumes:
  etc_wireguard:

services:
  wg-easy:
    image: ghcr.io/wg-easy/wg-easy:15
    container_name: wg-easy 
    environment:
      - INSECURE=true
      - PORT=51822
    networks:
      wg:
        ipv4_address: 10.42.42.42
        ipv6_address: fdcc:ad94:bacf:61a3::2a
    volumes:
      - etc_wireguard:/etc/wireguard
      - /lib/modules:/lib/modules:ro
    ports:
      - "51820:51820/udp"
      - "51821:51821/tcp"
      - "51822:51822"
    restart: unless-stopped
    cap_add:
      - NET_ADMIN
      - SYS_MODULE
      # - NET_RAW # ⚠️ Uncomment if using Podman
    sysctls:
      - net.ipv4.ip_forward=1
      - net.ipv4.conf.all.src_valid_mark=1
      - net.ipv6.conf.all.disable_ipv6=0
      - net.ipv6.conf.all.forwarding=1
      - net.ipv6.conf.default.forwarding=1

networks:
  wg:
    name: wg
    driver: bridge
    enable_ipv6: true
    ipam:
      driver: default
      config:
        - subnet: 10.42.42.0/24
        - subnet: fdcc:ad94:bacf:61a3::/64

Mijn Adguard home krijgt in het WG netwerk het ip 10.42.42.20 en als ik dat invoer als DNS bij wireguard dan werkt het dus. kan de ontwikkelaar mooi de wiki updaten.

Geen idee of het iets uitmaakt, maar ik maakte gebruik van de oude wireguard en heb meteen een upgrade gemaakt naar versie 15 van WG-easy.

[ Voor 5% gewijzigd door rens-br op 05-08-2025 08:30 ]

[bart.koppers]

rens-br schreef op zondag 3 augustus 2025 @ 23:06:
Inmiddels de oplossing gevonden na 3 avonden prutsen. Het heeft dus wel degelijk iets te maken met delen van netwerken binnen de beide containers. Je moet adguard toevoegen aan het interne netwerk van wireguard en dan het interne ip adres van adguard home gebruiken als DNS server.

Dat ziet er in beide compose files als volgt uit:

Adguard-home:

code:

name: adguardhome

volumes:
  config:
    driver: local
  work:
    driver: local

Deze volumes: kun je volgens mij weglaten, omdat je erboven al mapt naar de dirs

Je kunt beide - denk ik - misschien net zo goed combineren in 1 compose.yml?

Voordeel is oa dat je dan naar elkaar kunt verwijzen via de hostnames die je voor beide containers hebt gedefinieerd met container_name.
To be honest: weet zo niet zeker of dat kan (ipv IPv4/6) in WG-easy/AGH

[rens-br]

bart.koppers schreef op maandag 4 augustus 2025 @ 13:22:
[...]

Deze volumes: kun je volgens mij weglaten, omdat je erboven al mapt naar de dirs

Je kunt beide - denk ik - misschien net zo goed combineren in 1 compose.yml?

Eén compose file kan inderdaad ook prima en zal ook wel werken, maar ik heb de zaken graag gescheiden. Wat betreft volume, dat zou kunnen. Beide compose files komen uit de guides van AH en WG-easy met eigen netwerk aanpassingen erbij. Ben niet zo heel bekend met compose files, het uitzoekwerk met betrekking tot de netwerken was al heel wat.

Voordeel is oa dat je dan naar elkaar kunt verwijzen via de hostnames die je voor beide containers hebt gedefinieerd met container_name.
To be honest: weet zo niet zeker of dat kan (ipv IPv4/6) in WG-easy/AGH

Dat verwijzen via hostnames kan volgens mij zolang ze maar in één netwerk zitten, daar hoef je ze niet voor in één compose file te hebben. Je kan echter geen hostname als DNS instellen in wireguard, dus je schiet daar verder niet zoveel mee op.

[alex3305]

@rens-br Het grote probleem bij deze twee Compose files is dat er een volgordelijkheid in zit, dat kan nogal onhandig zijn. Want eigenlijk heb je niet eens een attachable network gedefinieerd, maar attach je daarna wel een andere container daaraan. Dan zou je eigenlijk nog beter met een apart commando het netwerk kunnen aanmaken en dan beide containers attachen.

Ook kan de keuze van een .2 IPv4 adres nogal ongelukkig uitpakken als met een (verkeerde) uitrol de DHCP server heeft besloten dat deze aan een container hangt. Ik begin dus meestal met .20.

Je zou er ook voor kunnen kiezen om AdGuard Home Sync te draaien en Wireguard een eigen DNS server te geven. Bijvoorbeeld:

YAML:

services:
  adguard-home:
    container_name: wireguard-adguard-home
    image: adguard/adguardhome:latest
    restart: unless-stopped
    ports:
      - 3001:3000/tcp # HTTP Web interface
    networks:
      internal:
        ipv4_address: 10.42.42.20
    volumes:
      - config:/opt/adguardhome/conf # app configuration
      - work/opt/adguardhome/work    # data dir

  adguard-home-sync:
    container_name: wireguard-adguard-home
    image: ghcr.io/bakito/adguardhome-sync:alpine-latest
    restart: unless-stopped
    command: run
    depends_on:
      - adguard-home
    networks:
      internal:
        ipv4_address: 10.42.42.30
    environment:
      - TZ=Europe/Amsterdam
      - CRON="*/30 * * * *"
      - ORIGIN_URL=http://your-adguard-home:80
      - REPLICA_URL=http://adguard-home:3000
      - REPLICA_AUTO_SETUP=true
      - REPLICA_USERNAME=admin
      - REPLICA_PASSWORD=somerandompassword
      - RUN_ON_START=true

  wg-easy:
    container_name: wireguard-wg-easy
    image: ghcr.io/wg-easy/wg-easy:15
    restart: unless-stopped
    depends_on:
      - adguard-home
    environment:
      - INSECURE=true
      - PORT=51822
    ports:
      - "51820:51820/udp"
      - "51821:51821/tcp"
      - "51822:51822"
    networks:
      internal:
        ipv4_address: 10.42.42.40
        ipv6_address: fdcc:ad94:bacf:61a3::2a
    volumes:
      - etc_wireguard:/etc/wireguard
      - /lib/modules:/lib/modules:ro
    cap_add:
      - NET_ADMIN
      - SYS_MODULE
      # - NET_RAW # ⚠️ Uncomment if using Podman
    sysctls:
      - net.ipv4.ip_forward=1
      - net.ipv4.conf.all.src_valid_mark=1
      - net.ipv6.conf.all.disable_ipv6=0
      - net.ipv6.conf.all.forwarding=1
      - net.ipv6.conf.default.forwarding=1

volumes:
  config:
    name: adguard-home-config
  work:
    name: adguard-home-work
  wireguard:
    name: wireguard

networks:
  internal:
    name: wiregaurd-internal
    driver: bridge
    enable_ipv6: true
    ipam:
      driver: default
      config:
        - subnet: 10.42.42.0/24
        - subnet: fdcc:ad94:bacf:61a3::/64

Meer informatie op GitHub. Maar ik gebruik een dergelijke setup voor mijn primaire / secundaire AdGuard Home instanties .

bart.koppers schreef op maandag 4 augustus 2025 @ 13:22:
[...]

Voordeel is oa dat je dan naar elkaar kunt verwijzen via de hostnames die je voor beide containers hebt gedefinieerd met container_name.
To be honest: weet zo niet zeker of dat kan (ipv IPv4/6) in WG-easy/AGH

DNS op hostname is extreem afhankelijk van de implementatie. Vooral reguliere DNS. Toen ik dat lokaal probeerde werkte het op mijn primaire host (Unraid) niet, maar op mijn secundaire host (Debian) wel. Allebei met dezelfde Compose file .

[rens-br]

alex3305 schreef op maandag 4 augustus 2025 @ 16:50:
@rens-br Het grote probleem bij deze twee Compose files is dat er een volgordelijkheid in zit, dat kan nogal onhandig zijn. Want eigenlijk heb je niet eens een attachable network gedefinieerd, maar attach je daarna wel een andere container daaraan. Dan zou je eigenlijk nog beter met een apart commando het netwerk kunnen aanmaken en dan beide containers attachen.

Er zullen ongetwijfeld wat minder handigheden in zitten, helemaal mee eens. Maar het aanmaken van je containers via docker is iets wat je toch in principe één keer doet. Dus even handmatig in de juiste volgorde uitvoeren is dan niet zo'n probleem lijkt me.

Ook kan de keuze van een .2 IPv4 adres nogal ongelukkig uitpakken als met een (verkeerde) uitrol de DHCP server heeft besloten dat deze aan een container hangt. Ik begin dus meestal met .20.

Dat is een goede tip en heb ik meteen aangepast.

Je zou er ook voor kunnen kiezen om AdGuard Home Sync te draaien en Wireguard een eigen DNS server te geven. Bijvoorbeeld:

Adguard sync is wel handig mocht ik ooit twee dns servers willen draaien, heb nu alleen maar één stuk hw waar ik dat op doe.

[bart.koppers]

DNS op hostname is extreem afhankelijk van de implementatie. Vooral reguliere DNS. Toen ik dat lokaal probeerde werkte het op mijn primaire host (Unraid) niet, maar op mijn secundaire host (Debian) wel. Allebei met dezelfde Compose file .

Voorzover ik weet/ervaar op alle OSen, zorgt Docker dat een andere container_name (eerst) wordt resolved binnen het netwerk.
Pas als niet kan worden geresolved, dan pas wordt dns van de host gebruikt

Je kunt het proberen door vanuit de container te pingen naar een andere container
(tenminste als ping in de container zit, natuurlijk)

Of heb je dan wat aangepast aan de standaard instellingen van Docker?
(Evt te checken via docker network inspect)

Vond nog leesbare uitleg: https://medium.com/@prajw...ing-docker-dns-2ed4b070a0

[ Voor 6% gewijzigd door bart.koppers op 05-08-2025 16:36 ]

[alex3305]

@bart.koppers Je hoeft mij niets uit te leggen over Docker DNS



Maar dit gaat niet specifiek over Docker's DNS, dit gaat over AdGuard Home die - in mijn geval - Unbound in een andere container niet op hostname kon resolven. Ondanks dat ik daar de container name of ingestelde hostname gebruikte en allebei aan hetzelfde interne netwerk hingen.

Het is alweer een tijd geleden, maar dat kwam volgens mij omdat AdGuard Home op de primaire (ipvlan) netwerk interface ging zoeken en daar de host niet op kon vinden en dan gewoon afhaakte. De andere host had een net iets andere network stack waardoor het daar wel werkte.

Je zou dit op kunnen lossen met een network priority, ware het niet dat dit niet werkt in Compose. Alhoewel dit issue gesloten is, pakt Compose de netwerken alfabetisch op . Eerlijk gezegd heb ik weinig zin in dat soort gare oplossingen.

Maar dat was de reden dat ik de ipam configuratie meegaf met de Compose definitie. Bij voorkeur laat ik Compose zelf IP adressen kiezen en uitdelen en doe ik alles op hostname. En dat doe ik dus ook bij alle andere diensten .

Inmiddels draai ik AdGuard Home op beide nodes overigens allebei met een ipvlan netwerk met een eigen subnet. Wellicht dat ik de Unbound route inclusief hostname mapping dus nog eens uit ga proberen. Momenteel heb ik namelijk geen Unbound draaien door het NOS / NPO probleem.

[bart.koppers]

alex3305 schreef op dinsdag 5 augustus 2025 @ 22:29:
@bart.koppers Je hoeft mij niets uit te leggen over Docker DNS

Die compose in combi met de opmerking over dns gaf mij een wat andere indruk.
Uitzondering begrijp ik nu.

En inderdaad, geen echte AGH issue.

[alex3305]

Overigens heb ik het werkend gekregen . Het was nogal... voor de hand liggend .

TL;DR, om Docker containers op hostname te gebruiken in de AdGuard Home configuratie moet je eveneens Docker's interne DNS als bootstrap DNS server opgeven.

Ik heb nu onderstaande Docker Compose configuratie:

YAML:

services:
  adguard-home:
    container_name: adguard-home
    image: adguard/adguardhome:v0.107.64
    restart: on-failure:10
    hostname: leetower.adguard.docker.internal
    environment:
      TZ: Europe/Amsterdam
    networks:
      ingress:
        priority: 1
      internal:
        priority: 2
      ipvlan:
        ipv4_address: 192.168.40.4
        priority: 3
    volumes:
      - /mnt/applications/appdata/adguard-home/conf:/opt/adguardhome/conf
      - /mnt/applications/appdata/adguard-home/work:/opt/adguardhome/work

  unbound:
    container_name: adguard-home-unbound
    image: klutchell/unbound:1.23.1
    restart: on-failure:3
    hostname: leetower.unbound.docker.internal
    networks:
      internal:

networks:
  ingress:
    name: swarm-overlay
    external: true
  internal:
    name: adguard-home-internal
    driver: overlay
    attachable: true
  ipvlan:
    name: br0.40
    external: true

Een aantal puntjes van aandacht:

• De hostname wordt (automatisch) gegenereerd door Ansible, maar is dus een combinatie van de machiennaam inclusief de dienst en het domein docker.internal.
• Het ingress netwerk gebruik ik voor Caddy reverse proxy door middel van Docker labels. Dat is buiten scope hier en heb ik weggelaten.
• Het internal netwerk is een Swarm overlay netwerk die ik op twee machines heb
• Het ipvlan netwerk is een ipvlan (duh) bridge netwerk die getagd is.
• Mijn secundaire machine houdt ik synchroon met AdGuard Sync. Vergelijkbaar met mijn eerdere post.

Ik heb nog een andere machine met wat kleine verschillen:

Diff:

services:
  adguard-home:
-    hostname: leetower.adguard.docker.internal
+    hostname: brickhouse.adguard.docker.internal

  adguard-home-unbound:
-    hostname: leetower.unbound.docker.internal
+    hostname: brickhouse.unbound.docker.internal

networks:
  ipvlan:
-    name: br0.40
+    name: br0.41

Mijn Upstream DNS Servers configuratie heb ik nu als volgt:

code:

leetower.unbound.docker.internal
brickhouse.unbound.docker.internal
[/168.192.in-addr.arpa/]192.168.1.1
[/ip6.arpa/]192.168.1.1

En mijn Bootstrap DNS Servers zijn:

code:

127.0.0.11
192.168.1.1

En als laatste de Private Reverse DNS configuratie:

code:

192.168.1.1
[/168.192.in-addr.arpa/]192.168.1.1
[/ip6.arpa/]192.168.1.1

Het geheel lijkt nu, inclusief hostname lookup door middel van PTR records te werken . Daarnaast gebruiken beide AdGuard Home instanties dus nu ook allebei beide Unbound instanties waardoor ik direct failover heb .

Nu nog even aankijken, maar dit ziet er uit als een mooi resultaat .

Het enige wat ik nog niet werkend heb gekregen is een andere user / group voor de AdGuard Home container, maar dat vind ik geen bijster groot probleem.

[bart.koppers]

alex3305 schreef op woensdag 6 augustus 2025 @ 16:47:
Overigens heb ik het werkend gekregen . Het was nogal... voor de hand liggend .

TL;DR, om Docker containers op hostname te gebruiken in de AdGuard Home configuratie moet je eveneens Docker's interne DNS als bootstrap DNS server opgeven.

Ik heb nu onderstaande Docker Compose configuratie:

YAML:

services:
  adguard-home:
    container_name: adguard-home
    image: adguard/adguardhome:v0.107.64
    restart: on-failure:10
    hostname: leetower.adguard.docker.internal
    environment:
      TZ: Europe/Amsterdam
    networks:
      ingress:
        priority: 1
      internal:
        priority: 2
      ipvlan:
        ipv4_address: 192.168.40.4
        priority: 3
    volumes:
      - /mnt/applications/appdata/adguard-home/conf:/opt/adguardhome/conf
      - /mnt/applications/appdata/adguard-home/work:/opt/adguardhome/work

  unbound:
    container_name: adguard-home-unbound
    image: klutchell/unbound:1.23.1
    restart: on-failure:3
    hostname: leetower.unbound.docker.internal
    networks:
      internal:

networks:
  ingress:
    name: swarm-overlay
    external: true
  internal:
    name: adguard-home-internal
    driver: overlay
    attachable: true
  ipvlan:
    name: br0.40
    external: true

Een aantal puntjes van aandacht:

• De hostname wordt (automatisch) gegenereerd door Ansible, maar is dus een combinatie van de machiennaam inclusief de dienst en het domein docker.internal.
• Het ingress netwerk gebruik ik voor Caddy reverse proxy door middel van Docker labels. Dat is buiten scope hier en heb ik weggelaten.
• Het internal netwerk is een Swarm overlay netwerk die ik op twee machines heb
• Het ipvlan netwerk is een ipvlan (duh) bridge netwerk die getagd is.
• Mijn secundaire machine houdt ik synchroon met AdGuard Sync. Vergelijkbaar met mijn eerdere post.

Ik heb nog een andere machine met wat kleine verschillen:

Diff:

services:
  adguard-home:
-    hostname: leetower.adguard.docker.internal
+    hostname: brickhouse.adguard.docker.internal

  adguard-home-unbound:
-    hostname: leetower.unbound.docker.internal
+    hostname: brickhouse.unbound.docker.internal

networks:
  ipvlan:
-    name: br0.40
+    name: br0.41

Mijn Upstream DNS Servers configuratie heb ik nu als volgt:

code:

leetower.unbound.docker.internal
brickhouse.unbound.docker.internal
[/168.192.in-addr.arpa/]192.168.1.1
[/ip6.arpa/]192.168.1.1

En mijn Bootstrap DNS Servers zijn:

code:

127.0.0.11
192.168.1.1

En als laatste de Private Reverse DNS configuratie:

code:

192.168.1.1
[/168.192.in-addr.arpa/]192.168.1.1
[/ip6.arpa/]192.168.1.1

Het geheel lijkt nu, inclusief hostname lookup door middel van PTR records te werken . Daarnaast gebruiken beide AdGuard Home instanties dus nu ook allebei beide Unbound instanties waardoor ik direct failover heb .

Nu nog even aankijken, maar dit ziet er uit als een mooi resultaat .

Het enige wat ik nog niet werkend heb gekregen is een andere user / group voor de AdGuard Home container, maar dat vind ik geen bijster groot probleem.

Tikje gekunstelde setup IMHO, voor een zeer specifieke setup.

Als je Unbound wil gebruiken als resolver voor AGH, kun je in AGH voor upstream en bootstrap “gewoon” verwijzen naar 127.0.0.11 en de unbound:port - er zijn verder geen IP-adressen adressen nodig.
Dat maakt dat de AGH via het IP van de host te gebruiken is.

Voor wat betreft “failover” : lijkt weinig toe te voegen, gezien dat DNS by design is ontworpen voor zo’n failover (reden dat er 2 of meer dns entries opgegeven kunnen worden via DHCP etc)

Een compose.yml houd ik waar maar mogelijk hetzelfde per Docker instance/server.
Liever regel ik specifieke instellingen via de environment-vars (lukt maar deels/niet met AGH, I know).

En, als dan wil gaan syncen heb je in jouw setup dat aparte swarm-netwerk nodig door deze heel aparte/specifieke networksetup.

Kortom, mooi dat gelukt om deze relatief complexe setup zo voor elkaar te krijgen, maar de meerwaarde en herbruikbaarheid: ik zie hem niet.

[alex3305]

@bart.koppers

Ik denk dat het aardig evident is dat de upstream 'gewoon' unbound:53 kan zijn. Ik verwacht dat zoiets hier wel algemeen bekend is. Ik wilde met name de kruisbestuiving van upstreams hebben, of in ieder geval testen, om te kijken hoe Unbound met o.a. caching omgaat. Als je namelijk één op één de AdGuard Home <-> Unbound koppeling maakt, is de kans dat de cache van de secundaire Unbound instantie - mits ingesteld - gevuld gaat worden een stuk kleiner. Nu met Parallelle Requests kan ik daar enigszins wel vanuit gaan. Nu kan ik Unbound dus gebruiken als L2 cache.

Voor wat betreft “failover” : lijkt weinig toe te voegen, gezien dat DNS by design is ontworpen voor zo’n failover (reden dat er 2 of meer dns entries opgegeven kunnen worden via DHCP etc)

Dat gedrag is enorm afhankelijk van de implementatie.

Ik snap niet waarom je zo kritisch moet zijn op de door mij gedeelde setup? Ik post dat hier alleen maar om anderen te helpen . Dat is niet heel positief, wel?

[TheCeet]

Nieuwe update.
v0.107.65

Changelog:

Security
- Go version has been updated to prevent the possibility of exploiting the Go vulnerabilities fixed in 1.24.6.

Added
- A separate checkbox in the Web UI to enable or disable the global DNS response cache without losing the configured cache size.
- A new "cache_enabled" field to the HTTP API (GET /control/dns_info and POST /control/dns_config). See openapi/openapi.yaml for the full description.

Changed
Configuration changes
In this release, the schema version has changed from 29 to 30.
- Added a new boolean field dns.cache_enabled to the configuration. This field explicitly controls whether DNS caching is enabled, replacing the previous implicit logic based on dns.cache_size.

# BEFORE:
'dns':
# …
'cache_size': 123456

# AFTER:
'dns':
# …
'cache_enabled': true
'cache_size': 123456
To roll back this change, set the schema_version back to 29.


Fixed
- Disabled state of Top clients action button in web UI (#7923).

[rens-br]

TheCeet schreef op woensdag 20 augustus 2025 @ 21:42:
Nieuwe update.
v0.107.65

Changelog:

[...]

Kreeg net al een melding van watchtower.

[EverLast2002]

is die nieuw toegevoegde checkbox (cache enabled) in feite een optie
om AGH als lokale cache server te laten werken?
dat was toch al actief zonder die checkbox, of begrijp ik het niet..

[lolgast]

@EverLast2002 Ik heb het begrepen als:
Je kunt stoppen met local cache gebruiken zonder de local cache weg/leeg te gooien

[ThinkPad]

Volgens mij is het puur een setting om caching aan/uit te kunnen zetten, zonder bij het invoerveld eronder de waarde 0 (nul) in te moeten voeren

[Hmmbob]

ThinkPad schreef op donderdag 21 augustus 2025 @ 13:22:
Volgens mij is het puur een setting om caching aan/uit te kunnen zetten, zonder bij het invoerveld eronder de waarde 0 (nul) in te moeten voeren

Zo lees ik 'em ook

[R-R-L]

Geen idee of ik in dit topic moet zijn, of er eentje voor Tailscale moet starten. Simpelweg omdat ik nog niet duidelijk heb waar het probleem zit.

Ik gebruik Tailscale voor de tunnel naar AdGuard Home, draaiend als add-on in HAOS. Werkte prima, maar sinds een paar dagen krijg ik buitenshuis weer advertenties te zien. Ben in die dagen nog niet thuis geweest, dus ook nog niet kunnen testen hoe het gedrag is als ik weer verbonden ben met mijn thuisnetwerk.

In AdGuard staan alle filters actief en zie ik DNS requests in de logging, die kan ik direct aan activiteit op mijn telefoon en tablet relateren. Quad9 voor DoH en DoT, geen fallback en IPv4/IPv6 van Quad9 voor fallback.

In Tailscale staat mijn RPi als exit node aangewezen, Tailscale IP als global nameserver met override DNS servers aan, MagicDNS uit.

Ik loop intussen zelf stuk op waar settings verkeerd kunnen staan. Rare dus dat ik wel logs zie en ook keurig dat dingen geblokkeerd worden, maar toch blijf ik advertenties zien.

Gebruikte apparaten zijn een Samsung A53 en Tab A9, beiden up-to-date. Router KPN box 12.

[EverLast2002]

even een WTF momentje daarnet :
ik draai in huis 3 AGH instanties (met keepalived als failover).
in AGH1 stond er in het dashboard een DNS queries getal van 99.000.
ik doe een 'refresh statistics' en het getal wordt KLEINER i.p.v groter.
vreemd, dus ik doe ook een refresh bij AGH2, en ook hier wordt het getal KLEINER.
AGH3 bleef gelijk qua getal maar die wordt sowieso zelden aangesproken.
kan iemand verklaren hoe dit komt?
ik dacht eerst dat AGH een log refresh had uitgevoerd, die staat bij mij op 7 dagen.
maar dit lijkt me niet de oorzaak.

[Starck]

EverLast2002 schreef op woensdag 27 augustus 2025 @ 20:32:
even een WTF momentje daarnet :
ik draai in huis 3 AGH instanties (met keepalived als failover).
in AGH1 stond er in het dashboard een DNS queries getal van 99.000.
ik doe een 'refresh statistics' en het getal wordt KLEINER i.p.v groter.
vreemd, dus ik doe ook een refresh bij AGH2, en ook hier wordt het getal KLEINER.
AGH3 bleef gelijk qua getal maar die wordt sowieso zelden aangesproken.
kan iemand verklaren hoe dit komt?
ik dacht eerst dat AGH een log refresh had uitgevoerd, die staat bij mij op 7 dagen.
maar dit lijkt me niet de oorzaak.

Zijn alle statistieken op het dashboard niet van de afgelopen 24 uur? Dus als jij 24 uur geleden meer requests deed dan nu, dan zou het getal inderdaad kleiner worden, de oude verlopen dan namelijk.

[lolgast]

EverLast2002 schreef op woensdag 27 augustus 2025 @ 20:32:
even een WTF momentje daarnet :
ik draai in huis 3 AGH instanties (met keepalived als failover).
in AGH1 stond er in het dashboard een DNS queries getal van 99.000.
ik doe een 'refresh statistics' en het getal wordt KLEINER i.p.v groter.
vreemd, dus ik doe ook een refresh bij AGH2, en ook hier wordt het getal KLEINER.
AGH3 bleef gelijk qua getal maar die wordt sowieso zelden aangesproken.
kan iemand verklaren hoe dit komt?
ik dacht eerst dat AGH een log refresh had uitgevoerd, die staat bij mij op 7 dagen.
maar dit lijkt me niet de oorzaak.

Wat @Starck zegt. Het is een rolling ‘log’ dus als jij 7 dagen geleden tussen 20:00 en 21:00 meer requests hebt gedaan dan vandaag tussen 20:00 en 21:00, dan wordt het getal kleiner als de achterkant van de log wordt overschreven met de nieuwe data van vandaag

[EverLast2002]

Starck schreef op woensdag 27 augustus 2025 @ 21:01:
[...]


Zijn alle statistieken op het dashboard niet van de afgelopen 24 uur? Dus als jij 24 uur geleden meer requests deed dan nu, dan zou het getal inderdaad kleiner worden, de oude verlopen dan namelijk.

De statistieken zijn geen 24 uur oud nee, ik had het net weer (afnemend totaal) en hier zat 1 uur tussen ververs moment.

[EverLast2002]

- muntje is gevallen, ik snap hem!

[mathijsdelva]

Ik heb wat hulp nodig. Ik ben helemaal niet thuis in deze zaken dus voor mij is echt alles nieuw. Ik heb een Raspberry Pi4 gekocht en die aangesloten op mijn Telenet modem met ethernet. De wifi van deze modem staat uit, want na m'n modem heb ik een Unify U7 Lite hangen verderop in m'n huis, verbonden via ethernet. De microSD in m'n Raspberry bevat Home Assistant. Via de add-on AdGuard Home probeer ik op DNS level alles te configureren zodat ik zonder ads kan surfen met al m'n apparaten op dit wifi netwerk.

Wat ik al weet is dat Telenet (fckers..) geen DNS changes toelaat in hun mijn.telenet.be. Dus ik moet dat instellen per toestel. Jammer, maar op zich geen probleem.

In algemene netwerk instellingen van Home Assistant (system > network, configure network interfaces), heb ik onder ipv4 voor static gekozen (zoals aangeraden) en daarbij krijg ik twee DNS IPs. Ik ga er vanuit dat ik één van deze 2 IPs moet gebruiken als DNS op mijn aparte toestellen. Klopt dat? Als ik dat doe, dan laden m'n websites etc wel nog, wat goed is, maar ik zie wel nog alle ads. Ik doe dus iets mis gok ik dan..

De log van m'n add-on zegt zaken als:
2025/08/29 12:43:47.000509 [info] dnsproxy: entering udp listener loop addr=127.0.0.1:53
2025/08/29 12:43:47.000509 [info] dnsproxy: entering listener loop proto=tcp addr=127.0.0.1:53

Kan iemand helpen? Eeuwige dank!

[rens-br]

mathijsdelva schreef op vrijdag 29 augustus 2025 @ 13:14:
Ik heb wat hulp nodig. Ik ben helemaal niet thuis in deze zaken dus voor mij is echt alles nieuw. Ik heb een Raspberry Pi4 gekocht en die aangesloten op mijn Telenet modem met ethernet. De wifi van deze modem staat uit, want na m'n modem heb ik een Unify U7 Lite hangen verderop in m'n huis, verbonden via ethernet. De microSD in m'n Raspberry bevat Home Assistant. Via de add-on AdGuard Home probeer ik op DNS level alles te configureren zodat ik zonder ads kan surfen met al m'n apparaten op dit wifi netwerk.

Wat ik al weet is dat Telenet (fckers..) geen DNS changes toelaat in hun mijn.telenet.be. Dus ik moet dat instellen per toestel. Jammer, maar op zich geen probleem.

In algemene netwerk instellingen van Home Assistant (system > network, configure network interfaces), heb ik onder ipv4 voor static gekozen (zoals aangeraden) en daarbij krijg ik twee DNS IPs. Ik ga er vanuit dat ik één van deze 2 IPs moet gebruiken als DNS op mijn aparte toestellen. Klopt dat? Als ik dat doe, dan laden m'n websites etc wel nog, wat goed is, maar ik zie wel nog alle ads. Ik doe dus iets mis gok ik dan..

De log van m'n add-on zegt zaken als:
2025/08/29 12:43:47.000509 [info] dnsproxy: entering udp listener loop addr=127.0.0.1:53
2025/08/29 12:43:47.000509 [info] dnsproxy: entering listener loop proto=tcp addr=127.0.0.1:53

Kan iemand helpen? Eeuwige dank!

Als het goed is heeft je raspberry pi een IP adres gekregen van telenet router (of je hebt deze fixed ingesteld op iets) en deze moet je gebruiken, vermoedelijk is dat een adres die begint met 192.168.X.X.

Verder kan je in de log van adguard home kijken wat voor requests daar voorbij komen. Zie je daar iets voorbij komen?

[Yarisken]

Neem is een toestel en geef daar statisch ip in van telenet, gateway en gebruik voor dns het ip van je raspberry pi. In adguard zelf , de webinterface, ga je in de logs zien of er verkeer toekomt.

[mathijsdelva]

rens-br schreef op vrijdag 29 augustus 2025 @ 14:07:
[...]


Als het goed is heeft je raspberry pi een IP adres gekregen van telenet router (of je hebt deze fixed ingesteld op iets) en deze moet je gebruiken, vermoedelijk is dat een adres die begint met 192.168.X.X.

Verder kan je in de log van adguard home kijken wat voor requests daar voorbij komen. Zie je daar iets voorbij komen?

Correct, bij verbonden apparaten in mijn telenet zie ik de Raspberry Pi staan met IP 192.168.0.114. Maar als die IP instel als DNS op m'n iPhone, dan laadt er geen enkele website.

De log toont dit:

[11:59:55] INFO: Starting NGinx...
[11:59:55] INFO: Successfully send discovery information to Home Assistant.
s6-rc: info: service discovery successfully started
s6-rc: info: service legacy-services: starting
s6-rc: info: service legacy-services successfully started
2025/08/29 12:00:01.009202 [info] filtering: saving contents id=1 path=/data/adguard/data/filters/1.txt
2025/08/29 12:00:01.094682 [info] filtering: filter updated id=1 bytes_written=3105564 rules_count=133066
2025/08/29 12:00:01.094914 [info] filtering: updated filter id=1 rules_count=133066 prev_rules_count=0
2025/08/29 12:00:03.296914 [error] filtering: removing old filter path=/data/adguard/data/filters/1.txt err="remove /data/adguard/data/filters/1.txt.old: no such file or directory"
2025/08/29 12:35:42.982406 [info] dnsforward: starting reconfiguring server
2025/08/29 12:35:42.982546 [info] dnsproxy: stopping server
2025/08/29 12:35:42.983025 [info] dnsproxy: stopped dns proxy server
2025/08/29 12:35:43.083792 [info] addrproc: finished processing addresses
2025/08/29 12:35:43.083813 [info] dnsproxy: upstream mode is set mode=load_balance
2025/08/29 12:35:43.083924 [info] dnsproxy: cache enabled size=4096
2025/08/29 12:35:43.083979 [info] dnsproxy: max goroutines is set count=300
2025/08/29 12:35:43.084245 [info] dnsproxy: ratelimit is enabled rps=20 ipv4_subnet_mask_len=24 ipv6_subnet_mask_len=56
2025/08/29 12:35:43.084299 [info] dnsproxy: server will refuse requests of type any
2025/08/29 12:35:43.084345 [info] dnsproxy: upstream mode is set mode=load_balance
2025/08/29 12:35:43.084385 [info] dnsproxy: cache enabled size=4194304
2025/08/29 12:35:43.084428 [info] dnsproxy: max goroutines is set count=300
2025/08/29 12:35:43.085829 [info] dnsproxy: starting dns proxy server
2025/08/29 12:35:43.085941 [info] dnsproxy: creating udp server socket addr=127.0.0.1:53
2025/08/29 12:35:43.086360 [info] addrproc: processing addresses
2025/08/29 12:35:43.086389 [info] dnsproxy: listening to udp addr=127.0.0.1:53
2025/08/29 12:35:43.086480 [info] dnsproxy: creating tcp server socket addr=127.0.0.1:53
2025/08/29 12:35:43.087695 [info] dnsproxy: listening to tcp addr=127.0.0.1:53
2025/08/29 12:35:43.088072 [info] dnsforward: finished reconfiguring server
2025/08/29 12:35:43.088170 [info] dnsproxy: entering udp listener loop addr=127.0.0.1:53
2025/08/29 12:35:43.088212 [info] dnsproxy: entering listener loop proto=tcp addr=127.0.0.1:53
2025/08/29 12:43:46.891724 [info] dnsforward: starting reconfiguring server
2025/08/29 12:43:46.891885 [info] dnsproxy: stopping server
2025/08/29 12:43:46.892265 [info] dnsproxy: stopped dns proxy server
2025/08/29 12:43:46.993029 [info] addrproc: finished processing addresses
2025/08/29 12:43:46.993142 [info] dnsproxy: upstream mode is set mode=load_balance
2025/08/29 12:43:46.993370 [info] dnsproxy: cache enabled size=4096
2025/08/29 12:43:46.993428 [info] dnsproxy: max goroutines is set count=300
2025/08/29 12:43:46.993633 [info] dnsproxy: ratelimit is enabled rps=20 ipv4_subnet_mask_len=24 ipv6_subnet_mask_len=56
2025/08/29 12:43:46.993680 [info] dnsproxy: server will refuse requests of type any
2025/08/29 12:43:46.993761 [info] dnsproxy: upstream mode is set mode=load_balance
2025/08/29 12:43:46.993822 [info] dnsproxy: cache enabled size=4194304
2025/08/29 12:43:46.993870 [info] dnsproxy: max goroutines is set count=300
2025/08/29 12:43:46.996849 [info] dnsproxy: starting dns proxy server
2025/08/29 12:43:46.996987 [info] dnsproxy: creating udp server socket addr=127.0.0.1:53
2025/08/29 12:43:46.998185 [info] addrproc: processing addresses
2025/08/29 12:43:46.998424 [info] dnsproxy: listening to udp addr=127.0.0.1:53
2025/08/29 12:43:46.998966 [info] dnsproxy: creating tcp server socket addr=127.0.0.1:53
2025/08/29 12:43:46.999491 [info] dnsproxy: listening to tcp addr=127.0.0.1:53
2025/08/29 12:43:46.999647 [info] dnsforward: finished reconfiguring server
2025/08/29 12:43:47.000509 [info] dnsproxy: entering udp listener loop addr=127.0.0.1:53
2025/08/29 12:43:47.000509 [info] dnsproxy: entering listener loop proto=tcp addr=127.0.0.1:53
2025/08/29 13:31:33.376661 [info] dnsforward: starting reconfiguring server
2025/08/29 13:31:33.376814 [info] dnsproxy: stopping server
2025/08/29 13:31:33.377182 [info] dnsproxy: stopped dns proxy server
2025/08/29 13:31:33.477917 [info] dnsproxy: upstream mode is set mode=load_balance
2025/08/29 13:31:33.478006 [info] dnsproxy: cache enabled size=4096
2025/08/29 13:31:33.478056 [info] dnsproxy: max goroutines is set count=300
2025/08/29 13:31:33.478245 [info] dnsproxy: ratelimit is enabled rps=20 ipv4_subnet_mask_len=24 ipv6_subnet_mask_len=56
2025/08/29 13:31:33.478290 [info] dnsproxy: server will refuse requests of type any
2025/08/29 13:31:33.478332 [info] dnsproxy: upstream mode is set mode=load_balance
2025/08/29 13:31:33.478368 [info] dnsproxy: cache enabled size=4194304
2025/08/29 13:31:33.478410 [info] dnsproxy: max goroutines is set count=300
2025/08/29 13:31:33.479223 [info] dnsproxy: starting dns proxy server
2025/08/29 13:31:33.479321 [info] dnsproxy: creating udp server socket addr=127.0.0.1:53
2025/08/29 13:31:33.479352 [info] addrproc: finished processing addresses
2025/08/29 13:31:33.479386 [info] addrproc: processing addresses
2025/08/29 13:31:33.479671 [info] dnsproxy: listening to udp addr=127.0.0.1:53
2025/08/29 13:31:33.479732 [info] dnsproxy: creating tcp server socket addr=127.0.0.1:53
2025/08/29 13:31:33.480053 [info] dnsproxy: listening to tcp addr=127.0.0.1:53
2025/08/29 13:31:33.480152 [info] dnsforward: finished reconfiguring server
2025/08/29 13:31:33.480659 [info] dnsproxy: entering listener loop proto=tcp addr=127.0.0.1:53
2025/08/29 13:31:33.480903 [info] dnsproxy: entering udp listener loop addr=127.0.0.1:53
2025/08/29 13:38:29.204853 [info] dnsforward: starting reconfiguring server
2025/08/29 13:38:29.205004 [info] dnsproxy: stopping server
2025/08/29 13:38:29.205571 [info] dnsproxy: stopped dns proxy server
2025/08/29 13:38:29.306269 [info] addrproc: finished processing addresses
2025/08/29 13:38:29.306304 [info] dnsproxy: upstream mode is set mode=load_balance
2025/08/29 13:38:29.306391 [info] dnsproxy: cache enabled size=4096
2025/08/29 13:38:29.306444 [info] dnsproxy: max goroutines is set count=300
2025/08/29 13:38:29.306692 [info] dnsproxy: ratelimit is enabled rps=20 ipv4_subnet_mask_len=24 ipv6_subnet_mask_len=56
2025/08/29 13:38:29.306747 [info] dnsproxy: server will refuse requests of type any
2025/08/29 13:38:29.306795 [info] dnsproxy: upstream mode is set mode=load_balance
2025/08/29 13:38:29.306833 [info] dnsproxy: cache enabled size=4194304
2025/08/29 13:38:29.306876 [info] dnsproxy: max goroutines is set count=300
2025/08/29 13:38:29.307708 [info] dnsproxy: starting dns proxy server
2025/08/29 13:38:29.307804 [info] dnsproxy: creating udp server socket addr=127.0.0.1:53
2025/08/29 13:38:29.308006 [info] addrproc: processing addresses
2025/08/29 13:38:29.308164 [info] dnsproxy: listening to udp addr=127.0.0.1:53
2025/08/29 13:38:29.308677 [info] dnsproxy: creating tcp server socket addr=127.0.0.1:53
2025/08/29 13:38:29.309187 [info] dnsproxy: listening to tcp addr=127.0.0.1:53
2025/08/29 13:38:29.309360 [info] dnsforward: finished reconfiguring server
2025/08/29 13:38:29.309557 [info] dnsproxy: entering udp listener loop addr=127.0.0.1:53
2025/08/29 13:38:29.309854 [info] dnsproxy: entering listener loop proto=tcp addr=127.0.0.1:53
2025/08/29 13:39:19.318360 [error] POST homeassistant.local:8123 /control/dns_config: validating dns config: upstream servers: parsing error at index 1: cannot prepare the upstream: unsupported url scheme: http

[ Voor 0% gewijzigd door rens-br op 29-08-2025 14:49 . Reden: quote tags ]

[rens-br]

mathijsdelva schreef op vrijdag 29 augustus 2025 @ 14:48:
[...]


Correct, bij verbonden apparaten in mijn telenet zie ik de Raspberry Pi staan met IP 192.168.0.114. Maar als die IP instel als DNS op m'n iPhone, dan laadt er geen enkele website.

Dat is in ieder geval het ip adres wat je moet hebben. Ik ben niet zo bekend met de HA integratie van Adguard home, maar ik zou verwachten dat je ook gewoon naar (in jouw geval) 192.168.0.114:90 kan gaan om de webinterface van adguard te gaan en daar zaken in te stellen. (en ook de client log te bekijken) heb je dat al gedaan?

Uit de logs die je nu gedeeld hebt kan ik zelf niet zoveel halen, al lijkt het erop dat adguard home niet (goed) draait.

Edit 324. Welke addon gebruik je? Is dat https://github.com/hassio-addons/addon-adguard-home? Zoja, heb je al deze stappen gevolgd? https://github.com/hassio...blob/main/adguard/DOCS.md

[ Voor 20% gewijzigd door rens-br op 29-08-2025 14:55 ]

[mathijsdelva]

Klopt, https://github.com/hassio-addons/addon-adguard-home. Ik kan ook niet 192.168.0.114:90 bezoeken ofzo, direct 404. http://homeassistant.local:8123 draait wel gewoon perfect natuurlijk. Als ik ga kijken bij het dashboard van Adguard Home zelf, dan zie ik overal 0 wat betekent dat het internetverkeer niet via Adguard Home gaat denk ik dan..

Edit: Ik heb inderdaad die docs gevolgd en dus ook die static ip gezet voor m'n ipv4.

[ Voor 11% gewijzigd door mathijsdelva op 29-08-2025 14:59 ]

[mathijsdelva]

Hm, Ik las net iets op GitHub van iemand:

I figured out the issue. I wanted to post if someone is a newbie like me and has the same problem. I didn't know the 53/UDP port needed to be open. I opened 53 TCP ports but UDP needed to be open. I just added a DNS service of ports in the firewall it solved the issue.
The only issue I'm having with ipv6. There isn't an option in the Netgear router to disable ipv6 and adding adguard's ipv6 in the router isn't working. Whenever I replace ISP's ipv6 DNS with adguard's DNS network stops working. Though the ipv6 service is already opened from the firewall. If I could disable ipv6 from my router I couldn't care but the issue is apple devices are ipv6's DNS with adguard's DNS.

Op mijn telenet zie ik dit staan:


Als ik het goed begrijp wordt poort 53 gebruikt voor AdGuard Home en die is net niet toegelaten bij Telenet?

[henk26]

Zijn er meer gebruikers waar sinds dit weekend de rabobank app niet meer werkt? Ik zie dat bepaalde domeinen van .rabobank.nl worden geblokkeerd waardoor de bankapp weigert verbinding te maken.

[stormfly]

henk26 schreef op dinsdag 2 september 2025 @ 12:01:
Zijn er meer gebruikers waar sinds dit weekend de rabobank app niet meer werkt? Ik zie dat bepaalde domeinen van .rabobank.nl worden geblokkeerd waardoor de bankapp weigert verbinding te maken.

Nee geen last van, zal door één bepaalde lijst komen?

[henk26]

stormfly schreef op dinsdag 2 september 2025 @ 12:08:
[...]


Nee geen last van, zal door één bepaalde lijst komen?

Klopt, in de standaard Adguard DNS lijst wordt het rabobank domein geblokkeerd. Kennelijk is de bank zelf nu ook verdacht ;-). Nu ik het domein heb gewhitelist werkt het weer.

[Hmmbob]

Ah, ik kreeg de laatste tijd wel een popup "Geen verbinding met de bank" oid, maar na de vingerafdruk werkte het dan toch weer.

Edit; dat gezegd hebbende; nu nergens last van

[ Voor 16% gewijzigd door Hmmbob op 02-09-2025 13:34 ]

[bart.koppers]

mathijsdelva schreef op vrijdag 29 augustus 2025 @ 14:57:
Klopt, https://github.com/hassio-addons/addon-adguard-home. Ik kan ook niet 192.168.0.114:90 bezoeken ofzo, direct 404. http://homeassistant.local:8123 draait wel gewoon perfect natuurlijk. Als ik ga kijken bij het dashboard van Adguard Home zelf, dan zie ik overal 0 wat betekent dat het internetverkeer niet via Adguard Home gaat denk ik dan..

Edit: Ik heb inderdaad die docs gevolgd en dus ook die static ip gezet voor m'n ipv4.

Heb je in de AGH addon wel Upstream DNS servers ingesteld (bv je router of Dns addressen van je provider), en bootstrap servers ingesteld? (1.1.1.1 of 8.8.8.8 bv?)

[ Voor 6% gewijzigd door bart.koppers op 02-09-2025 15:42 ]

[bart.koppers]

mathijsdelva schreef op vrijdag 29 augustus 2025 @ 15:11:
Hm, Ik las net iets op GitHub van iemand:

I figured out the issue. I wanted to post if someone is a newbie like me and has the same problem. I didn't know the 53/UDP port needed to be open. I opened 53 TCP ports but UDP needed to be open. I just added a DNS service of ports in the firewall it solved the issue.
The only issue I'm having with ipv6. There isn't an option in the Netgear router to disable ipv6 and adding adguard's ipv6 in the router isn't working. Whenever I replace ISP's ipv6 DNS with adguard's DNS network stops working. Though the ipv6 service is already opened from the firewall. If I could disable ipv6 from my router I couldn't care but the issue is apple devices are ipv6's DNS with adguard's DNS.

Op mijn telenet zie ik dit staan:
[Afbeelding]

Als ik het goed begrijp wordt poort 53 gebruikt voor AdGuard Home en die is net niet toegelaten bij Telenet?

Met de Telenet router heeft het weinig van doen. Die heeft zijn eigen DNS draaien voor LAN

Jouw client wil je instellen zodat het HA ip-adres wordt gebruikt, toch.
Daar draait dan AGH (via de Addon), op port 53

(En die “tip” over forwarden van DNS verkeer vanuit de router: ik raad je dat ten zeerste af. Tenzij je dat kan limiteren tot LAN only. Er is geen reden dat clients van buiten request moeten plaatsen bij jouw DNService (intern) toch?)

[mathijsdelva]

Het is mij ondertussen gelukt, hoewel ik niet kan uitleggen waarom het wel ineens werkt. Ik heb eigenlijk niets veranderd.. Nu, er zijn mij ondertussen ook wat zaken duidelijk geworden. DNS level adguard biedt mij relatief weinig extra voordeel tov local apps op m'n Mac / iPhone gezien je daar betere adblocking hebt dan op DNS niveau (YouTube als één voorbeeld). Het is zelfs zo dat er wat issues zijn wat betreft adblocking op m'n Mac als ik de DNS instel tov de local app en die al dan niet aanzet terwijl de DNS aanstaat. Beetje teleurstellend.

[Mirabis]

mathijsdelva schreef op woensdag 3 september 2025 @ 09:11:
Het is mij ondertussen gelukt, hoewel ik niet kan uitleggen waarom het wel ineens werkt. Ik heb eigenlijk niets veranderd.. Nu, er zijn mij ondertussen ook wat zaken duidelijk geworden. DNS level adguard biedt mij relatief weinig extra voordeel tov local apps op m'n Mac / iPhone gezien je daar betere adblocking hebt dan op DNS niveau (YouTube als één voorbeeld). Het is zelfs zo dat er wat issues zijn wat betreft adblocking op m'n Mac als ik de DNS instel tov de local app en die al dan niet aanzet terwijl de DNS aanstaat. Beetje teleurstellend.

Voordeel zit er toch juist in dat je niet op elk apparaat de Adguard (of gelijke) app hoeft te installeren en instellen. Je kan netwerkwijd ook ads en ongewenst verkeer blokkeren van IoT apparaten, random tablets, tv, etc. Mijn iPhone heeft ook de Adguard app en kan daar een groot deel lokaal afvangen, maar alle DNS blokkades etc handel ik centraal af met Adguard Home. Statistisch gezien wordt 31% van de requests in mijn netwerk (~80 clients) geblokkeerd door Adguard Home.

[mathijsdelva]

bart.koppers schreef op dinsdag 2 september 2025 @ 15:33:
[...]


Heb je in de AGH addon wel Upstream DNS servers ingesteld (bv je router of Dns addressen van je provider), en bootstrap servers ingesteld? (1.1.1.1 of 8.8.8.8 bv?)

Kan je even een voorbeeldlijst geven?

[bart.koppers]

mathijsdelva schreef op woensdag 3 september 2025 @ 11:02:
[...]


Kan je even een voorbeeldlijst geven?

Waarvan?

Beste om Adguard te configureren via de webpage in HA.
Je kan ook direct naar http://<ip_van_HA>:3000

[Hmmbob]

download: AdGuard Home 0.107.66