Vlákno názorů k článku
Thunderbird 145 zapíná DNS over HTTPS a už není pro 32bitový Linux od Jan Hrach - Měla by si DNS řešit každá aplikace sama?...

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