Názory k článku
Thunderbird 145 zapíná DNS over HTTPS a už není pro 32bitový Linux

Zrovna u e-mailů to není tak kritické, ale nechá se to DoH zase vypnout?
Používám DNS na lokální síti, a ty adresy zvenku prostě neexistují. (U pošty to asi nevadí, ale uvnitř zpráv by se asi něco našlo...)

Vypnout to jde jako cokoliv jineho. Nehlede na to, ze Thunderbird neni jen posta... a i co se emailu tyce, ten obsah davno neni jen prosty text, zeano :)

V pripade netextoveho obsahu emailu nemoznost resolvovat rozlicne trackovacie pixely by mohli mnohi vnimat ako ziadanu feature, ze ano.

Prostý text to sice není... - ale já stejně blokuji všechny pokusy tahat do zpráv obsah z dálky, takže co není přímo v tom e-mailu, jako by nebylo.

Default vypadá na pohled stejně jako u Firefoxu. Tedy v našem regionu zcela bez DoH.

Měla by si DNS řešit každá aplikace sama? Proč na to není systémová služba a standard? (kromě možnosti vlastního nameserveru a v /etc/resolv.conf napsáno 127.0.0.53 který to celé dělá - a mj. tohle API neumí signalizovat podrobnější chyby a parametry) Nebo jaké jsou výhody, že se to řeší v aplikaci?

Mě teda pěkně serou, že tohle cpou do aplikací. A zapínají ve výchozí konfiguraci. Umíte najít někdo detaily, jak to DNS over HTTPS má přesně fungovat v Thunderbirdu? Mě se to zatím z mobilu nepovedlo.

Za mě to má poskytovat systém. Aplikace od něj má dostat jenom parametry, jakými je připojený.

První problém je, že Linuxový systém nemá žádné rozumné API ke zjištění, že nastavené DNS už šifrované je. Druhá věc je, že systemd-resolved s NetworkManagerem běžně leakuje query, když si to nastavíte podle návodu.

15. 11. 2025, 10:20 editováno autorem komentáře

Není náhodou mobilní Thunderbird přebrandovaný K9 mail?
V desktopovém TB jsou celkem příčetné asi 4 možnosti, stačí kliknout.
Stav v nastavení je zobrazený a výchozí stav je, že to zapne jen někde (např. ne ve firemní síti).
Pokud to chcete na systémové úrovni, můžete použít něco jako Cloudflare WARP.

V Androidu už roky není potřeba žádná aplikace.

Alespoň pokud vám je jedno, zda jde o DoT nebo DoH. Kdysi přidali jen DoT a nejsem si jistý, jak se to přesně v které verzi chová. (v mém Android 15 jde napřímo jen nastavit hostname, ale co se s ním dělá...)

15. 11. 2025, 10:48 editováno autorem komentáře

> Linuxový systém nemá žádné rozumné API ke zjištění, že nastavené DNS už šifrované je.

Pretoze to aplikaciu nema co zaujimat. Ked to bude system resolvovat postovymi holubami, tak to bude postovymi holubami a znova, aplikaciu nema zaujimat ako. Ma ju zaujimat co.

> Druhá věc je, že systemd-resolved s NetworkManagerem běžně leakuje query,

Termin "leakovat" pouzivaju ludia, ktori sice nic netusia o dns, ale o to silnejsie nazory maju o tom, ako ich use case (globalny tunel na nejaho vpn providera) ma fungovat. Ze to nie je jediny use-case akosi ignoruju. Ze napriklad ich use-case koliduje s korporatnymi vpn, kde chcem presny opak -- do vpn iba query na korporatne dns zony, vsetky ostatne mimo vpn -- ich nezaujima, tak to nazvu "leak".

systemd-resolved routuje dns query na prislusne resolvery podla nastavenych pravidiel. Je mozne nastavit aj to, co chcete, vsetko do vpn, ale to si musite pozriet, aky navod pouzivate a ci je urceny pre vas use case.

15. 11. 2025, 11:07 editováno autorem komentáře

Firefox zajímá šifrování DNS, protože tím podmiňuje použití ECH. Úplně ignoruje DNSsec. Přitom by stačilo se umět zeptat lokálního resolvers, jestli upstream šifruje.

Jsem rád, že mě znáte a umíte hodnotit moje znalosti DNS. Neříkám, že jsem v tomhle státě nejlepší. Ale troufám si tvrdit, že o tom něco málo vím.

Já vím, že systemd-resolved jde nastavit správně. Ale stejně lépe uděláte, když použijete unbound, knot-resolver, pdns-recursor nebo bind9.

Sice nemají tak snadnou konfiguraci, ale pro globální šifrované TLS vám nedovolí to zkazit.

Hlavní výhoda je, že to můžete posílat přes HTTPS. Systémové DNS cache totiž forwardovat umí typicky jenom přes DNS over TLS. To na soukromí stačí. Ale zjistit z aplikace, jak je zabezpečený další skok, to nemá žádný standard.

No na soukromí stačí.. možná se nikdo po cestě nedozví vaše DNS dotazy.
Ale ještě tu máte identifikaci serveru přes SNI, která doprovází vytvoření každého nového TLS spojení. Ano ECH to může potencionálně řešit, ale vyžaduje podporu a vypnutý fallback na starší verze TLS na každém serveru, kam se připojujete.. takže možná někdy v budoucnu a jsou tam proměnné, co neovlivníte.
Jediný praktický způsob jak skrýt svou aktivitu zůstává pořád jen VPN přes nějakého hosta, kterému věříte.

Otazkou zostava, ci chcete, aby bolo mozne uplne skryt, kam sa zariadenie pripaja a o com si cvrlika.

Pretoze prezentovany je jeden pohlad - pouzivatel, jeho pocitac a nedoveryhodna siet, cez ktoru komunikuje.

Ale co opacny scenar? Siet je doveryhodna, zariadenie nie? To je dnes uz velmi casty problem, rozlicne chromecasty, smart TV, IoT a dalsie zariadenia, ktore neumoznuju pouzivatelovi kontrolu. Naozaj chceme, aby sa pripajali kade tade? (Nepripajat tiez nemusi byt riesenie - uz dnes su TV, ktore bez pripojenia odmietnu fungovat).

Chápu, ale to bohužel platí obecně s těmi bezpečnostními mechanismy. Záleží, v jakém kontextu se použijí a úplně nejde technicky zařídit oboje - jak zabezpečení, když to používám já, tak kontrolu, pokud to používá někdo jiný.. Can't have your cake and eat it too :)

S tím, co píšete, je to složité.. takže zbývá jen segmentovat sítě s minimálním množstvím nutných prostupů. V případě, že je to kritické, tak masírovat firmy a dodavatele ohledně transparentního popisu nutných endpointů venku při použití nějakého egress filtrování, což může být prakticky nemožné nebo úplné peklo ;)
Komunikace se dá samozřejmě analyzovat i bez čitelných SNI a DNS, akorát je to komplikovanější a mnohdy o hodně hrubější. Pokud se nějakou analýzou a heuristikou povede zjistit z HTTPS spojení pravděpodobný DoH server, můžete ho zkusit cvičně bloknout a podívat se, jestli ten blackbox nebude mít nějaký fallback na DNS server přidělený v místní síti.
Nicméně uvidíme i jak se bude ECH případně prosazovat, zatím mi to přijde spíš okrajové mimo Cloudflare, ale to se může samozřejmě změnit. A vůbec nemám představu o těch velkých čínských cloudech.

A jaké DNS servery používáte, jestli se můžu zeptat? Připojení na quad cokoliv fakt nepotřebuje vidět SNI, aby bylo hned jasné, co je DNS. Ostatní běžné servery totéž. SNI DNS serveru je podle mě potřeba schovávat výjimečně.

Ano, VPN přesune tu komunikaci jinam, kde je to vidět pořád stejně. To chápu na cestách, kde si vybrat nemůžete. U domácího nebo firemního připojení mi to nedává smysl. Prostě si objednejte konektivitu od někoho, komu věříte.

Možná si úplně nerozumíme.
Řekněme, že zabezpečení DNS komunikace si vyřešíte přes DoH nebo DoT - nikdo po cestě neuvidí, co si povídáte s DNS serverem, nemůže jednoduše udělat man-in-the-middle atp.
Jediné, co zachytí, je navázání komunikace s daným DNS serverem, ale ne obsah.

Potud fajn. Ale když pak vytvoříte HTTPS/QUIC spojení na webovou službu/stránku s adresou, co jste si právě přeložil, tak se typicky také použije SNI, které bez použití ECH zahlásí hostname toho serveru.

Tzn. sice máte zabezpečenou DNS komunikaci (má to i jiné benefity než soukromí), ale samotná spojení na cílové servery se stejně velmi jednoduše identifikují.
Můžete si to jednoduše sám ozkoušet třeba ve Wiresharku, když si zachytíte chvíli provozu a pak prohlédnete s filtrem "tls.handshake­.extensions_ser­ver_name"

A ano, samozřejmě je tam ještě další možnost, pokud máte takovýhle dump celé komunikace, nebo NetFlow s metadaty o spojeních (jako většina ISP), tak můžete zkoumat a zpětně přeložit cílové adresy všech spojení resp. identifikovat ASN, zjistit komu patří atp. Ale je to složitější, zvlášť u služeb někde v cloudech a sdílených prostředích. Je tam mnohem horší odstup signál-šum, než když to zjistíte z DNS dotazů okolo nebo to ty servery přímo pošlou v SNI.

V aplikaci se to řeší proto, že na to systémová služba není. A ta na to není proto, že prohlížeče (kde se to začalo používat jako první) se vyvíjejí daleko rychleji, než systémové služby. Za mne je v pořádku, že se to nejdřív vyzkouší v některých aplikacích, a teprve pak se to bude cpát do systémových služeb. Ostatně i v těch prohlížečích je to stále někde na pomezí experimentální a běžné služby. Věřím, že za nějakou dobu se to třeba do systemd-resolved dostane.

V systemd-resolved je to uz niekolko rokov.

Opravdu? Jak se to konfiguruje? V aktuální dokumentaci o tom nic není: https://www.freedesktop.org/software/systemd/man/latest/resolved.conf.html

DoT tam je opravdu roky,
DoH ještě ne https://github.com/systemd/systemd/pull/31537

To je skvělé. :-( DoH při použití třetí strany může naopak soukromí uživatele ohrožovat. DoH resolver totiž dostává veškeré dotazy stroje (zde aplikace) a dokáže si je přímo s klientem spojit. DoH operátor sice může slibovat že klienty nesleduje, ale věřte mu ... Navíc tato třetí strana by bez použití jejího DoH resolveru k těmto dotazům vůbec neměla přístup. Kdo jim zaplatil aby mu odesílali dotazy uživatelů ve výchozím stavu?

Ano jsou situace kdy DoH dává smysl jako v případech obcházení restriktivních síťových politik na úrovni DNS a možná v totalitních režimech. Otázka však zní zda se to týká většiny uživatelů aby to muselo být zapnuté ve výchozím stavu a jestli to má dělat každá aplikace sama?

Daleko větší smysl dává použít běžný DNS server předaný sítí třeba i s DoT. "Anonimitu" těchto dotazů na internetu pak zajišťují různé cache po cestě a to že daný resolver nepoužíváte sami. Pro většinu z nás není největším nebezpečím soukromí dotazů v koncové síti, ale podvržená data v odpovědích. Tedy spíše je důležitější DNSSEC ověřování až na úrovni systemového DNS resolveru/cache.

DoH při použití třetí strany může naopak soukromí uživatele ohrožovat. DoH resolver totiž dostává veškeré dotazy stroje (zde aplikace) a dokáže si je přímo s klientem spojit.
Zatímco když se klient dotazuje DNS protokolem … je to úplně to samé.

Běžným DNS protokolem to nedokáže - tedy není to to samé. Předně se standardně neptáte třetí strany ale firemního DNS nebo DNS serveru ISP. Druhak máte v cestě nejdřív jednu cache v systému (tedy nespojíte to s konkrétní aplikací), druhou cache máte typicky na úrovni segmentu (tedy za ní už nevíte který počítač v rámci segmentu se ptal), další cache má rekurzivní resolver na hraně sítě (odtud neodlišíte zákazníka konkrétního ISP). Kdykoliv to prochází přes cache tak dotaz dál nepokračuje pokud se tam odpověď už nachází. A rekurzivní DNS dělá query minimisation, tedy každý autoritativní DNS server vidí jen tu část dotazu který odpovídá jeho úrovni a s konkrétním klientem/aplikací si to nemůže spojit - ptá se rekurzivní DNS.

Jasně, pokud jste si nastavil v systému jako DNS server třetí stranu tak jste už o anonymitu davu přišel a navíc dotazy posíláte celou cestu nešifrované. Za ztrátu "soukromí" si pak ale můžete sám. Pak už je ale docela jedno jestli si pomůžete přes DoT nebo DoH, ale DoH má oproti DoT větší overhead kvůli HTTPS, výhodou je maximálně to že se na rozdíl od DoT hůř blokuje.

Brání něco firmě nebo ISP provozovat také DoH? Na všech těch úrovních, kde předpokládáte cache?

Jinak já bych za mnohem větší ztrátu soukromí považoval to, kdyby mé DNS dotazy sledoval provozovatel místní sítě nebo ISP, který je na základě IP adresy dokáže spojit s konkrétní osobou, domácností nebo firmou. Než to, že by je sledoval nějaký velký provozovatel DNS jako DNS4EU, Cloudflare, Google apod., kteří podle IP adresy určí leda tak ISP a obec.

Firmě nic nebrání provozovat DoH, ale to ještě neznamená že je tyto aplikace s vlastním DoH klientem budou používat a nebudou místo toho posílat dotazy třetím stranám. DoT je v tom lepší jelikož systémový resolver zkusí navázat šifrované spojení s adresou kterou získal autokonfigurací.

Provozovatel místní sítě nebo ISP nepotřebuje nutně vaše DNS dotazy aby věděl kam lezete. Ten to dost dobře tuší z netflow a případně ze SNI. Třetí strana - provozovatel DoH resolveru by tyto informace bez toho aniž by ho aplikace použila vůbec neměl.

Pokud se chcete schovat před ISP tak vám nezbude nic jiného než šifrovaný tunel do nějaké sítě které věříte že vás skryje. Pokud šifrujete pouze DNS dotazy tak děláte jen poloviční práci a ve výsledku si nemusíte pomoct.

Aby jirsak zase neblabolil o vecech, o kterych nic nevi ze?

DNS dodaz bezi na dns server ktery ma uzivatel nastaven ... a neprekvapive ma kazdy uzivatel jiny, bud sveho isp, nebo nejaky ktery mu jeho isp predhodi ... nebo zcela svuj.

Navic nastaveni dns serveru ma zcela standardizovane distribucni kanaly, bud pres dhcp nebo pres rdnss.

Zatimco tohle svinstvo nastavuje dodavatel aplikace.

Navic to zcela totalne rozbiji sitovani, to bude zase place, az pocet uzivatelu klesne na tisicinu ... i kdyz nula z nuly ... Protoze neprekvapive se spousta uzivatelu pripojuje na mailservery uvnitr sve site, ktere maji privatni adresy.

Není už na čase, abyste dostal ban, když soustavně porušujete pravidla diskuse? Navíc vaše příspěvky jsou nepravdivé, takže jich žádná škoda nebude.

DoH si nastavuje uživatel v aplikaci. Ve správně nakonfigurované síti to nic nerozbíjí, protože pokud síť zasahuje do DNS provozu a je správně nakonfigurovaná, signalizuje, že se DoH nemá používat.

Já si myslím, že nejste ve při. Jen je otázka, proti jakému odposlechu se bráníte. Klasický protokol DNS je otevřený a kdokoliv může poslouchat cokoliv. Samozřejmě místní poskytovatel má všechna data v ruce. Zároveň spousta uživatelů má ručně nastavenou adresu na veřejný resolver a tam si může jeho požadavky číst kdokoliv po trase.

DoH tohle zakryje, ale posílá pak všechna data z DNS konkrétnímu cíli v internetu. Pokud máte ale stejně nastavené v DNS čtyři osmičky, pak je lepší použít proti nim DoH než otevřený DNS. Existuje dokonce standardní mechanismus DDR (RFC 9462), který dovoluje to takhle automaticky povýšit.

Pokud se vám tedy nelíbí váš místní poskytovatel (třeba někde v kavárně), tak je pro vás DoH prospěšný, protože ukryje dotazy před místní sítí.

Jestliže vám ale naopak vadí ten veřejný cíl v internetu, pak musíte přejít na místní resolver nebo si postavit vlastní DoH.