Názory k článku CZ.NIC spustil nový veřejný DNS resolver, podporuje DNS over TLS
-
Dobrý den,
DoT není závislé na webovém prohlížeči a kromě Linuxu a Androidu verze 9 si můžete vyzkoušet na Windows také pomocí stub resolveru Stubby, viz https://dnsprivacy.org/wiki/display/DP/Windows+installer+for+Stubby
A zda-li Vám DoT funguje poznáte např. ze síťového provozu (Wireshark aj.) tak, že Vaše PC komunikuje s DNS resolverem na TCP portu 853 zabezpečeně.
-
Pro běžné smrtelníky? Stubby bych věřil, snad i na Windows (ale nemám osobní zkušenost). Android 9 má mít nativní podporu, celkem snadno nastavitelnou. Co chybí?
Pokud byste chtěl nativní podporu přímo ve Windows, tak s tím cz.nic těžko bude něco dělat ;-) (a možná by ani nebylo vhodné podporu Windows dlouze rozvíjet na root.cz)
-
Já nepíšu, že bych Stubby nevěřil. Ale nakonfiguruje si ho normální uživatel? Pochybuji. Chci pro běžné uživatele přímou podporu ve Windows, aby se o to nemuseli starat (a nepsal jsem, že je to věc nic.cz). Jinak se to nerozšíří.
Věřím a doufám, že je to jen otázka času, proto jsem zvýraznil zatím. Rozhodně mě to zajímá a zkusím si to.
PS: Podporu pro Windows na Root rozvíjet budu, protože na rozdíl od Linuxu má na desktopu většinu, ať už si myslíte cokoli. -
Lukáš TurekStříbrný podporovatel
Plánujete tam časem přidat i DNS over HTTPS, když už ho Knot Resolver také podporuje? DoH ve Firefoxu stačí jen zapnout, není potřeba nic instalovat.
-
Pár týdnů je v testování https://odvr.nic.cz/doh Zanedlouho by to mělo být i šířeji oznámeno.
-
Martin X (neregistrovaný)
Ako je to s blokovanim "zakazanych" domen (prevadzkovatelov nelegalnych stavkovych systemov) tymto resolverom ?
Su tieto domeny blokovane pre vsetkych jeho pouzivatelov nezavisle od ich geografickej lokality alebo je tam mechanizmus, ktory geograficku lokalitu berie do uvahy ?
Z pravneho hladiska by totiz tieto domeny mali byt blokovane len pre pouzivatela na uzemi CR, pre pouzivatela mimo CR by mala byt takato domena normalne resolvovana. Na druhej strane aj SR ma podobny zoznam blokovanych domen, ktory ale so zoznamom CR nie je totozny. -
Adresy z českého blacklistu
https://csnog.github.io/MFCR-blacklist/blacklist.txt
prochází.
A když do toho nebude nikdo šťourat, třeba tak poběží dál.
dig 1xbet.com
; <<>> DiG 9.11.3-1ubuntu1.7-Ubuntu <<>> 1xbet.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48522
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;1xbet.com. IN A;; ANSWER SECTION:
1xbet.com. 12 IN A 5.196.121.188
1xbet.com. 12 IN A 190.105.194.58
1xbet.com. 12 IN A 190.121.210.133;; Query time: 20 msec
;; SERVER: 193.17.47.1#53(193.17.47.1)
;; WHEN: Thu May 02 01:11:11 CEST 2019
;; MSG SIZE rcvd: 86
dig lottoevents.com
; <<>> DiG 9.11.3-1ubuntu1.7-Ubuntu <<>> lottoevents.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34956
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;lottoevents.com. IN A;; ANSWER SECTION:
lottoevents.com. 585 IN A 185.213.211.137;; Query time: 19 msec
;; SERVER: 193.17.47.1#53(193.17.47.1)
;; WHEN: Thu May 02 01:13:42 CEST 2019
;; MSG SIZE rcvd: 60 -
Dle návodu na https://www.nic.cz/odvr/, část Linux (Network Manager) se sice změní DNS servery pro dané připojení, ale jinak je vše nezabezpečené jako předtím po portu 53 (ubuntu 18.04). NetworkManager to nezařídí a systemd-resolve ukazuje DNSSEC supported: no.
Navíc mám opět dle návodu na na www.dnssec.cz klíč zelený, přitom všechny DNS query jedou bez zabezpečení a vrací se v odpovědi 'Cannot handle DNSSEC security RRs'.
Troufám si také souhlasit, že pobloudí i nelaik, případně nabyde falešného dojmu bezpečí.
Nejspíše bude nutné použít stubby, který článek zmiňuje. Tam je ale konfigurace vyžadující veřejně klíče ?
-
Momentální návody tam jsou z doby před spuštěním DNS over TLS. Jak jsme tu řešili, systémové resolvery typicky DoT (ani DoH) nepodporují, takže nastavení by nebylo tak jednoduché jako pár kliknutí v NetworkManageru. S lokálním ověřením DNSSEC je to podobné, pokud vím.
Z hlediska bezpečí je potřeba rozlišit dvě věci. Zabezpečení kanálu, třeba pomocí TLS, je jedna věc, jejímž cílem je především soukromí. Tam je taky potřeba důvěra v provozovatele (cz.nic, v tomto případě). Na druhou stranu, validace DNSSEC ověřuje, že data v DNS nebyla změněna někde po dlouhé cestě od vlastníka zóny (skrze různé servery, cache apod.)
Resolvery cz.nic validují DNSSEC, ale samozřejmě pokud se k ním připojujete nezabezpečeným kanálem a DNSSEC lokálně neověříte, někde po cestě mohl někdo data podvrhnout. Takové riziko ale nejde nijak "otestovat", pokud vím... podobná zelená světýlka se dělají jednoduše tak, že se zkusí resolving domén se záměrně rozbitým DNSSEC (různými způsoby) a ten by měl selhat. Jako základní test to stačí, ale skutečná bezpečnost není o takových světýlkách.
-
Děkuji za upřesnění, DNSSEC, ač implikuje trochu IPSEC, není DNS over TLS a řeší komunikaci mezi vlastníkem domény a registrátorem.
Ještě bych se zeptal, když CZ NIC má doménu nejvyšší úrovně, neberou ISP DNS záznamy od něj a není tak vlastně pak správný záznam i na ISP resolverech ?
Takto funguje DNS over TLS se stubby
vi /etc/stubby/stubby.yml- upstream_recursive_servers
- address_data: 193.17.47.1
tls_auth_name: "odvr.nic.cz"
- address_data: 185.43.135.1
tls_auth_name: "odvr.nic.cz"
(odtranit defaultní sinodun.com servery)
systemctl restart stubby -
Pokud máte IPv6, tak obecně doporučuji zkoušet i to. Routing mi někdy přijde záludný a relativně běžně se v4 a v6 routují zcela jinými trasami i když jsou oba konce stejné fyzické stroje. (To není nic specifického pro cz.nic.)
Jinak 10-15 ms round-trip mi přijde pořád v pohodě pro DNS resolver, pro "normální použití" (jako prohlížení webu).
-
Dobrý den,
pomalé nejsou, záleží na vašem ISP, kudy směruje provoz na naše prefixy. Dokonce to může být jinou trasou pro IPv4 a IPv6. Vyzkoušejte si prosím pomocí traceroute.
V případě předchozího tazatele byl provoz k nám směrován přes zahraniční lokality (DE, AT, SK), proto vzrostla latence v ms.
VS.
-
Používám O2.
Tracing route to odvr.nic.cz [193.17.47.1]
over a maximum of 30 hops:1 <1 ms <1 ms <1 ms 192.168.1.1
2 * * * Request timed out.
3 14 ms 15 ms 15 ms 114.197.broadband16.iol.cz [90.183.197.114]
4 19 ms 21 ms 22 ms 194.228.190.148
5 16 ms 17 ms 17 ms 194.228.190.21
6 18 ms 18 ms 18 ms 194.228.190.10
7 17 ms 16 ms 16 ms nix4-s.nic.cz [91.210.16.3]
8 18 ms 17 ms 17 ms gw-s-01-dnsgw.nic.cz [217.31.205.99]
9 16 ms 17 ms 16 ms odvr.nic.cz [193.17.47.1]Trace complete.
-
Schválně jsem to spustil i v práci, ale tam to nějak nedopadlo dobře:
traceroute to odvr.nic.cz (193.17.47.1), 30 hops max, 60 byte packets
1 (skryto) 0.420 ms 0.396 ms 0.375 ms
2 (skryto) 1.053 ms 1.257 ms 1.339 ms
3 ari-bgp1.bb.poda.cz (85.135.32.21) 6.482 ms 6.527 ms 6.501 ms
4 * * *
5 be101-d994-brq-itself.cz (212.96.178.10) 9.729 ms be400-d994-brq.itself.cz (212.96.178.8) 12.032 ms 12.033 ms
6 gw-b-01-v103.nic.cz (217.31.205.210) 13.583 ms 13.434 ms 13.442 ms
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * * -
Z UPC:
Tracing route to odvr.nic.cz [193.17.47.1] over a maximum of 30 hops: 1 1 ms <1 ms <1 ms router [192.168.1.1] 2 9 ms 8 ms 8 ms (skryto) 3 8 ms 8 ms 7 ms (skryto) 4 23 ms 25 ms 26 ms cz-ner-pop2-ra2-vla2154.net.upc.cz [84.116.221.218] 5 24 ms 26 ms 27 ms cz-prg02a-ra2-vla2151.net.upc.cz [84.116.221.205] 6 24 ms 26 ms 26 ms at-vie01b-rc1-ae27-0.aorta.net [213.46.160.173] 7 23 ms 25 ms 23 ms sk-bts04a-rd1-ae3-0.aorta.net [213.46.160.90] 8 26 ms 25 ms 29 ms sk-bts03a-ri1-ae0-0.aorta.net [84.116.135.162] 9 23 ms 23 ms 23 ms gw-b-01-v103.nic.cz [217.31.205.210] 10 26 ms 22 ms 26 ms odvr.nic.cz [193.17.47.1] Trace complete.
