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
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?
Za Quad9 je IBM. Jak rozdíl jedné desetiny vteřiny ovlivňuje chování lidí je měřitelné – některé studie uvádí, že zrychlení načítání stránky o 0,1 sekundu znamená zlepšení konverzí až kolem 10 %. Když to bude mít jeden uživatel trvale pomalejší, vliv na konverzi bude samozřejmě menší. Ale spočítejte si, na kolik DNS odpovědí denně uživatel čeká, a tím si přenásobte ty desítky či stovky milisekund. Navíc vy porovnáváte ideální hodnoty – kterých se dosáhne právě jen tím měřením a přepínám na to, co je nejlepší.
"na kolik DNS odpovědí denně uživatel čeká"
Nevím. Určitě používá nějakou cache.
At už v zařízení nebo v lokální síti.
Takže přes ISP to budou desítky?
Pokud tedy zavrhneme DNS od ISP.
Což je tento případ.
Ano, vzal jsem ideální hodnoty.
Můžu vzít ty nejhorší.
Satelitní internet bude asi nejhorší? 60 ms
Mobilní internet na nějaké mizerné 4G síti 40 ms
VDSL někde daloko od DSLAM 30 ms
Doby kdy 100 ms bylo běžné v rámci republiky a do ameriky to byla 1 vteřina už jsou dávno pryč. A snad se nikdy nevrátí. DNS dotazy jsou konstatně velké i jejich počet se nebude moc měnit. Ale HW se zlepšuje podle Mooreho zákona.
Doslova narážíme na rychlost světla.
Nejhorší hodnota nebude 60 ms. Nejhorší hodnota bude, že se nějaký server zblázní a bude odpovídat vteřiny. Nebo si Google rozbije síť ve střední Evropě a nebude odpovídat vůbec. Nebo se ISP uklikne a začne všechny požadavky na čtyři jedničky posílat do /dev/null.
Všechny tyhle situace to řešení použité v AdGuard Home vyřeší. Žít se samozřejmě dá i bez toho. Ale implementované to tam je jednou, od té doby to může každý uživatel AdGuard Home použít. Tak proč to nepoužít?
Jak jsem psal.
Dnešní HW je mnohem rychlejší než před 40 lety.
DNS se za tu dobu zas tolik nezměnilo.
Pár DNS serverů jsem už otestoval.
Ještě se mi nestalo aby lokálnín DNS byl pomalejší než cokoliv jiného.
Potvrzuji že nízký ping a přeložení jednoho dotazu je něco jiného než když to zatížíte touto obludností:
https://www.grc.com/dns/benchmark.htm
/Z toho by jeden grcal, aku to robí prevádzku./SK OFF
(Starší verze V1 je free.)
A proto nechápu proč si BFU na stanici nastaví 8888 místo 192.168.1.1.
1) Soukromí jde do kopru protože Googlu už o něm ví úplně všechno.
2) Je to pomalejší. Ale toho si většina BFU nevšimne.
Protože diskuze o důležitosti rychlosti DNS je už 20 let mimo mísu.
8. 1. 2026, 07:51 editováno autorem komentáře
Tak já jsem se tedy s tím, že DNS u ISP (dobře, to není "lokální") byl pomalý setkal už několikrát. Spočítané to nemám, takže "mnohokrát" raději psát nebudu. Nakonec to ve většině případů dopadlo tak, že do DNS šlo 9.9.9.9 protože to sice není tak rychlé (což stejně nepotřebuju) ale ta odezva je alespoň plus mínus konstantní a není to ani pomalé.
Dva DNS servery jsou standart snad všude.
Pokud to budou dva servery téhož poskytovatele nebo dokonce skrytě dvakrát ten samý server, moc si nepomůžete.
Takže první dávám rychlí (Lokální, ISP)
Někteří ISP vám sice dají „svůj“ DNS server, ale komunikaci na něj přesměrují typicky na Google. Nebo ten svůj DNS server opravdu mají, ale ten dotazy forwardu je na Google. Takže pokud si takhle nastavíte server ISP a jako spolehlivý pak čtyři osmičky, možná ve skutečnosti pořád používáte jen jeden server.
Neodpověděl jste na otázku kolik DNS dotazů pošlete za den.
Tipoval bych to na stovky dotazů. Za jednoho člověka. Přepdokládám, že u spousty lidí to bude méně.
Nejde jen o rychlost, jde i o spolehlivost (možná dokonce víc, než o rychlost).
8. 1. 2026, 08:38 editováno autorem komentáře
Vzhledem k tomu jaké počty dotazů hlásí ostatní uživatelé mi přijde jediné správné řešení mít lokální DNS server.
Ten na stanicích nastavit jako primární.
Pro případ že by selhal potom sekundar nastavit na jakýkoliv jiný.
Na stanicích (Win, android) stejně nepůjde vymyslet nic jiného.
Leda nějakou VPNku.
Rodičovskou kontrolu nabízí 1111 i DNS4EU
Takže DNS na stanici dítěte by mohl vypadat takto:
Primar 192.168.1.1
Secundar 1.1.1.3
Satelitní internet? Starlink není svými parametry v kategorii satelitního spojení, v podstatě je srovnatelný s LTEčkem.
Inmarsat umí maximálně 14,4kbps dialup, Eutelsat umí max 50/30Mbps, ovšem s latencí 700+ms (dodávali jsme jich 20, a v ČR, která je na rozhraní dvou beamů, se nikdy nikdo ze zákošů nedostal pod 730ms.
Telefonovat skrt to technicky vzato jde, SIP se nerozpadá, ale psychicky to zvládnou tak 3 lidi z tisíce.
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/wireshark.... s omezenim na port 53.
digem/drillem/nslookupem... 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.