Názory k článku
Cloudflare spustil DNS resolvery na adresách 1.1.1.1 a 1.0.0.1
-
zajímavé, o těchto DNS serverech vím tak 5 let, dříve měli info na adrese dns.cloudflare.com, teď koukám tam je už něco jiného.
Stejně tak se dříve chlubili, že nic nikam nelogují a že každý rok si nechávají dělat externí audity, že to tak opravdu je, teď tam nic takového nevidím. Něco mi na tomhle smrdí.
-
musel jsem si to s něčím splést, ani archive.org na téhle adrese neviděl dříve víc https://web.archive.org/web/20180328150501/https://dns.cloudflare.com/ Je možné, že dříve na téhle adrese byl dns pro jiné účely, je to ale pouze můj dojem.
-
DK (neregistrovaný)
Porad to tam je
"We will never log your IP address (the way other companies identify you). And we’re not just saying that. We’ve retained KPMG to audit our systems annually to ensure that we're doing what we say.
Frankly, we don’t want to know what you do on the Internet—it’s none of our business—and we’ve taken the technical steps to ensure we can’t."
-
me (neregistrovaný)
Ubuntu 18.04 bude mit v repozitari aplikaci "stubby", clienta pro secure DNS.
Podrobnosti o pouziti "DNS over TLS" jsou na https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Daemon+-+Stubby
-
me (neregistrovaný)
Zajimavy je take prispevek uzivatele jedisct1 v diskuzi
https://support.opendns.com/hc/en-us/community/posts/115019265903-DNS-over-TLS
-
me (neregistrovaný)
Nekolik zdroju odkazuje na https://1.1.1.1/, ze by tam melo byt vice informaci o Cloudflare DNS, ale me ten odkaz nefunguje...
-
me (neregistrovaný)
Toto je zrejme nejlepsi zdroj informaci o 1.1.1.1:
https://developers.cloudflare.com/1.1.1.1/ -
-
me (neregistrovaný)
Tak jsem si zmenil DNS na 1.1.1.1 a stejne mi https://1.1.1.1 nefunguje. Zkousim z browseru ale i curl ukazuje, ze tam zadny http server neni...
$ curl https://1.1.1.1 curl: (7) Failed to connect to 1.1.1.1 port 443: Connection refused $ curl http://1.1.1.1 curl: (7) Failed to connect to 1.1.1.1 port 80: Connection refused $ host -v 1.1.1.1 Trying "1.1.1.1.in-addr.arpa" ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54359 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;1.1.1.1.in-addr.arpa. IN PTR ;; ANSWER SECTION: 1.1.1.1.in-addr.arpa. 1800 IN PTR 1dot1dot1dot1.cloudflare-dns.com. Received 84 bytes from 1.1.1.1#53 in 44 ms
Zkusil jsem curl ze serveru ve Francii a tam se skutecne zobrazuje nejaka html stranka, jen na https://1.1.1.1 . Takze se pokusim, zjistit, kdo mi obsah blokuje, nebude to uplne snadne...
-
Lol Phirae (neregistrovaný)
Tak jsem si zmenil DNS na 1.1.1.1 a stejne mi https://1.1.1.1 nefunguje.
Skoč si do železářství pro bublinky do vodováhy, pak to zaručeně už bude fungovat.
-
Filip JirsákStříbrný podporovatelTipoval bych to na Cisco WiFi kontrolér, viz např. tento komentář.
-
Vladimír ČunátStříbrný podporovatel
Jak psali jiní, ideální je mít DNS resolver přímo na localhostu (ať už "stub" – tedy pouze přeposílající jinam, nebo nějaký co umí/dělá více).
Dodal bych, že zmiňovaný knot-resolver také umí TLS, na straně serveru i klienta. Druhý směr jsme tam dopsali až dost nově (2.0.0 před dvěma měsíci).
-
me (neregistrovaný)
Hraji si, porovnavam rychlost ruznych DNS serveru. Mam jednoduchy skript ktery se pta na cca 10 ruznych DNS jmen a merim dobu behu skriptu.
Lokalni DNS cache na "firewalu" je skutecne nejrychlejsi, ale jen v pripade, ze skript spustim nekolikrat po sobe (prvni dotaz je "pomaly"). Na tom Cloudflare je zajimave, jak rychle vraci vysledek. Muze to byt zajimave reseni pro lidi, kteri lokalni DNS resorver nemaji. Skutecne to prohlizeni internetu muze meritene urychlit...
Prave se mi povedlo zachytit, ze i Cloudflare se chova podobne jako muj lokalni resolver, prvni dotaz obcas trva dele. Je to ale porad vyrazne rychlejsi nez DNS od Google, ktery ma vicemene konstatni dobu odezvy...
#!/bin/sh DNSSERVER="$1" grep -v "^#" <<+++ | www.root.cz www.kernel.org www.cznic.cz www.google.com www.seznam.cz www.idnes.cz www.ihned.cz www.blesk.cz www.bbc.co.uk www.cnn.com +++ while read H X; do host "$H" $DNSSERVER done
Mereni se provadi takto:
$ time bash test-dns1.sh # default, localhost
$ time bash test-dns1.sh 1.1.1.1 # Cloudflare
$ time bash test-dns1.sh 8.8.8.8 # Google
$ time bash test-dns1.sh 208.67.222.222 # OpenDNS
$ time bash test-dns1.sh 217.31.204.130 # CZ.NICOrientacni namerene vysledky,
Google, #1: 0.652s
Google, #2: 0.581sOpenDNS, #1: 1.081s
OpenDNS, #2: 0.975sCloudflare, #1: 0.641s
Cloudflare, #2: 0.291s -
Vladimír ČunátStříbrný podporovatel
K rychlosti odpovědí považuji za nejdůležitější dvě věci:
1) "blízkost" jejich nejbližšího serveru. Vy máte evidentně ke všem ping pod 1ms, takže toto kritérium víceméně nepoznáte (pro běžný provoz). Mít alespoň desítky milisekund nepovažuji za vzácnost a pak výběr poskytovatele může dělat značný rozdíl, ale optimální volba se bude lišit pro každého uživatele.
2) obsah cache. Je velký rozdíl jestli resolver může odpovědět rovnou z cache anebo musí dělat dotazy na upstream servery. Tady už objektivní měření není tak jednoduché, protože záleží na co se ptáte a i jednotlivé běhy se ovlivňují. A ovlivňují se i po vypršení TTL, protože třeba i knot-resolver obsahuje volitelný modul který se snaží odhadnout jaké dotazy přijdou a předpřipravit čerstvá data do cache.
-
me (neregistrovaný)
Ano, vysledky zavisi na mnoha promennych.
Stejny test jsem zkusil na malem serveru umistenem v datacentru ve Francii, vysledky jsou znacne rozdilne. Jednoznacne tam vyhrava lokalni DNS server, ten vetsinou potrebuje mene nez 0.5s. Google pak cca 0.8s a Claudflare, prekvapive, cca 1s...
-
xsouku04 (neregistrovaný)
Jak ta firma Claudfare o které jsem nikdy nic neslyšel dosáhla toho, že o tom píší po celém světě?
Zřídit si DNS, nebo spíše mu jen změnit ip adresu na snadněji zapamatovatelnou, přece není něco, co by si zasloužilo takovou pozornost.
Tomu říkám úspěch PR, když přiměli i root jim zdarma zveřejnit reklamu. Nebo to snad někdo organizuje a dostal za to zaplaceno a root je jen objetí nějakých intrik hlavních zpravodajských agentur odkud tuhle zprávu přebral?Jaké jsou zdroje této zprávy?
Zaráží mne především to, že tuhle zprávu pochybné důležitosti píší i hlavní média, jako by to bylo někým organizováno.
-
Filip JirsákStříbrný podporovatel
To, že jste o té firmě nikdy neslyšel, je váš problém – zvlášť když ani neumíte zkopírovat nebo správně opsat jejich název. Je to velký poskytovatel CDN.
Oni si nezřídili DNS, nýbrž začali poskytovat veřejné DNS resolvery – podobné, jako poskytuje např. Google, IBM nebo OpenDNS.
Toho, že o tom píší po celém světě, dosáhli „snadno“ – začali zdarma poskytovat službu, která je užitečná pro celý internet, a vydali o tom tiskovou zprávu. Vybudujte důvěryhodnou firmu, nabídněte službu užitečnou pro všechny uživatele internetu, a také se o vás bude psát.
-
Snadno to lze dohledat že to dělá kdekdo, není třeba někomu dělat zdarma reklamu.
Viz např. zde.
https://www.lifewire.com/free-and-public-dns-servers-2626062 -
Filip JirsákStříbrný podporovatel
S desítkami popů (a tedy nízkou latencí) to zase úplně kde kdo nedělá. Tohle nebyla reklama, ale zprávička, jakých je tady dvanáct do tuctu.
-
Vladimír ČunátStříbrný podporovatel
O Quad9 se taky celkem dost psalo - a to byla nová "firma" jen pro účel těch veřejných DNS resolverů. CloudFlare je celkem známé a primárně díky jiným službám než DNS (okolo CDN), pokud vím.
-
Ondřej CaletkaZlatý podporovatelBude výrazně pomalejší kvůli absenci cache a také o vás vyzradí mnohem víc kvůli spoustě dotazů navíc. Ale pokud ten kešující resolver nastavíte tak, aby dotazy šifrovaně přeposílal třeba na čtyři jedničky, případně střídal čtyři jedničky, čtyři osmičky a třeba čtyři devítky, máte ideální řešení…
…tedy až na to, že pokud půjde o notebook, tak si s ním neškrtnete v téměř žádné hotelové Wi-Fi síti.
-
Ondřej CaletkaZlatý podporovatel
*absencí cache je myšleno absence horké cache, kterou jeden samotný uživatel nemá moc šanci udržovat.
-
Já (neregistrovaný)
Co o mně vyzradí navíc? Někde se přece zeptat musím. Buď se zeptám jednou nějakého cizího resolveru nebo to zjistím sám, pak se tedy musím zeptat víckrát.
On se dns server, když neví, ptá pokaždé na celé doménové jméno místo toho, aby se ptal postupně na jednotlivé části od nejvyšší domény dolů? Nezkoušel jsem to.Hotelové wifi neřeším, bez vpn se stejně nepřipojuji.
-
Vladimír ČunátStříbrný podporovatel
Pokud jde o vyzrazování a používáte VPN, tak bych se ptal skrze tu VPN. Její provozovatel stejně vidí jména kam se připojujete (i v https díky SNI) a v jeho provozu je slušná šance se schovat.
Způsob ptaní záleží na resolveru a nastavení. Existuje i RFC: https://tools.ietf.org/html/rfc7816
-
Ondřej CaletkaZlatý podporovatel
Když máte resolver, který se ptá přímo autoritativních serverů, tak se celé dotazované jméno posílá všem autoritativním serverům, tedy putuje po síti mnohonásobně a do různých směrů. Pro špehujícího ISP je to nezajímavé, protože ten vidí veškerý provoz, ale vzdálenější pozorovatel může dostat informace, které by jinak nedotal.
Teprve nedávno se objevil standard QNAME Minimization, který toto chování mění, ale v praxi naráží na spoustu rozbitých autoritativních serverů, takže se stejně v resolverech musí obcházet: https://ripe72.ripe.net/archives/video/219/
-
j (neregistrovaný)
Fakt by me zajimalo, co navic se dovim z toho, ze se klient na my siti pta postupne na .cz, root.cz, a www.root.cz vs ze posle jeden dotaz na www.root.cz. Jo, vlastne se dovim, ze tam ma rekurzivni DNS ...
A ta lokalni cache bude pro dotycneho uzivatele ve vetsine pripadu fungovat naopak velmi dobre, protoze lidi navstevujou omezeny set domen. Ne ze by to teda bylo nejak poznat, z pohledu uzivatele to bude mit vliv 00prd.
-
pokud u sebe máš dns resolver, samozřejmě se musí poslat dotaz na .cz, .root a www.root.cz pokud záznamy už nemáš v cache.
To je otázka, řada webů má ttl 60, takže to také není pohodlné. Řešením je dotazovat před vypršením ttl ty domény znovu a držet je pořád v cache, pak budou dotazy opravdu rychlé.
-
Honza (neregistrovaný)
S 1.1.1.1 může být velká potíž, protože např. Cisco WiFi kontroléry tuto IP adresu používají jako proxy (DHCP proxy, web authentication proxy). Sic je 1-ničkový rozsah už dávno delegován, ale Cisco tuto změnu vůbec nereflektovalo ve svých produktech, a stále používají 1.1.1.1 pro svoji potřebu. :-( Jde to na produktech změnit, ale to už je na svrávcích zařízení. Tedy se ani nedivím, že v některých sítích 1.1.1.1 nebude fungovat.
ČLÁNKY DO MAILU