Vlákno názorů k článku Evoluce DNS v Linuxu aneb od resolv.conf k systemd-resolved od Vladki - A umí to aspoň DNSsec, DoT, DoH ? Jinak...
-
VladkiStříbrný podporovatelA umí to aspoň DNSsec, DoT, DoH ?
Jinak jak to tady čtu tak je to docela chaos. Článek říká že to umí spoustu zajímavých a užitečných věcí ale nic jsem se nedozvěděl.
To už mi přijde lepší resolvconf (nevim jestli je specifický pro debian nebo ne), jakožto manager obsahu resolv.conf. Zaregistruje konfiguraci dle síťovek a podle daný priorit přepíše resolv.conf.
Nahodim VPN dá tam to co si řekne VPN. Vypnu ji, vrátí tam to co mám na eth/wifi. Zapnu lokálního binda/unbound/dnsmasq, dá mi tam localhost.
-
VladkiStříbrný podporovatel
Tak to tady ten článek nemusel vůbec být když si mam podle Vás všechno najít v manuálu.
-
DannyStříbrný podporovatelPrijit s komentarem typu "mam tu obskurdni kombinaci a chci tu po vas vymyslet reseni" take neni zcela koser ;-) Clanek se venuje beznym use-case, ktere pokryvaji vetsinu beznych situaci.
-
DNSsec i DNS-over-TLS to umí.
DoH je navíc stejně většinou pitomost. Je to vhodný maximálně v sítích které blokují či jinak zasahují do provozu na portu 53 a 853. V režimu ve kterém to používají prohlížeče kdy odesílají všechny dotazy na konkrétní "prověřenou" službu třetí strany to může být pro soukromí dokonce škodlivější než nešifrované DNS-over-UDP/TCP (port 53). Na portu 53 se totiž agreguje a jsou po cestě používané cache. Je tak těžší si spojit dotaz s osobou konkrétního člověka než u DoH kde to je možné až na úrovni konkrétní aplikace.
DNSsec v systemd-resolved používat lze a lze i vynutit. Ale pak nastává v sítích které používají jako DNS cache routery od společnosti Mikrotik. Jejich implementace DNS totiž stripuje DNSsec podpisy a to pak DNSsec klient vyhodnotí (oprávněně) jako útok. Výsledkem v takové síti nefunkční DNS. Je pak potřeba si do /etc/hosts přidat minimálně VPN koncentrátor a používat v takové síti VPN. Bohužel Mikrotik není jediný kdo takto blbě zasahuje do DNS záznamů. Windows nemají schopnost DNSsec ověřovat a tak se nepředpokládá že by to u klientů mělo vadit.
-
Vladimír ČunátStříbrný podporovatel
Co já vím, tak DNSSEC v systemd-resolved je lepší vypnout.
Oni prostě nemají čas to naimplementovat pořádně a pak to dělá víc škody než užitku. Jednak ten "allow-downgrade" mód je výborný způsob, jak vzít to špatné z obou stran (s DNSSEC a bez). Plus různé nepříjemné bugy, namátkou třeba https://github.com/systemd/systemd/issues/35126#issuecomment-2469907990
-
Zmíněný bug je vlastnost Fedory která ve výchozím stavu vypíná SHA1 a další algoritmy. Je potřeba si to přečíst celé než si na tom postavíte názor.
K tomu doporučení DNSSEC vypnout: Ano způsobuje to občas problémy u domén které mají rozbité podpisy, používají nebezpečné algoritmy podpisu a v sítích které zasahují do DNS záznamů. Každopádně reakce DNSSEC validujícího resolveru je správná - nesedí to, je to útok, zahoď odpověď.
Kde typicky nastávají problémy jsou vládní weby méně rozvinutých států, některé hotelové Wi-Fi, sítě které jsou postaveny na Mikrotiku (v roli DNS resolveru) a sítě využívající některé chybné implementace DNS64 které odebírají DNSSEC podpisy (mj. Cisco).
-
Vladimír ČunátStříbrný podporovatel
Ne. RFC definují chování pro nepodporované algoritmy. Dle issue to systemd-resolved dělá "po svém". Já jinak jsem zastáncem DNSSEC, ale podle standardů.
-
DannyStříbrný podporovatel
Ono ale ono to jednoznacne neni :-) Ono podpurny sloupecek Use for DNSSEC Validation rika, ze to je RECOMMENDED. Takze ano, jedna vec je samotna implemetnace (kde mame striktni MUST) a druha realna validace na resolveru, to proste nejde mezi sebou zamenovat. Takze pokud se ve Fedore rozhodli SHA1 hodit pres palubu, v zasade se neprohresili, ostatne mame i IETF draft, co smeruje stejnym smerem...
-
Vladimír ČunátStříbrný podporovatel
Myslel jsem tím to, že RFC definují, co má resolver dělat s nepodporovanými algoritmy. TL;DR: nedojde k validaci a data projdou bez chyby, ale nastaveno je to tak, aby útočníci nemohli dělat downgrade-attack (předstírat jiné algoritmy než doopravdy jsou použity).
Fedora/RHEL překvapila mnohé DNSSEC vendory svými policy okolo SHA-1, tak tady mám pochopení, že chvíli trvá se přizpůsobit (i když tohle zrovna dělají už roky).
-
DannyStříbrný podporovatel
No jestli spis neni problem v tom, ze DNSSEC vendori sami neprilis tlaci na formalni pohreb SHA1 :-) Aneb tohle lezi v IETF uz od leta 2022 a nejak furt tak nejak nic... ale jak slo o to se zbavit iteraci a soleni u NSEC3, tak za rok a pul bylo hotovo a RFC upecene - takze ono to jde, kdyz se chce, ale tady se holt moc nespecha. To s technikou realne nema nic spolecneho - to je uz jenom cista politika.
-
Vladimír ČunátStříbrný podporovatel
Používat SHA1 v DNSSEC je standardizováno jako NOT RECOMMENDED od 2019: https://datatracker.ietf.org/doc/rfc8624/
Nepodporovat SHA1 u resolverů/validátorů dělá více škody než užitku. Místo slušného zabezpečení přes SHA1 dostaneme zabezpečení žádné.
-
DannyStříbrný podporovatel
Ano, napul ;-) Ono "NOT RECOMMENDED" proste neni totez co "MUST NOT" a to i na strane signeru - kde se melo (a uz davno) zacit. V realu to vede k pa-stavu, kdy lidi na zmenu... proste kaslou, protoze to preci nejak funguje, tak proc to menit - dokud to pujde, tak na to proste nesahnou. Nejake "warningy" do logu nestaci, to skoro nikdo necte ;-) Nekdy je veci lepsi po vzoru Fedory/RHEL proste rozbit a tu zmenu sice nevybirave... ale proste vynutit. Politikou tady je prave takove to "jemne preslapovani", vysledkem je akorat falesny pocit bezpeci. SHA1 uz davno neni zadne "slusne zabezpeceni", stejne jako MD5 - ktera ten "MUST NOT" flag uz davno (od RFC 6725) ma.
-
Vladimír ČunátStříbrný podporovatel
Oni (Fedora) to ale nechtějí rozbít. Chtějí ty domény downgradovat na nezabezpečené - tedy neověřuje se u nich pak nic, ani slabé SHA1, ale fungují.
-
DannyStříbrný podporovatel
Vsak to je pristup, ktery je v principu v naprostem v poradku. Pokud je nejaky algoritmus jiz moralne jakoze davno fakt zastaraly, neni duvod neco takoveho prohlasovat za "bezpecne" a ten falesny pocit bezpeci naopak umele utvaret. Problemy kolem SHA1 jsou zname dvacet let, dost casu to resit a zbavit se toho. To, ze DNS normotvurci se SHA1 nedokazou mit tolik odvahy, co sveho casu meli u MD5 a propsat to konecne i do RFC relevantnich je jina pisnicka. To ale neznamena, ze dokud se tak nestane, tak nikdo nesmi konat. Maslo na hlave tady maji jini panove - a nikoliv ti z Fedory.
ČLÁNKY DO MAILU