Názory k článku AdGuard Home: bezpečnější procházení webu a rodičovská kontrola

Děkuji za pěkný článek.
Spoustu zajímavých informací.

Nadpis evokuje reklamu na komerční službu.
Takže jsem ho málem přeskočil.

S tou nutností použití hvězdičkového certifikátu pro DoT nesouhlasím.

Mám AdGuard Home na OpenWRT a luci-app-acme mi zajišťuje certifikát dns.example.com a DoT z Androidů normálně funguje.

A generujete si dynamicky poddomény podle identifikátorů klientů, abyste mohl na základě toho odlišit, od kterého z nich dotaz přišel? Pokud ne a pro všechny používáte napevno jednu adresu pro DoT, tak wildcard certifikát samozřejmě nepotřebujete.

Aha, v tom případě se velmi omlouvám! Já mám i vypnuté logy v celém AGH, takže mě toto využití nenapadlo. Děkuji za upřesnění.

A na jakém HW to prosím provozujete? Koukal jsme ze to chce aspon 100MB úložiště což už není na běžný router.

MiniPC s 2x LAN a CPU Ryzen 5825U. Je to takový univerzální domácí server/NAS. Běží tam Proxmox ve kterém, kromě jiného, ve VM běží OpenWRT, takže si mohu dovolit do OpenWRT doinstalovat více služeb.

Krásné řešení.
Taky jsem kdysi provozoval něco podobného.
Ale jaksi jsem ztratil důvěru ve virtuální firewall.
FW by měl být kus železa s 2 × RJ45.
Jeden WAN (plný bordelu) a druhý čistý LAN.
Když se začnete učit etický hachking, tak rychle pochopíte proč to je lepší.
Takže jsem to rozbil a mám samostatnou krabičku s firewallem .... která řeší i další věci.
Za ním je potom druhá krabička (NAS), která toho řeší polovinu.
Ve finále těžko říct jestli to je lepší.
To staré řešení fungovalo roky bez problémů.
Bezpečné to bylo v tom že to nikdo neměl.
Takže to bylo zranitelné na The Heartbleed Bug a dost možná i na Log4Shell.
Ale z venčí se k tomu nikdo nedostal. Snad. Teoretická cesta tam byla.
Chápete kam Vás směruju?

jaký je přesně ten zásadní bezpečnostně relevantní rozdíl mezi tím, když firewall běží na nějakém pofidérním železe v kdovíjak nedokumentovaně ořezaném čemsi, o čem nikdo pořádně neví jak to výrobce zprasil, vs když běží na virtualizovaném železe v dobře známém a prozkoumaném a zdokumentovaném, k danému účelu vytvořeném operačním systému?
ta uzavřená krabice bez adekvátní dokumentace zabezpečená primárně svou obskuritou že je dramaticky bezpečnější, jak z toho tvrzení plyne?
rád bych to věděl, neptám se jen pro kamaráda.

Add firewall ve virtualu.

Já v tom vidím jen dva reálné rozdíly mezi HW a virtuálním FW:

Teoreticky lze útočit na síťovou vrstvu hypervisoru (virtuální switch, L2, atd.). To se ale dá technicky eliminovat tím, že WAN rozhraní není na hostu vůbec připojeno a je předané firewallu přes PCI passthrough nebo jako celé USB/NIC zařízení.

Druhý rozdíl je, že FW VM sdílí hypervisor s ostatními stroji. Pokud by někdo kompromitoval jinou VM, mohl by se teoreticky pokusit dostat i k firewallu přes chyby v hypervisoru nebo managementu.

Jenže v okamžiku, kdy má útočník pod kontrolou nějaký stroj za firewallem na tom samém hypervisoru, mám už mnohem větší problém než to, že by mohl zkusit napadnout FW VM. To už není běžný „útok z internetu“, ale cílený průnik do vnitřní infrastruktury.

Samostatná krabička FW má výhodu v tvrdé fyzické hranici důvěry, ale u domácího nebo labového prostředí je rozdíl mezi HW a virtualizovaným FW spíš teoretický než praktický.

Ping:
1.1.1.1 6 ms
8.8.8.8 6 ms
9.9.9.9 12 ms
86.54.11.1 14 ms

EDIT:
2a13:1001::86­:54:11:1 5 ms
2a13:1001::86­:54:11:201 5 ms

7. 1. 2026, 07:52 editováno autorem komentáře

Jak jsem psal v článku, je to hodně individuální. Navíc ping nerovná se odbavený DNS dotaz. Jestli jsem z toho zkoušení rychlosti veřejných DNS resolverů něco vzal, tak to, že jeden pokus nic neznamená. Výhodou Adguard Home je, že vám ty průměrné odezvy počítá z tisíců dotazů a můžete to sledovat v čase. Zjistíte tak, že resolver, který se jevil jako rychlý, má dny, kdy je odezva přes 100 ms apod.
Jinak ještě samozřejmě dost záleží na tom, jaký protokol používáte. Já na komunikaci s upstreamovými DNS servery používám DoT, abych měl zachovanou integritu odpovědí. Jsou servery, které mají DoT prakticky stejně rychlé jako DNS po UDP, a pak jsou takové, u kterých je ta odezva u šifrovaných protokolů klidně víc než dvojnásobná.

Reagoval jsem na větu:
"Bude to ale asi hodně individuální v závislosti na geolokaci"
To platili v dobách vytáčeného interetu.
Dneska je páteřní optická sít tak hustá že geolokace nemá vliv.
V rámci EU určitě ne.
Mezi kontinty to už je poznat. 10 000km = 30ms protože rychost světla sklem je nic moc.
I ty aktivní prvky po cestě jsou mnohem rychlejší.
Starý hloupý HUB přidával 1ms. Dnešní chytrý switch je klidně 100x rychlejší a ještě u toho zvládne routovat.

Chtěl jsem se pochlubit jak mi šlape IPv6 :-)
Teoreticky by měla být rychlejší.
Prakticky rozdíl 1ms je v rámci chyby měření.

Nejsem odborník na síťový provoz, abych to byl schopný zhodnotit, ale myslím, že kdyby dnes na té geolokaci nezáleželo, tak služby, kde je potřeba co nejnižší odezva (DNS, VPN...), neudržují servery v desítkách lokalit po Evropě, aby byly co nejblíž zákazníkovi.
Pokud mi DNS4EU jakožto pro mě dlouhodobě nejrychlejší resolver vrací odpovědi po DoT za 15 ms, tak dalších 10 ms, protože to je v jiném koutě Evropy, je docela citelný rozdíl.

Myslím, že nešlo ani tak o geolokaci v rámci státu, jako spíš o geolokaci v rámci kontinentu. Protože jde o to, kde je server, kterého se dotazujete. Google má pokud vím připojení i do pražského NIXu, Cloudflare má také POP v Praze. IBM je v Praze v Peering.cz, takže pokud někdo nepeeruje tam, jeho požadavky se nejspíš budou odbavovat v Německu. Což už na latency poznáte. I u těch vámi naměřených hodnot má IBM dvojnásobnou latency oproti Googlu a Cloudflare

Ping na 1.1.1.1/8.8.8­.8/9.9.9.9 je 1-2 ms, takže NIX.
Pouze ten 86.54.11.1 je pomalejší, ten dává 9-10 ms.
Zatímco z druhého konce republiky dnes není zase až taková výjimka mít do Prahy hned +10 ms navíc.

Ano 1111 a 8888 jedou do Prahy a zpátky.
V mém případě to je 300km protože sedím 150km od NIXu v Praze.
Takže od mých hodnot je třeba odečíst:
1ms na můj FW a lokální sít.
1ms než se světlo prodere optickým vláknem.
2 ms ISP

Do Německa to bude dejme tomu 1000km takže se přičtou 3 ms
PING berlin.de 25 ms

Zkrátka se bavíme o milisekundách.
V součtu to jsou desítky ms.
Cokoliv pod 100 ms je v pohodě protože to človek nepozná.
Nebo Vy poznáte rozdíl mezi 0,1 a 0,2 vteřiny?
Dvakrát nula je stále nula.

Co sem plete IBM?

A co na to CDN resolvery? Pouzivaju tie velke DNSka GeoDNS?

Je snadne zjistit, odkud se pta recursor, to ale samozrejme nemusi znamenat, ze po ceste k nemu neni jeste nejaka cache.

Zjistite to napriklad takto:

Udelate si v nejake domene, ke ktere mate pristup delegaci pro domenu dalsiho radu.

Jako nameserver si date neco s ip adresama (inet/inet6) serveru, ktery je ve vasi moci.

Tam zakazete jekoukoli reakci na port 53.

Pustite tam tcpdump/wireshar­k.... s omezenim na port 53.

digem/drillem/ns­lookupem... se ptate ruznych serveru (1.1.1.1,8.8.8­.8....) na jedinecny zaznam z te domeny dalsiho radu, ktera smeruje na Vas server.

A vidite podle mne zajimave veci (obzvlaste ohledne vyuzivani EDNS(0)).

Nejak takto funguje napriklad https://www.dnsleaktest.com/

Nebo https://ipu.iol.cz/q bez javascriptu, ovladatelna curlem(kteremu muzete pripadne rict jake pouzit dns --dns-servers), ale primarne testujici neco trosku jineho.

Před časem jsem chtěl rozběhnout v dockeru na nasu, ale vyšlo mi, že NAS blokuje port 53 a Adguard (to samé pi-hole) ho potřebuje pro sebe a ani změna portu nepomůže. Podařilo se to někomu rozchodit bez macvlan?

Normálně to provozuji už dlouho na NAS Synology v Dockeru a jediné, co tam mám v nastavení "specifického" je to, že používám "network_mode: host".

Ještě to zkusím, dost sem se s tím natrapil tak jsem to vzdal. Ohledně network mode, co so šlo, tak jsem do host dal, portu je dost a snaz se s tím pracuje, i když chápu, že to není tak bezpečné.

Já úspěšně používám AdGuard Home + Tailscale v Dockeru na Asustor NASu. Adguard si sám nabindoval :53 nebyl a tím žádný problém. 🤔

Bezi na nom Synology DNS Server? (je to dependency pre Synology Directory Server). Ak ano, tak presne preto je to problem a preto treba macvlan / ipvlan. Alebo sa pohrat s viacerymi interfaces a presvedcit Synology DNS Server, nech sa binduje len na jeden (prva moznost je jednoduchsia, vsetky Synology aplikacie miluju bindovat sa na 0.0.0.0).

Pěkný článek právě podobou věc musím řešit :). Tohle se mě bude velmi hodit, až se budu rozhodovat co nasadit.

Měl bych poznámku k slovu "keši". Správně by to měla být "vyrovnávací paměť".

7. 1. 2026, 09:49 editováno autorem komentáře

Existuje něco na android? Myslím tím to obecné dns. Prohlížeč mám ff a doplněk to řeší uspokojive ale aplikace bych chtěl trochu vytočit :)
Sice tam mám volbu Soukromé dns ale to nefunguje, nebo to neumím nastavit.

Existuje, najdete to v mém článku, který jsem linkoval trošku níže, v tom článku to najdete pod nadpisem: Nastavení soukromého DNS AdGuardu v Androidu.

Snažím se pochopit, jak AdGuard na mobilu zastoupí celý DNS OS ale nepřišel jsem na to, Stále se chce vecpat do prohlížeče. Nevadí, jsem ztracený případ, nicméně děkuji za osvětu, že něco takového řeší i jiní lidé, to zatím stačí.

Na mobilu existuje i verze jen pro prohlížeč (zdarma) a verze která vytvoří vpn pro celý telefon (placená)

Je možné to kombinovat s VPN, která provozuje DNS s blokováním reklam: https://protonvpn.com/cs/features/adblocker (já tuto VPN používám a mohu doporučit).

jelikož apliace Adguard pro Android jako většina podobných využívá pro svoje fungování VPN slot, není možné ji požívat s klasickou VPN aplikací. Řešení je ovšem několik, pokud Vám jde o rozšířené možnosti spravování DNS dotazů. Například v PRotonVPN využit custom DNS server a přejít na NextDNS, nebo například používat aplikace RethinkDNS, která dokáže kombinovat VPN s pokročilým blokátorem (pokročilejší nastavení ovšem s tímto setupem).

Taky poskytuju VPN a DNS servery (Technitium) mám přímo ve vnitřním rozsahu VPN. Funguje to skvěle i na mobilu. DNS servery jsou jen docker kontejnery, které v mém případě jsou vystavené jen do wireguard VPN.

Na androidu používám DNS66 a odfiltruje to většinu reklamního malware i z aplikací

Adguard Home jsem nezkoušel, ale vím o něm. Ve VPN síti, kterou poskytuju i komerčně, jsem provozoval 2x Pi-Hole server.

Se změnou docker obrazů Pi-Hole jsem přešel na pokročilejší řešení ve formě Technitium. Je to taky OpenSource, a dá se skvěle používat v dockeru.

Přechod z Pi-Hole na Technitium bylo dobré rozhodnutí. Technitium narozdíl od Adguard Home, dokáže fungovat jako plnohodnotný autoritativní DNS server.

Něco jsem o tom taky napsal - zde je můj článek: https://itislove.cz/2025/08/blokovani-reklam-v-operacnich-systemech-iii/

Já jsem na Technitium taky přešel. Důvod byl prostý - pi-hole začalo delat po nějakém upgrade problémy typu timeout dotazů, výkonnostní propad a tak. Reset a konfigurace od znova nepomohly, tak byl nahrazen. Technitium je z mého pohledu krok vpřed proti pi-hole.

Vdaka za clanok.
Chcel by som sa optytat ako mate nastavenu reverznu proxy aby pocuvala na 443 jak web tak doh dotazy?

Používám Apache a nejsem si vědom toho, že bych tam měl něco spešl oproti jiným webům, které za tou proxy mám. Je to HTTPS provoz jako jakýkoliv jiný.

Myslím, že Asus routery AdGuard obsahují.

Nemáte problém s načítáním stránek (které se načtou bez použití restriktivní adblock DNS) nebo Anti-adblock zprávami na webech?

Třeba DNS4EU uvádí, že se toto může stávat:
"some websites and apps may have anti-ad detection systems in place, which could prevent the website from displaying properly or cause the app to malfunction."

Mimochodem tato DNS také shromažduje některá citlivá data:
"information collected by log files include internet protocol (IP) addresses, browser type, Internet Service Provider (ISP), date and time stamp, referring/exit pages, and possibly the number of clicks"

Mimochodem tato DNS také shromažduje některá citlivá data:
"information collected by log files include internet protocol (IP) addresses, browser type, Internet Service Provider (ISP), date and time stamp, referring/exit pages, and possibly the number of clicks"
Zapomněl jste na takový „drobný detail“, totiž že jde o informace shromažďované při návštěvě webu https://www.joindns4.eu, ne informace shromažďované v rámci poskytování služby DNS. Mnoha lidem to dojde z toho výčtu informací, ale vy jste to formuloval tak, že by si někdo mohl myslet, že se tyhle informace logují na DNS serverech DNS4EU.

Naopak DNS4EU při vyřizování DNS dotazů velmi dbá na to, aby se nelogovalo nic, co se logovat nemusí. Trochu je o tom napsáno zde: https://www.joindns4.eu/for-public, víc je v Terms of Use, které jsou bohužel aktuálně nedostupné.

Ano, máte pravdu, to jsem také zjistil. Mají tu stránku špatně napsanou, čekal bych že to DNS tam bude zmíněno, pokud by měli jinou politiku.

Na vámi odkázané podstránce je text "DNS4EU Public Resolvers Policy" kde je v tom PDF dokumentu co zaznamenávají:

o DNS query sent by the device,
o Resolver DNS response,
o DNS query type
o DNS query timestamp
o Resolver Identifier
o ASN identifier
o Threat type (in case threat is detected)
o Content type (in case content blocking is elected by User)
o Transport protocol
o Query port
o Ttl (time to live)

a uchovávání až 6 měsíců. IP je prý anonymizována ale nechápu z toho, zda oni k ní mohou získat přístup, zdá se mi, že po 24 hodin ano.

Na té webové stránce je jasně napsané, že je to politika týkající se té webové stránky. A plyne to i z těch údajů – počty prokliků z DNS fakt nezjistíte.

Mně právě odkaz na ten PDF dokument směruje na nějakou stránku se serverovou chybou.

Nesouhlasím s tímto tvrzením:
"Rozšíření v prohlížečích dnes nestačí."

Doplněk do prohlížeče dokáže odfiltrovat i to co DNS blokace z povahy fungování nedokáže udělat. Navíc to tedy mohu kombinovat s přednastaveným filtrováním i DNS.
Např. v mobilu můžu nastavit adguard DNSka pro stejné filtrování. Brave už také něco blokuje.

Z pohledu čisté blokace reklam, to je za mně zbytečné jak na PC či mobilu.

Co může být výhoda pihole/adguard jsou možné statistiky dotazů a pokud by mi povolilo definovat kategorie stránek dle témat k blokaci.
Ale čistě kvůli reklamám něco instalovat a udržovat mi přijde zbytečné, naívc méně efektivní.

Firefox + uBlock funguje skvěle na Linuxu (androidu) i Win.
Ale například na YT koukám na TV.
A tu mám LG s WebOS.
Že tam nejede FF je jasný.
Ale nejde tam ani VPN.
Tak co by jste doporučil?

Na androidu používám NewPipe = YT bez reklam.
Ale reklamy ve free aplikacích se mi zobrazí :-(

Ja bych doporucil k televizi pripojit neco jako rpi5, dal pouzivat firefox + ublock a televizi na internet vubec nepoustet.

Na LG s WebOS je YouTube bez reklamy: https://repo.webosbrew.org/apps/youtube.leanback.v4/

Trochu zvláštně se to instaluje, potřebuje povolit vývojářský mód jednou za 40 dní, ale je na to i doplněk.

Funguje mi to dlouhodobě bez problémů.

Na Androidu pak ReVanced, akorát pozor na fejky.

na androide je skor smarttube

DNS a blokací reklam právě se hodí ve všech jiných apkách než je browser..

Privoxy funguje už tri dekády.

Používal jsem, ale tak před 25 lety. Fakt to ještě existuje?

AdGuard som skúšal používať ako proxy DNS pred mojím Unboundom, ktorý zabezpečuje lokálne DNS pre služby. Technicky to fungovalo, ale pridaná latencia bola neakceptovateľná – ikony na domovskej stránke sa načítavali s citeľným oneskorením.

Navyše mi AdGuard nijako nepomohol s reklamami na YouTube, čo bol jeden z hlavných dôvodov, prečo som ho testoval.

Nakoniec som sa vrátil k uBlock Origin, ktorý rieši jednak problematické (rogue) domény, jednak reklamy priamo vo videách na YouTube. AdGuard som preto úplne odinštaloval.

Já větší latenci nepozoruji. Když se přes DoT dotážu na one.one.one.one (Cloudflare), dostanu odpověď za 20 ms, což je zhruba stejně velká odezva, jakou mám při dotazech na Adguard na mém serveru. Pokud to má člověk v domácí síti, tak to nemá vůbec konkurenci, to se odezva pohybuje v řádku jednotek ms.

Ja este jednu otazku ked je tu tak vela odbornikov a ludi co vsetko skusaju.
Preco sa trapit s nejakym DNS a portami a nastavovanim. Zakazat premavku a vsetko dat cez stare dobre proxy ktora toho dokaze ovela viac ako obycajne DNS. Je na tom nieco zle?
Rozmyslam o tom uz dlho len nemam cas sa s tym hrat.

Dneska se skoro všude používá HTTPS. Takže pokud nebudete používat TLS inspekci, proxy uvidí jen na kterou doménu směruje požadavek. Takže tím nic víc, než s DNS, nedokážete.

Bavíme sa o normálnej proxy, cez tu idete plain.

Ale iba http requesty. Pri https proxy vidi presne to, co ine zariadenie, cez ktore tecie traffic, t.j. maximalne tak SNI.

Aby videl viac, musel by robit SSL termination a to uz by si koncove zariadenie vsimlo.

To by pak HTTPS poněkud postrádalo smysl. V případě HTTPS spojení přes HTTP proxy jde nešifrovaným kanálem jenom požadavek CONNECT, za kterým následuje DNS název nebo IP adresa, kam se má proxy připojit. Tím nešifrovaná část spojení končí a proxy jen vytvoří TCP tunel, kterým si klient přímo se serverem ustaví normální HTTPS spojení. V rámci toho má ještě šanci odchytit SNI, pokud se nepoužije ECH.

Takže proxy nic víc, než hostname, odchytit nemůže (pokud se nepoužije TLS inspekce s podvrženými certifikáty). Pokud cílový server podporuje ECH a prohlížeč při ustavování spojení předá jen IP adresu a ne hostname, nedozví se proxy ani to hostname.

Adguard jsem si před několika roky zaplatil pro několik zařízení.
Bez toho nelze normálně prohlížet většinu webu. Na domácí síti jsem měl dříve pihole napojeny na kresd. Ale pihole jsem změnil za adguard. Někdy je potřeba začít zvolna s restrikcemi, často se mi totiž stalo že to negativně ovlivnilo běh některých služeb.

Něco jako staré vousaté lokální řešení Squid + Squirm (redirector) na účely blokování nežádoucího obsahu už nikdo nepoužívá?

V dobách vytáčeného spojení, kdy vše (bohužel i odesílání hesel) běželo po HTTP, to bylo ultimátní řešení, které dokázalo ušetřit stovky (tehdejších) přenesených megabajtů, a tedy ne nevýznamné množství peněz.

Blokace prostřednictvím DNS je lepší. Ty stovky megabajtů vám ušetří a ještě přidá případně centrální správu blocklistů/allow­listů. Dáte si kontejner na VPN server a pak stačí VPN používat všude. A když sáhnete po pokročilejším řešení, jako Technitium, tak si můžete i spravovat vlastní zóny.

Pokud byste tam nenasadil TLS inspekci s falešnými certifikáty, stejně by ten proxy server neviděl dovnitř HTTPS komunikace. V lepším případě by viděl akorát doménové jméno požadavku – tedy to samé, jako u DNS.

ono to bylo extrémně užitečné i na paketovém mobilním připojení (GPRS, později 3G a LTE). měl jsem to nasazené u máti, kde je dodnes jen mobilní připojení, protože starosta nějakou formalitou zablokoval dokončení a kolaudaci roztahané optiky, protože zakázku vyhrála jiná než JEHO firma, která v tom utopila spoustu peněz, a protože to nesměla zprovoznit a vydělávat na tom, na neschopnosti splácet dluh zkrachovala. on následně nebyl znovu zvolen, a nové zastupitelstvo od té doby během 8 let novou zakázku nevypsalo. takže celé městečko (nějakých 1500 adresních míst) má do baráků zavedené trubky, ale nejsou v nich vlákna, natož data, a všichni jedou akorát po LTE nebo wifině (v těch částech kde to dokázali pokrýt). a už několik let se řeší, jak to právně udělat, aby se směly využít ty trubky, které patří zaniklému subjektu, protože je obec před jeho zánikem nepřevzala, protože starosta se postaral i o to, aby nedošlo k odkupu už hotové infrastruktury.
máti sice moc provozu negeneruje, ale dokud většina provozu šla po http, tak typicky to její čtení novin ve statistice squidu vypadalo tak,že cca 90% požadavků se odbavilo z cache. a když se otvírá třeba iDnes, tak rozdíl 150kB vs 1,5MB na každou stránku je rozdíl rozpoznatelný i na mobilu.