[AdGuard Home] Ervaringen & discussie

[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

[sennevb]

TheCeet schreef op woensdag 28 mei 2025 @ 08:16:
@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.

Hallo, ik heb onderstaande blocklist, toch komen de ads van vtm go nog steeds door.

Ik heb de google dns servers geblockt in de firewall..
Ik zie in adguard toch traffic van dpgmedia passeren.

Heb jij andere blocklists misschien?

[TheCeet]

@sennevb
Om te beginnen een tip, vervang de link van OISD naar https://big.oisd.nl

Hierbij opsomming van mijn blocklists, en ik heb geen ads in VTMGO

code:

https://adguardteam.github.io/HostlistsRegistry/assets/filter_1.txt
https://adguardteam.github.io/HostlistsRegistry/assets/filter_3.txt
https://adguardteam.github.io/HostlistsRegistry/assets/filter_18.txt
https://adguardteam.github.io/HostlistsRegistry/assets/filter_33.txt
https://raw.githubusercontent.com/Perflyst/PiHoleBlocklist/master/SmartTV-AGH.txt
https://adguardteam.github.io/HostlistsRegistry/assets/filter_51.txt

AdGuard DNS filter
OISD Blocklist Big
Peter Lowe's Blocklist
Phishing Army
Steven Black's List
SmartTV
HaGeZi's Pro++ Blocklist

Op welk toestel zie je toch ads van VTM GO?

[sennevb]

TheCeet schreef op zaterdag 20 september 2025 @ 19:48:
@sennevb
Om te beginnen een tip, vervang de link van OISD naar https://big.oisd.nl

Hierbij opsomming van mijn blocklists, en ik heb geen ads in VTMGO

code:

https://adguardteam.github.io/HostlistsRegistry/assets/filter_1.txt
https://adguardteam.github.io/HostlistsRegistry/assets/filter_3.txt
https://adguardteam.github.io/HostlistsRegistry/assets/filter_18.txt
https://adguardteam.github.io/HostlistsRegistry/assets/filter_33.txt
https://raw.githubusercontent.com/Perflyst/PiHoleBlocklist/master/SmartTV-AGH.txt
https://adguardteam.github.io/HostlistsRegistry/assets/filter_51.txt

AdGuard DNS filter
OISD Blocklist Big
Peter Lowe's Blocklist
Phishing Army
Steven Black's List
SmartTV
HaGeZi's Pro++ Blocklist

Op welk toestel zie je toch ads van VTM GO?

Ik heb al deze blocklist toegevoegd, nog steeds heb ik ads.
Ik heb het zowel op mijn nvidia shield als de lg smart tv.
Ik block standaard de google dns omdat ik weet dat nvidia die anders in de achtergrond nog gebruikt.

Dit is een stuk van de logs v gisteravond:

[sennevb]

Ik ben intussen al wat verder, ik test c.dpmedia.net op 2 ip's en dit met schillende resultaten, iemand enig idee, aangepaste filters lijst is leeg, hier hebben ooit voor dit ip wel aangepaste regels in gestaan??:

[ Voor 11% gewijzigd door sennevb op 21-09-2025 20:08 ]

[sennevb]

update:


Instellingen stonden niet op globaal

[Glassertje]

sennevb schreef op zondag 21 september 2025 @ 18:56:
[...]

Ik heb al deze blocklist toegevoegd, nog steeds heb ik ads.
Ik heb het zowel op mijn nvidia shield als de lg smart tv.
Ik block standaard de google dns omdat ik weet dat nvidia die anders in de achtergrond nog gebruikt.

Dit is een stuk van de logs v gisteravond:
[Afbeelding]

Als de de Hagezi blocklist toevoegt, wordt c.dpgmedia.net ook geblokkeerd in iedere blocklijst.

[sennevb]

TheCeet schreef op zaterdag 20 september 2025 @ 19:48:
@sennevb
Om te beginnen een tip, vervang de link van OISD naar https://big.oisd.nl

Hierbij opsomming van mijn blocklists, en ik heb geen ads in VTMGO

code:

https://adguardteam.github.io/HostlistsRegistry/assets/filter_1.txt
https://adguardteam.github.io/HostlistsRegistry/assets/filter_3.txt
https://adguardteam.github.io/HostlistsRegistry/assets/filter_18.txt
https://adguardteam.github.io/HostlistsRegistry/assets/filter_33.txt
https://raw.githubusercontent.com/Perflyst/PiHoleBlocklist/master/SmartTV-AGH.txt
https://adguardteam.github.io/HostlistsRegistry/assets/filter_51.txt

AdGuard DNS filter
OISD Blocklist Big
Peter Lowe's Blocklist
Phishing Army
Steven Black's List
SmartTV
HaGeZi's Pro++ Blocklist

Op welk toestel zie je toch ads van VTM GO?

@TheCeet

Bij mij word het nu eindelijk geblokt, maar iets te goed.

Het startscherm van vtm go duurt nu heel lang, als ik daar voorbij geraak en een aflevering kies dan blijft de cursor maar draaien en word er geen aflevering gestart

[sennevb]

Bij mij word het nu eindelijk geblokt, maar iets te goed.

Het startscherm van vtm go duurt nu heel lang, als ik daar voorbij geraak en een aflevering kies dan blijft de cursor maar draaien en word er geen aflevering gestart

Na 1 min wachten (soms langer) start de aflevering dan toch door, probeert hij bij jullie ook zo lang de reclame af te spelen?

[TheCeet]

@sennevb
Op AndroidTV start alles instant. Idem browser.
Is wel al effe geleden.

Ik test later deze avond en pas deze post aan.


EDIT:
Met de nodige vertraging is hier feedback.
Getest in Chrome browser op laptop, na klikken op iets 'Special Forces' genomen als voorbeeld, max 5sec het loading icoontje, en dan start meteen de aflevering. Soms 2sec, maar langste duurde 5sec.
Querylog kan ik niet goed afleiden welke domains nu werking hebben op VTMGo

[ Voor 54% gewijzigd door TheCeet op 23-09-2025 09:29 ]

[sennevb]

TheCeet schreef op maandag 22 september 2025 @ 19:47:
@sennevb
Op AndroidTV start alles instant. Idem browser.
Is wel al effe geleden.

Ik test later deze avond en pas deze post aan.

oke bedankt!
op de LG smarttv worden de ads niet geblockt, maar ik ben de logs aan het bekijken ,deze gebruiken andere adressen dan de android app..
Ik ga nu trial and error doen en proberen het juiste DNS call te blocken.

[Kindrih]

Ik heb een tijdje nu AdGuard draaien, nu valt mij het volgende op: extreem veel pings naar een Delta site vanaf mijn TpLink x20 netwerk welke ik ook van Delta heb gekregen. Nu vraag ik mij af zit er in de software van de tplink een koppeling met Delta? Betreft de volgende site x20.tplink.acs.dfn.nl
Meer mensen die hier “last” van hebben?

[quovadis25]

als ik die dns request in gemini draai, krijg ik het volgende:

"x20.tplink.acs.dfn.nl" is een DNS-aanvraag, wat een query is naar het Domain Name System (DNS) om een voor mensen leesbare domeinnaam te vertalen naar een IP-adres.

Deze specifieke domeinnaam lijkt gerelateerd te zijn aan een TP-Link-router en een dienst genaamd "ACS," wat staat voor Auto Configuration Server. ACS is een onderdeel van het TR-069-protocol, dat door internetproviders (ISP's) wordt gebruikt om apparatuur bij de klant (CPE) zoals routers en modems op afstand te beheren en te configureren.

De onderdelen van de domeinnaam suggereren het volgende:

x20: Zou een specifiek model of een versie van een TP-Link-apparaat kunnen zijn.

tplink: Identificeert de fabrikant van het apparaat als TP-Link.

acs: Verwijst naar de Auto Configuration Server.

dfn.nl: Een domein dat waarschijnlijk toebehoort aan een serviceprovider of een organisatie in Nederland, aangegeven door het landcode-topleveldomein (nl).

Wanneer een router wordt ingeschakeld, kan deze een DNS-aanvraag naar een dergelijk domein sturen om het IP-adres van zijn aangewezen ACS te vinden. Dit stelt de internetprovider in staat om automatisch firmware-updates door te voeren, problemen op te lossen of nieuwe configuraties toe te passen op de router zonder handmatige tussenkomst van de gebruiker.

[Kindrih]

quovadis25 schreef op maandag 22 september 2025 @ 20:54:
als ik die dns request in gemini draai, krijg ik het volgende:


[...]

Bedankt voor het uitzoeken! Dan zit er blijkbaar een stukje software van Delta in de X20 versterkers welke nieuw uit doos zijn gekomen, bijzonder.

[Videopac]

0.107.67 is uit.

[SED]

@Kindrih
Lees ook:
https://service-provider.tp-link.com/solution/25/

[kooswerker]

weet iemand hoe je de ads kunt omzeilen van npo strart/videoland?
voorheen werkte AdGuard Home nog prima op de Android app en browser
heb een paar filters geprobeerd maar niks werkt tot heden

[ThinkPad]

Is er ook iemand die size_memory in de YAML-config nog getweaked heeft? Dat is het aantal queries wat hij van de querylog in het geheugen houdt (bij bekijken van de log).
Zie uitleg: https://github.com/Adguar...rdhome/wiki/Configuration

Ik vond dat wat traag, dus heb het opgeschroefd van 1k naar 40k, dat is bij mij ongeveer 2-3 dagen aan queries. Ik heb AGH als plugin op m'n OPNsense router draaien, die heeft zat geheugen (8GB totaal, amper de helft in gebruik) dus doe liefst zoveel mogelijk in RAM, dat is nog altijd sneller dan m'n (SATA) SSD.

[ Voor 38% gewijzigd door ThinkPad op 15-10-2025 16:25 ]

[Villager]

ThinkPad schreef op woensdag 15 oktober 2025 @ 16:13:
Is er ook iemand die size_memory in de YAML-config nog getweaked heeft? Dat is het aantal queries wat hij van de querylog in het geheugen houdt (bij bekijken van de log).
Zie uitleg: https://github.com/Adguar...rdhome/wiki/Configuration

Ik vond dat wat traag, dus heb het opgeschroefd van 1k naar 40k, dat is bij mij ongeveer 2-3 dagen aan queries. Ik heb AGH als plugin op m'n OPNsense router draaien, die heeft zat geheugen (8GB totaal, amper de helft in gebruik) dus doe liefst zoveel mogelijk in RAM, dat is nog altijd sneller dan m'n (SATA) SSD.

Ik heb het ook op 40K gezet. Eens aankijken wat het effect zal zijn. Minder disk writes is altijd beter.

[clubeddie]

Na 4 dagen prutsen, wel iets wijzer, niets verder hier maar eens een poging doen.
Sinds vorige week over op delta glasvezel en sindsdien heb ik helaas weer advertenties in mijn browser (hemel, wat zijn dat er veel), druk bezig geweest om alles te herstellen, maar zonder resultaat.

in mijn router uiteraard de dns van mijn adguard als eerste opgenomen, maar helaas. Na een tijd zoeken kwam ik erachter dat al mijn devices ineens en ipv6 adres hadden. En ook als ik op mijn smartphone bijvoorbeeld alles statisch instelde had ik nog steeds advertenties en zag ik niets in de logging voorbij komen vanaf dit ip adres. Druk gezocht op internet, nieuwe adguard installatie geprobeerd, aan de slag geweest met opnsense, maar op de een of andere manier blijft het lastig met ipv6. Op mijn windows pc de test gedaan door ipv6 uit te schakelen en tadaa... alles werkte weer van ouds.

Ik kan ipv6 niet uitzetten in het glasvezel modem, zover ik heb kunnen zien maakt dat ook niet uit, want als het eenmaal actief is op je netwerk kan je ook ipv6 adressen van buitenaf krijgen ? Ik snap nog niet zoveel van ipv6.

Kan adguard home niet overweg met ipv6? Ik kan online betrekkelijk weinig vinden en wat ik vind helpt me niet op de goede weg. Hier ook gezocht op ipv6, geeft 7 pagina's met resultaten, maar niet iets wat mij heeft geholpen. Het lijkt me dat adguard hiermee overweg zou moeten kunnen, maar of ik zie iets gruwelijks over het hoofd of ik snap er nog minder van dat ik dacht.

Heeft iemand hier een geniaal idee, waarmee ik de boel weer gewoon aan de praat krijg of is de enige optie de router in bridge zetten en een ander apparaat erachter hangen. Zoals gezegd heb ik een opnsense omgeving gebouwd in mijn proxmox server met dubbele nic, maar zelfs die kreeg het voor elkaar om ipv6 adressen via de een of andere route er doorheen te sluizen. Geen idee hoe, met rules uitgeschakeld, zonder resultaat. Maar een beetje normaal internetten anno 2025 is gewoon niet meer te doen met al die k.u.t. reclames. Ik hoop dat iemand een oplossing hier heeft.

[Kroonkurk]

Op welk device draait de AGH ?
Heeft die een ipv6 adres ?
Dan kan je in de router hopelijk naast een ipv4 adres voor de dns server ook een ipv6 adres voor de dns server instellen ?

[Ragger]

Zoek naar het interne ipv6-adres van het AGH-apparaat. Dat begint zeer waarschijnlijk met fe80. Die zet je ook in je router.

[Ringgss]

Deze kan je ook zien op de installatie gids tab in Adguard home ( /#guide )

[tomdh76]

Ik heb een soortgelijke setup. OPNsense op proxmox en dan de adguard plugin voor OPNsense. Bij mij werkt het goed. Ik zie ook in de query ipv6 adressen van clients (adres zoals 2000:xxxx etc). heb je in je upstream dns servers wel ipv6 adressen?

[EverLast2002]

clubeddie schreef op zondag 19 oktober 2025 @ 20:45:
Na 4 dagen prutsen, wel iets wijzer, niets verder hier maar eens een poging doen.
Sinds vorige week over op delta glasvezel en sindsdien heb ik helaas weer advertenties in mijn browser (hemel, wat zijn dat er veel), druk bezig geweest om alles te herstellen, maar zonder resultaat.

in mijn router uiteraard de dns van mijn adguard als eerste opgenomen, maar helaas. Na een tijd zoeken kwam ik erachter dat al mijn devices ineens en ipv6 adres hadden. En ook als ik op mijn smartphone bijvoorbeeld alles statisch instelde had ik nog steeds advertenties en zag ik niets in de logging voorbij komen vanaf dit ip adres. Druk gezocht op internet, nieuwe adguard installatie geprobeerd, aan de slag geweest met opnsense, maar op de een of andere manier blijft het lastig met ipv6. Op mijn windows pc de test gedaan door ipv6 uit te schakelen en tadaa... alles werkte weer van ouds.

Ik kan ipv6 niet uitzetten in het glasvezel modem, zover ik heb kunnen zien maakt dat ook niet uit, want als het eenmaal actief is op je netwerk kan je ook ipv6 adressen van buitenaf krijgen ? Ik snap nog niet zoveel van ipv6.

Kan adguard home niet overweg met ipv6? Ik kan online betrekkelijk weinig vinden en wat ik vind helpt me niet op de goede weg. Hier ook gezocht op ipv6, geeft 7 pagina's met resultaten, maar niet iets wat mij heeft geholpen. Het lijkt me dat adguard hiermee overweg zou moeten kunnen, maar of ik zie iets gruwelijks over het hoofd of ik snap er nog minder van dat ik dacht.

Heeft iemand hier een geniaal idee, waarmee ik de boel weer gewoon aan de praat krijg of is de enige optie de router in bridge zetten en een ander apparaat erachter hangen. Zoals gezegd heb ik een opnsense omgeving gebouwd in mijn proxmox server met dubbele nic, maar zelfs die kreeg het voor elkaar om ipv6 adressen via de een of andere route er doorheen te sluizen. Geen idee hoe, met rules uitgeschakeld, zonder resultaat. Maar een beetje normaal internetten anno 2025 is gewoon niet meer te doen met al die k.u.t. reclames. Ik hoop dat iemand een oplossing hier heeft.

Heb je IPv6 ook uitgezet in je Proxmox host?
Ik heb in mijn OPNsense IPv6 d.m.v. een checkbox UIT staan.
Verder doe ik niks met IPv6 en heb het overal uitgeschakeld.

[TheCeet]

Hier toch maar eventjes waarschuwen. Voor diegene die DNS0 gebruik(t)en:
nieuws: Europese publieke DNS-resolver dns0 stopt per direct vanwege tijd- en...

[ThinkPad]

Is bij mij nooit sneller geweest dan Quad9. Herkomst was volgens mij ook discutabel, of het wel een volledig Europees bedrijf was (zelfde oprichters als NextDNS, wat een Amerikaans bedrijf is).

Ik gebruik 3 upstream servers: Quad9, de snelste van m'n provider (Solcon) en DNS.SB.
Kwestie van meerdere servers toevoegen in AGH, stats resetten en dan 1-2wk ofzo aankijken waar de meeste hits naartoe gaan. Met de setting 'parallel requests' wordt dat gauw duidelijk. Quad9 staat bij mij altijd bovenaan, daarna provider, daarna DNS.SB

Die DNS4EU is helemaal langzaam.

[ Voor 5% gewijzigd door ThinkPad op 21-10-2025 11:49 ]

[Glassertje]

AdGuard Home v0.107.68

[lolgast]

Ben ik een keer de eerste! 2 bugs gefixt, weinig spannends verder

download: AdGuard Home 0.107.69

[stormfly]

ThinkPad schreef op woensdag 15 oktober 2025 @ 16:13:
Is er ook iemand die size_memory in de YAML-config nog getweaked heeft? Dat is het aantal queries wat hij van de querylog in het geheugen houdt (bij bekijken van de log).
Zie uitleg: https://github.com/Adguar...rdhome/wiki/Configuration

Ik vond dat wat traag, dus heb het opgeschroefd van 1k naar 40k, dat is bij mij ongeveer 2-3 dagen aan queries. Ik heb AGH als plugin op m'n OPNsense router draaien, die heeft zat geheugen (8GB totaal, amper de helft in gebruik) dus doe liefst zoveel mogelijk in RAM, dat is nog altijd sneller dan m'n (SATA) SSD.

Tnx voor de headsup, dit maakt de query log flink sneller.

[ThinkPad]

Ja gaat hier ook vlotter, heb het nu twee week draaien en geen negatieve gevolgen gemerkt

[HollowGamer]

Het was mij vandaag niet gelukt met IPv6 en op de Synlogy als container AGH.

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.

[ThinkPad]

Ok, (voor mij) hele irritante manco gevonden: je kan niet HTTPS voor de webinterface of DNS-over-HTTPS server apart gebruiken.

port_https: The HTTPS port. Used for both web UI and DNS-over-HTTPS.

en

If 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.

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.

[ Voor 17% gewijzigd door ThinkPad op 15-11-2025 09:43 ]

[HollowGamer]

@ThinkPad Ik doe dit altijd, en vrijwel nooit meer via de applicaties zelf. Heb zelf lokaal een self signed Caddy certificaat, dat is voor mij hier lokaal prima, en die management dan ook dit centraal.

[Mirabis]

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.

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.

[HollowGamer]

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.

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.

[lolgast]

@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

[sjongenelen]

Ik ook. In AGH een rewrite rule obv source ip subnet

[HollowGamer]

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

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?

Ik doe dit namelijk wel voor Synology met dynamic-DNS, maar dacht juist dat dit kon doordat hij wel een IP-adres doorgeeft?

[Mirabis]

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.

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.

[HollowGamer]

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.

Maar je exposed dus wel je webserver?

Als dit beter in een eigen topic moet, dan hoor ik het wel.

[Mirabis]

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.

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.

[TheCeet]

Hier nog Tweakers die via Proxmox Helper Scripts AdguardHome draaien in Proxmox?
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 ]

[PaulHelper]

Ik heb geen idee of dit hier hoort maar ik probeer het maar.
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?

[HollowGamer]

@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.

[PaulHelper]

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.

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.

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 ]

[sjongenelen]

Wildcard cert is echt wel nodig als je client ids wil gebruiken met DoH

[alex3305]

@HollowGamer Er is voor zover ik weet geen beperking op diepte van multi-level subdomains . Dat zou ook raar zijn, aangezien het voor certbot geen fluit uitmaakt hoe diep je een certificaat aanvraagt. Tegelijkertijd is een wildcard van een wildcard niet toegestaan. Dus *.*.example.com mag niet. Maar ook *.foo.*.example.com mag niet.

@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:



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 . Dat vond ik zo irritant dat ik deze setup voor nu achter me heb gelaten. Alhoewel ik toch moet toegeven dat ik recent wel weer aan het testen ben geweest met DNS-over-TLS , maar dan de reverse proxy de TLS termination laat doen.

Momenteel gebruik ik buitenshuis een Wireguard tunnel met (twee) AdGuard Home als DNS server. Dat werkt vooralsnog wat betrouwbaarder.

[Glassertje]

sjongenelen schreef op woensdag 26 november 2025 @ 09:33:
Wildcard cert is echt wel nodig als je client ids wil gebruiken met DoH

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

[ Voor 5% gewijzigd door Glassertje op 26-11-2025 12:05 ]

[sjongenelen]

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

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.

[sjongenelen]

Overigens heb ik in agh een custom rule, die mijn domain rewrite naar agh IP en niet de modem. Heb zelf geen drops

[HollowGamer]

@alex3305 Je hebt gelijk! Is het wel niet zo dat sommige apps/websites het niet zo leuk vinden?

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.

[alex3305]

@HollowGamer De diepte van het domein maakt het certificaat of de certificaat-chain in principe geen biet uit. Sterker nog, het certificaat wordt uitgegeven voor 1 of meerdere (sub)domeinen. Of dat dan een Let's Encrypt certificaat is of iets anders, is irrelevant. Hetzelfde geldt overigens voor DNS, waar de enige beperking is dat het record niet over de 255 bytes heen mag. Een entry eindigt vervolgens (volgens RFC1035 in een null label en een zero byte:

quote: RFC1035

3.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.

Multi-level domeinen (en certificaten) zijn overigens bijzonder gewenst . In mijn thuissituatie heb ik onder andere *.clients.example.com en *.nodes.example.com. De clients zijn daarbij de apparaten die eindgebruikers gebruiken, waaronder tablets, telefoons en computers. En de nodes zijn de servers. Daar zit dan mijn (zelfbouw) NAS, een paar Pi's en een Nuc bij. Maar ook een backup machine in Canada.

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.

[Vorkie]

Heb je vandaag problemen met o.a. microsoft.com en google.com, check even of je niet https://dbl.oisd.nl/ gebruikt...

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 ]

[ronaldtb]

Ik had de laatste paar dagen regelmatig problemen met het downloaden sommige podcasts. Die bleken geblokkeerd te zijn



edit: Volgens OISD.nl staat npo.nl op geen enkele block list…

[ Voor 9% gewijzigd door ronaldtb op 30-11-2025 10:50 ]

[jurroen]

ronaldtb schreef op zondag 30 november 2025 @ 10:24:
edit: Volgens OISD.nl staat npo.nl op geen enkele block list…

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).

[ronaldtb]

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).

Dat klopt en dat weet ik, maar dan staat dat er bij. Dit werd echt geblokkeerd door de OISD NSFW list.

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 ]

[Sinna]

Ik loop - nu mijn netwerk IPv6 ondersteunt - tegen het volgende aan op een AGH-installatie binnen HA (al vermoed ik dat het bij een een 'gewone' AGH niet anders zal zijn): ik zie DNS-requests gelogd worden vanaf het IPv6-adres van mijn clients, maar als ik hiervoor cliëntinstellingen maak, dan worden die keihard genegeerd.
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?

[gerritjan]

Software-update: AdGuard Home 0.107.70

[Harmen]

gerritjan schreef op donderdag 4 december 2025 @ 18:51:
Software-update: AdGuard Home 0.107.70

Heb gisteren geupdate, merk dat de Average processing speed omhoog is gegaan. Van 0.5ms naar 15ms.



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 ]

[FLA NL]

Ook maar terug gegaan naar de vorige versie. Voor maandag staat de fix gepland kan je nu in het issue zien.