[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!