Názory k článku
Google přidal podporu DNS-over-TLS na své veřejné resolvery
-
Myšlenka dobrá, ale ... Google? (neregistrovaný)
Já bych myslel, že hlavním důvodem zavádění DNS-over-TLS je soukromí (bezpečnost řeší DNSSEC), aby nikdo z DNS dotazů neviděl, na které webové stránky přistupuju. No a z tohoto důvodu mi nedává vůbec smysl sice použít DNS-over-TLS, ale přitom nechat otevřenou tu největší díru do sokuromí - Google.
Nevím jestli tímhle nesměřujeme do monopolizace DNS několika málo firmami podobně, jako si několik málo firem monopolizovalo e-mail. Takže: zkoušeli jste někdo provozovat vlastní DNS-over-TLS server? Vím že třeba unbound to umí, ale nezkoumal jsem to. A v tom případě - jde pak řešit autentizaci klientů? Představoval bych si to tak, že budu mít ve své domácí síti ten DNS-over-TLS server, na mobilech a noteboocích si nastavím stub resolver tak, aby tento server používal, ale zase nechci nechávat otevřenou v podstatě proxy do DNS úplně komukoliv. Když už mám TLS, tak bych použil klientské certifikáty na ověření, kdo k tomu serveru smí přistupovat.
Máte s tím někdo nějaké zkušenosti?
-Yenya
-
Meh (neregistrovaný)
Hlavnim duvodem zavadeni DNS over TLS je, aby vlezle korporace mohly sbirat informace o uzivatelich, tj. jednak rozsirit mezi uzivatele aplikace typu browser nebo antivir, ktere maji zadratovane vlastni DNS servery, na kterych je takovy sber mozny, a dvak obejit pripadne filtrovani dotazu na cizi DNS / blokovani portu 53 v mistnich sitich. Proto se to tlaci jako vsechno ostatni zasifrovane pres 443, ne kvuli nejakemu soukromi.
-
Přezdívka: * (neregistrovaný)
Pletete si pojmy. Tady se resi DNS-over-TLS (DoT - port 853) a vy resite DNS-over-HTTPS (DoH - port 443).
https://tools.ietf.org/html/rfc7858 (DNS-over-TLS a.k.a. DoT)
https://tools.ietf.org/html/rfc8484 (DNS-over-HTTPS a.k.a. DoH) -
> Takže: zkoušeli jste někdo provozovat vlastní DNS-over-TLS server?
Vlastní provozovat lze, ale zatím není standardizován žádný "privacy protokol" směrem k autoritativním serverům. Tedy není úplně jednoduché vybrat kam tohle místo přechodu na cleartext umístit. Pokud nějakému velkému resolveru důvěřujete (z hlediska soukromí), tak to bude dobrá volba. Samozřejmě mnozí budou více věřit svému ISP.
Další potíž je že SNI v HTTPS je zatím obvykle nešifrované, takže v reálném provozu se tím zatím neskryje skoro nic (jen zpřístupní navíc další straně), ale řešení už se standardizuje tak snad brzy: https://tools.ietf.org/html/draft-ietf-tls-esni-02
-
janci (neregistrovaný)
aky je rozdiel medzi stubby a dnscrypt-porxy?
stubby resolvuje lokálne a dnscrypt-proxy iba forwarduje dotaz ďalej, kde je resolvovany.
unbound a knot-resolver resolvujú lokálne, ale ak som to dobre pochopil
- tak dotazy vedia robiť len cez port 53 (nekryptovane) ktoré smerujú na ROOT dns servery
- ak sa nastavia tak že dotazy robia overTLS na nejaké "resolvery" napr cloudfire alebo quad9 tak sa z nich stanú iba forwaderyidemi o to, že môj ISP niečo robí s DNS dotazmi, knot-resolver som nevedel rozchodiť lebo DNS odpovede ktoré došli tak ich nevedel spracovať.
takže teraz používam na routry dnsmasq ktorý použije lokalny dnscrypt-proxy ...
