Software-update: AdGuard Home 0.107.15

AdGuard Home versie 0.107.15 is uitgekomen. Met deze software kan er thuis een dns-server worden opgezet om zo onder meer advertenties en malware te blokkeren op het gehele netwerk. Het is daarmee dus vergelijkbaar met Pi-hole. AdGuard Home werkt op een machine met Windows, macOS, Linux of FreeBSD, is ook in staat om tegen phishing te beschermen en heeft parental control. Op ons eigen forum kan over het programma worden gediscussieerd. De changelog voor deze uitgave kan hieronder worden gevonden:

Security

• As an additional CSRF protection measure, AdGuard Home now ensures that requests that change its state but have no body (such as POST /control/stats_reset requests) do not have a Content-Type header set on them (#4970).

Experimental HTTP/3 Support

See #3955 and the related issues for more details. These features are still experimental and may break or change in the future.

• DNS-over-HTTP/3 DNS and web UI client request support. This feature must be explicitly enabled by setting the new property dns.serve_http3 in the configuration file to true.
• DNS-over-HTTP upstreams can now upgrade to HTTP/3 if the new configuration file property use_http3_upstreams is set to true.
• Upstreams with forced DNS-over-HTTP/3 and no fallback to prior HTTP versions using the b:// scheme.

Fixed

• User-specific blocked services not applying correctly (#4945, #4982, #4983).
• only application/json is allowed errors in various APIs (#4970).

Versienummer	0.107.15
Releasestatus	Final
Besturingssystemen	Windows 7, Linux, BSD, macOS, Windows 8, Windows 10, Windows 11
Website	AdGuard Team
Download	https://github.com/AdguardTeam/AdGuardHome/releases/tag/v0.107.15
Licentietype	GPL

Reacties (28)

[doodleman]

De keuze is reuze..

Heb zelf pi-hole op een raspberrypi2. Is Adguard dan een vooruitgang? Of “even-goed”?

[lenwar]

Vooraf:
Beiden doen wat ze moeten doen. Namelijk spelen als DNS sinkhole en dat doen ze beiden technisch gezien gewoon goed.

Even los van de technische verschillen van de software zelf (pi-hole is een op maat gepatchte dnsmasq (pi-hole FTLDNS) met een lighttpd webserver (pihole Web) met een complete PHP-installatie er omheen en een hele boel briljante scripting er omheen (pihole Core) om de boel draaiende te houden, waar AGH een vanaf de grond opgebouwde tool is die uit één binary bestaat en één configuratiebestand), heeft AGH een paar functionele voordelen ten opzichte van pi-hole:

AGH ondersteund zonder nog meer derdepartijsoftware DoH, DoT, DoQ, enz zowel intern als extern. Je kan dus in je eigen lan versleutelde DNS-verzoeken doen, maar ook versleutelde verbindingen naar upstream-DNS servers gebruiken. (alles is tegenwoordig versleuteld, behalve de basis in de vorm van DNS, wat ik altijd raar heb gevonden)
AGH ondersteund de efficientere ABP-formaten. (die zijn ongeveer een factor 3 kleiner dan de platte hosts lists die pi-hole moet gebruiken (omdat het dus een dnsmasq-server is, die er niet op ontworpen is, om als DNS-sinkhole te fungeren)
AGH ondersteund TLS-certificaten die je rechtstreeks in de GUI kan configureren (geen geprut in configuratiebestandjes van een webserver)
AGH kan (onder Linux) zonder root-rechten draaien. Op BSD-platformen zou ik dat eigenlijk niet weten of dat ook ondersteund wordt. N.B. Dit vereist wel eenmalig iets doen op de commandline als root, maar daarna is het klaar.

Bovenstaande zijn wat mij betreft de primaire zaken die AGH een beter product maken dan pi-hole.

Verder nog wat niche dingen:
AGH heeft ook wat standaard schakelaartjes om in één keer heel Facebook (of Netflix of TikTok of weet ik veel wat allemaal) te blokkeren.
AGH draait op alles wat Linux-achtig/BSD-achtig of Windows-achtig is. Het heeft geen derdepartijafhankelijkheden. Je kan het dus op vrijwel iedere knappere router neerzetten en opstarten.(mits de CPU-architectuur wordt ondersteund). Pi-hole kan dit dus alleen als het betreffende OS o.a. een PHP-installatie ter beschikking heeft en alle benodigde libraries voor de componenten (dnsmasq/lighttpd/PHP).

Maar:
Wat ik pi-hole moet nageven is dat ik hun GUI mooier vindt, maar dat is puur een kwestie van smaak. pi-hole heeft ook een CLI waar je wat dingen mee kan doen (die je volgens mij ook vrijwel allemaal in de GUI kan doen, maar dat laatste weet ik niet zeker)

Onder aan de streep zijn dit natuurlijk typisch producten die wanneer het eenmaal draait dat je er dan eigenlijk niet meer echt naar omkijkt. Het is tenslotte een middel, niet een doel op zich.

[dikbek]

Een paar nadelen van AdGuard Home waar ik tegenaan liep, zijn:

Het grote voordeel van Pi-Hole t.o.v. AdGuard Home, is dat Pi-Hole een project is vanuit de open-source community, en AGH een open-source project is van het bedrijf Adguard. Nu ben ik niet helemaal op de hoogte van de werking van een GNU General Public License, maar volgens mij staat ze niets in de weg om in de toekomst te besluiten AGH naar hun eigen hand te zetten, door bijvoorbeeld telemetry toe te voegen. Waarschijnlijk komt er dan wel een alternatieve branch, maar dit is wel een factor om rekening mee te houden.

Als je AGH wil gebruiken in combinatie met unbound, is de meerwaarde van DoH, DoT of DoQ alleen te merken in je lokale netwerk, aangezien Unbound fungeert als de upstream DNS server voor AGH. Misschien handig voor grotere netwerken, maar overbodig in de meeste thuisnetwerken.

Als je gewend bent om pihole-updatelists te gebruiken naast de pi-hole installatie, is AGH toch nadelig, aangezien ik nog geen vergelijkbare tool heb kunnen vinden voor AGH.

[Reactie gewijzigd door dikbek op 22 juli 2024 22:49]

[lenwar]

De GPL-licentie verplicht je de componenten van het project dat je maakt ook weer in GPL onder te brengen.
Ofwel als ze hele nieuwe componenten uitbrengen, kunnen ze die onder een andere licentie uitbrengen, maar aanpassingen op bestaande componenten moeten weer in GPL.

Het zou inderdaad kunnen dat het bedrijf mettertijd iets dergelijks gaat doen. Daar loop ik nu echter nog niet tegen aan.

Ik zie voor mijn gebruik op dit moment ook geen meerwaarde om de root DNS servers extra te belasten voor mijn privé netwerkje (als teveel mensen dat gaan doen gaat dat echt impact hebben op het internet natuurlijk)
Ja tools als unbound cachen, maar dat doen pihole en agh ook.

Ik snap uiteraard het idee dat je je dns-verzoeken niet bij één toko wil onderbrengen ivm privacy en dan maar hopen dat je geen malware ergens in je netwerk hebt zitten die je dns-verzoeken onderscheppen of erger omleiden zonder dat je dat merkt, maar ik blijf echt stellig van mening dat alle telecommunicatie versleuteld moet zijn.

AGH ondersteund op dit moment het ODoH protocol nog niet, maar zodra dat er is, is ook het privacy-stuk van alles naar een één provider sturen afgedicht. Maar goed. Daar heb je nu niks aan.

Ik snap overigens niet zo goed wat dat scriptje doet? Pihole update toch net zoals AGH periodiek z’n blocklists?

[dikbek]

Ik weet dat het bedrijf het op dit moment niet doet, maar ik gebruik Pi-Hole uit principe, want stel een grote groep gebruikers zou overstappen van pi-hole naar AGH, dan zou de motivatie van de Pi-Hole developers om het project verder te ontwikkelen naar verloop van tijd zakken. En dit versterkt de positie van AGH, en zodra de monopolie van AGH groter zou worden, zal het bedrijf waarschijnlijk toch proberen dingen voor eigenbelang aan AGH toe te voegen. Misschien ook niet, maar bedrijven zijn natuurlijk gemotiveerd door geld. Dus vandaar.

Het enige grote voordeel wat ik zie t.o.v. Pi-Hole is het gebruik van APB formaten, en het feit dat het een enkele binary is met 1 config bestandje.

Ik voorzie geen gigantische gebruikstoename van Unbound en verkeer naar de root DNS servers, behalve dan door een klein technisch ingesteld groepje. En zoals je al zei, Unbound cachet ook, en vaak werkt het ook voor meerdere apparaten binnen een netwerk. Wellicht onderschat ik de problematiek, maar ik denk dat op de korte termijn dit niet zo'n groot probleem zal zijn.

ODoH heb ik nog niet van gehoord, en ook ik ben van mening dat het verkeer encrypted zou moeten zijn. Helaas ondersteunen de root domain servers geen encryptie, anders had ik dit natuurlijk al aangezet. Ik weet voor de rest nog niets over ODoH, maar zoals je zegt zal dit misschien wel de oplossing zijn voor de toekomst.

Het scriptje zorgt ervoor dat er automatisch nieuwe adlists worden toevoegd aan de pi-hole. Eigenlijk is het een tool die een adlist voor adlists kan updaten in de gravity database (i.p.v. de adlists zelf, zoals updateGravity dat al doet).

Neem het voorbeeld aan deze lijst (waarvoor het scriptje origineel bedoeld is). Natuurlijk is het een vertrouwenskwestie als je deze bron gebruikt voor je adlists.

Maar ik gebruik het scriptje zelf ook om mijn custom offline adlists automatisch te updaten. Zo heb ik een symlinkje naar een paar offline adlists in mijn '/var/www/html' staan, die ik vervolgens weer in een config bestandje van pihole-updatelists plaats (bijvoorbeeld http://127.0.0.1/adlists/advertisements.list).

Zo kan ik entries toevoegen aan textbestandjes i.p.v. via de interface of via sqlite3.

Het voordeel hiervan is dat ik alleen een symlinkje hoef te creëeren bij een nieuwe install, en pihole-updatelists draai, en deze voegt vervolgens al mijn custom entries automatisch doe, zonder dat ik een backup hoef terug te zetten van gravity, of dat ik alle entries één voor één moet toevoegen.

Je kunt met de software ook comments aan de entries toevoegen, en de entries aan groepen koppelen. Het enige wat ik handmatig moet doen (maar ondertussen al met een bash script heb geconfigureerd), is de groepen zelf aanmaken, en eventueel de clients een naam geven en aan de gewenste groepen koppelen.

Het voordeel hiervan is dat ik mijn pi-hole haast volledig geautomatiseerd heb, terwijl ik dit net niet kan met AGH.

[Reactie gewijzigd door dikbek op 22 juli 2024 22:49]

[lenwar]

Wellicht onderschat ik de problematiek, maar ik denk dat op de korte termijn dit niet zo'n groot probleem zal zijn.

Zoals je al aangeeft is het natuurlijk 'een handje vol mensen' die direct met de root-servers praten en het in de praktijk wel zal loslopen. Maar het DNS-systeem is in elk geval ontworpen om met tussenpersonen te werken. Maar goed. Het is in elk geval wel dat 'als' bijvoorbeeld 0,1% van de particulieren wereldwijd dit gaat doen, dat de boel dan in elkaar zakt. (gelukkig zal dit in de praktijk nooit gebeuren)
Het is voor mij dan ook een beetje principieel om dit soort dingen niet te doen. Maar ik snap dat mensen het doen 'uit principe' of 'omdat het kan' (toch weer iets geekyer (op de positieve manier!!) )

ODoH (Oblivious DoH) heeft het principe van een privacygeoriënteerde proxyserver voor DoH.
Jij stuurt je versleutelde verzoek, versleuteld naar de ODoH server. Die stuurt het versleutelde verzoek versleuteld door naar (bijvoorbeeld) Cloudflare. Die doet z'n ding, verstuurd het versleutelde antwoord versleuteld naar de ODoH server en de ODoH server stuurt het versleutelde antwoord weer versleuteld naar jouw DNS-server.

Ofwel: De ODoH server weet 'wie een verzoek doet', maar niet 'welk verzoek' (vanwege de 'dubbele versleuteling' (bij gebrek aan een betere term van mijn kant)) en de DoH server weet 'welk verzoek' gedaan is maar niet 'wie het verzoek doet' (want die ziet alleen de ODoH server). Het vereist dus wel dat zowel de DNS-server zelf (AGH/PiHole/welke dan ook) als de upstream DNS-server, moet weten dat het om ODoH gaat en niet alleen DoH.

Het komt er op een neer dat ik een brief in een groene envelop en die in een blauwe envelop doe. De tussenpersoon haalt mijn blauwe envelop uit de groene envelop, doet die blauwe envelop in een paarse envelop en stuurt die naar de eindbestemming. Die opent de paarse envelop, de groene envelop en leest de brief. Vervolgens stuurt hij een brief terug in de groene envelop in de paarse envelop retour naar de tussenpersoon. Die haalt de groene envelop uit de paarse en doet hem retour in de blauwe en stuurt die terug naar mij. En ik haal de de groene envelop uit de blauwe en haal de brief uit de groene.

De eindbestemming weet alleen er een groene envelop was, maar weet niet van wie. En de tussenpersoon weet alleen dat de inhoud van de blauwe envelop van en naar de paarse envelop gaat, maar weet niet wat er in de groene envelop zit.

(nu ik dit zo lees weet ik niet welke ingewikkelder is ;-) )

Het nadeel hiervan is, is dat er een extra partij is die een verstoring kan hebben en altijd vertraagd (altijd een extra stap die niet gecached kan worden ivm versleuteling), maar je creëert wel een situatie waarin 'niemand kan zien' welk DNS-verzoek jij doet (als in, aan jouw IP-adres is gekoppeld). Persoonlijk zie ik dit als een laag overhead die de overhead waard is. (persoonlijke mening)


Dus als ik het goed begrijp, update dat scriptje de beschikbare adblock-lijsten in pi-hole. Dus niet de inhoud van de lijsten zelf (de daadwerkelijke block-entries), maar de lijsten zelf.
Dat klinkt als iets dat ik niet nodig heb. Ik heb m'n AGH geïnstalleerd staan en kijk er eigenlijk nooit naar om. Ik heb één adblocklijst (van oisd.nl) en die doet z'n ding. Ik kijk ook nooit naar de data en zo. Hooguit als er is een keer iets stuk is, dat ik dan ga kijken of ik iets moet whitelisten ofzo. Het is voor mij bijna volledig een zwarte doos.

(Her)installaties doe ik dus eigenlijk ook nooit, want 'hij doet het gewoon', maar een herinstallatie zou dus zijn dat ik de AGH-binary download, het configuratiebestand (die ik heb op een backup heb staan) ernaast zou zetten en klaar. (of stel dat ik m'n Pi zou moeten herinstalleren om welke reden dan ook, dan is dat een minimale (her)installatie van het OS, en dan trap ik het installatiescriptje af via die URL (die Pi-hole ook heeft) en dan zet ik het configuratiebestand ernaast). Ik zou dat kunnen scripten, maar dat voegt voor mij niet zoveel toe, gezien ik eigenlijk nooit wat met de software doe.

Maar ik gebruik het scriptje zelf ook om mijn custom offline adlists automatisch te updaten........

Het klinkt alsof je je er wel helemaal bent in gegaan. Erg leuk om te lezen. Ik ben zelf jaren geleden gestopt met dat soort dingen (ik word oud ), maar ik vind het leuk om te zien dat mensen nog steeds zo enthousiast zijn met dit soort zaken! Kudo's!!

Maar inderdaad. AGH heeft geen CLI waar je echt iets mee kan. Je kan er wat basiszaken mee configureren (luisteren op specifieke IP-adressen en poorten en zo) en stoppen/starten/herstarten/enz, maar niks inhoudelijks. Ze hebben wel een REST API waar je tegen aan kan praten.
https://github.com/Adguar...dHome/tree/master/openapi
Die gebruikt de open standaard van OpenAPI en daar zou je dus tegen aan kunnen programmeren, mits je dat kan natuurlijk .
Er is ook een Python client specifiek voor AGH. Die gebruikt Home Assistant om tegen AGH aan te praten.
https://pypi.org/project/adguardhome/

De software kan het dus wel. Ik zelf niet ;-) (ik kan (goed genoeg) niet programmeren. Ik kom niet verder dan wat shell-scripting en wat kleine dingen in python)

Ofwel. Het is mogelijk zijn om geautomatiseerd adblocklijsten aan je configuratie toe te voegen als je de REST API of Python client gebruikt. Ik weet niet of er al wat hobbyisten/bedrijven zijn die hier de moeite voor hebben genomen.

[dikbek]

Nou ja, als het internet door unbound inzakt of minder goed werkt is daar natuurlijk ook iets voor te zeggen.

Dus als ik het goed begrijp, zorgt ODoH er voor dat verkeer tussen '[Thuis DNS] <--> [ODoH Proxy] <--> [Cloudflare]' niet af te luisteren valt, maar dat de ODoH server zelf nog wel kan zien dat ik een verzoek doe richting cloudflare, maar alleen niet de inhoud (zoals welke specifieke pagina) van die requests, vanwege de envelop binnenin de buitenste envelop?

En bij DoH kan een middle man ook niet meelezen, maar eindigt de encryptie bij de DNS server, en dus kan die wel zien welke pagina je bezoekt, omdat deze data niet meer encrypted is? M.a.w. De buitenste blauwe envelop mist?


En dat tooltje is inderdaad niet meer dan dat. Maar ik vind het zelf wel prettig dat er iemand is die het werk doet van adlists bundelen, zonder dat ik zelf zo nu en dan op onderzoek uit moet of de lijsten nog wel bijgehouden worden, en of er ook nieuwe lijsten zijn bijgekomen. Ik lever daar natuurlijk, zoals eerder gezegd, een stukje veiligheid voor in, aangezien er een geinjecteerde lijst tussen kan komen (of door de samenstellers of door de lijstenmaker zelf). Maar dit kan ook gebeuren als je de lijsten zelf inlaadt.

Maar zoals je zegt, gewoon de config kopieren naar een nieuw gedownloadde binary werkt inderdaad prima als dat je eisen zijn. Je zult alleen wel met de tijd handmatig lijsten moeten toevoegen en verwijderen naarmate ze verouderen. Gelukkig zijn er genoeg lijsten die al jaren bestaan, en waarschijnlijk ook gewoon bestaan blijven. Bijkomend voordeel is van AGH is de ondersteuning van het ABP blocklist formaat, aangezien dezen ook gebruikt worden door veel adblockers in browsers, en dus ook onderhouden zullen blijven worden.

Voor mij is het een beetje een uit de handen gelopen hobby projectje geworden, maar ik ben hierdoor wel bash gaan leren en bekend aan het worden met Linux. Python wil ik op zich nog wel een keer leren, maar ik krijg zo'n last van mijn lichaam door te veel bezig te zijn met de computer, dus ik moet me een beetje matigen (ook al lukt dit niet altijd, met alle gevolgen van dien ).

Dat alles gezegd hebbende, ik blijf zelf liever toch bij pi-hole vanwege de eerder genoemde redenen.
Ik wou even een contributie doen onder andere voor wanneer iemand op dit artikel & comments stuit, en er misschien ook wat aan heeft.

[Reactie gewijzigd door dikbek op 22 juli 2024 22:49]

[lenwar]

Klopt;

DoH:
AGH versleutelt data, stuurt het naar Cloudflare. Cloudflare ontsleutelt data, doet z’n ding, versleuteld data en stuurt het antwoord naar AGH.

Alleen AGH en Cloudflare weten wat ‘ik’ heb opgevraagd. (Mijn ISP en alle tussenpersonen niet)

Met ODoH:
AGH versleutelt data en versleutelt het verzoek. Die stuurt het naar de ODoH proxy. Die ontsleutelt het verzoek (niet de data), die versleutelt een nieuw verzoek naar Cloudflare. Die ontsleutelt het verzoek (van de ODoH-proxy) en de data van AGH.
Cloudflare versleuteld het antwoord en versleutelt en nieuw verzoek terug naar de ODoH-proxy. De ODoH-proxy ontsleutelt het antwoord-verzoek van Cloudflare (niet de data) en versleutelt een antwoord-verzoek terug naar AGH, die het antwoord-verzoek en de data ontsleutelt.

Met ODoH weet de ODoH proxy dat ik een verzoek doe, maar niet welk verzoek. En Cloudflare weet welk verzoek het is, maar niet van wie het afkomt (( alleen dat het via de ODoH-proxy komt ))

[MadMax12]

MIjn ervaring met beide, heb ze beide draaien, is dat het even goed is.
De UI van Adguard is "mooier" en denk voor de minder ingelezen mensen ook makkelijker.
Qua werking vind ik beide even goed.

[Sieginator]

Nadat ik m'n (True)NAS geüpdate had, kreeg ik geen leven meer in de vm waar Ubuntu op draait. In Ubuntu draaide Pi-hole. Ik heb overwogen om Adguard te installeren. De enige reden dat ik Pi-hole toch opnieuw in een vm met daarop Ubuntu server heb geïnstalleerd, is omdat ik daar bekend mee ben. Ik heb me verdiept in de voor en tegens tussen beide, maar wat ze moeten doen, doen ze beide goed.
Persoonlijke voorkeuren maakt de ene Adblokker meer geschikt dan de ander.

Er zijn op het internet veel sites te vinden waar Adguard en Pi-Hole tegen elkaar worden afgewogen.

[Reactie gewijzigd door Sieginator op 22 juli 2024 22:49]

[Polderviking]

Grote voordeel van adguard vind ik dat ze gewoon publieke servers hebben die je gewoon kan gebruiken. Dat maakt het vrij makkelijk aan te bevelen aan derden...

Ik heb heel lang een pihole gehad, en krijg dan de vraag waarom ze op "mijn wifi" geen advertenties krijgen maar dat is aan een leek toch moeilijker uit te leggen, laat staan implementeren.

Zo'n dns aanpassing in hun router loods je ze nog wel een keer doorheen.

Je mist natuurlijk alles en dan nog wat aan aanpasbaarheid, en er is het privacyvraagstuk, maar in de praktijk doen die publieke servers precies wat je wil en dat is zeker voor jantje doorsnee voldoende...
Die mensen gaan toch niet met blocklists enzo in de weer.

[Reactie gewijzigd door Polderviking op 22 juli 2024 22:49]

[SauSkopje]

Deze kan je niet auto-updaten en moet handmatig gedaan worden.

[Saeverix]

Ja dat had ik ook. Was de eerste keer dat het handmatig moest.
Even de instructies in de FAQ volgen en dan is het zo gedaan: https://github.com/Adguar...me/wiki/FAQ#manual-update

[vuilverwerking]

.

[Reactie gewijzigd door vuilverwerking op 22 juli 2024 22:49]

[slelieveld]

.

[Reactie gewijzigd door slelieveld op 22 juli 2024 22:49]

[lenwar]

Dan denk ik dat dat wat tijdelijks was. Ik heb hem zojuist geüpdatet via de gu
Toegegeven. Ik had hem vanaf 0.107.13 niet van .14, dus mogelijk dat daar een verschilletje zit.

[crypt0rr]

Werkt ondertussen weer prima!

[Mr. Freeze]

Ligt eraan waar je hem vandaan hebt en waarop je Adguard draait, hier de snapstore gebruikt en heeft automatische een update uitgevoerd.

Raspberry Pi in mijn geval; https://snapcraft.io/install/adguard-home/raspbian

[vuilverwerking]

Heeft iemand ook tips voor de volgende setup:
- 2 x Raspberry Pi 3
- AdGuard Home op beide

Hoe kan ik het beste een failover / sync tussen deze twee opzetten?
Iemand ervaring met GitHub oplossingen of iets anders?

[huntback]

is dit wat voor je?
https://github.com/bakito/adguardhome-sync

[vuilverwerking]

Deze had ik gezien.
Heb jij ervaring er mee?

[huntback]

Ik heb AGH in docker op 2 synology nassen draaien.
De sync tussen die 2 gaat met AGH-sync en draait hier prima.
Wijziging op de 1 wordt ge-synced naar de ander (dus visa versa)

[crypt0rr]

Deze tool werkt precies zoals verwacht. Synchroniseert via de API van instance A naar B of meerdere.

Draait hier met cron elk huur een sync actie, zo worden zaken van de primaire DNS naar de secundaire machine gelijk getrokken.

[lenwar]

Het ligt er een beetje aan wat je onder een failover verstaat en hoeveel controle je hebt over je netwerk.
Je zou gescript een virtueel ip-adres kunnen laten veranderen als er één uitvalt. Dat kan gedoe opleveren met ARP-caching in je netwerk. Maar je hebt dan wel een hele puike failover-techniek voor thuis

Je kan ook gewoon de ene primair en de andere secundair aanwijzen voor de ene cliënt en visa versa voor de andere door je dhcp-server. En zo dus eventueel de ‘load’ verdelen op die manier.
De meeste moderne dns-clients onthouden dat hun primaire niet-beschikbaar is, en gaan dan vanzelf een tijdje naar de secundaire.

Het sync-stukje zijn derdepartijtooltjes voor. Startpage is je vriend

Ik heb er zelf ook twee draaien, maar nooit die moeite genomen. Het draait stabiel en er veranderd vrijwel nooit wat.

Ik gebruik op m’n Apple telefoon Adguard Home Remote van een medetweaker. Dan heb je één centrale plek om beide installaties tegelijk te beheren. Is niet noodzakelijk, wel handig.

[Dushi]

Kijk ook eens naar NextDNS.io
Had vroeger pihole en Adguard home maar ben nu tevreden gebruiker van NextDNS

[Mausssie]

Ziet er op het eerste gezicht interessant uit, kende deze partij nog niet.
Weet jij het eventuele voordeel van hen ten opzichte van dns.adgueard.com?

[Dushi]

Nee, geen idee

[Blackouts]

Ik gebruik al een tijdje dns.adguard.com als prive DNS op al mijn apparaten. Werkt voor mij ook prima. Geen Rpi nodig met extra software.

[Reactie gewijzigd door Blackouts op 22 juli 2024 22:49]