Názory k článku Evoluce DNS v Linuxu aneb od resolv.conf k systemd-resolved
-
peci1Stříbrný podporovatelJako celkem podstatne mi prijde vedet o 4 modech resolv.conf:
Ja zasadne pouzivam mod 3 (symlink na /run/systemd/resolve/resolv.conf) a to funguje celkem rozumne. Muzu pak dokonce i rucne editovat /etc/resolv.conf, a zmena vydrzi do pristi zmeny konektivity, coz je casto neco, co chci (docasne pridat lokalni DNS server, nebo zmenit jejich poradi).
Jen mi prijde, ze nekdy neni mozne donutit NetworkManager, aby DNS servery spravne seradil. I kdyz treba v NM nastaveni je moznost DNS priority, tak podle mne vzdycky preferuje dratove pripojeni pred bezdratovym...
17. 6. 2025, 03:19 editováno autorem komentáře
-
Vladimír ČunátStříbrný podporovatelResolvování přes systemd-resolved je znatelně rychlejší? Byla by k tomu nějaká citace nebo tak?
-
DannyStříbrný podporovatelJestli ten problem vznikne lokalne ja jedne masine v ramci jeho cache a nebo na "tradicnim resolveru", ktery si zadratuju do resolv.conf je v tomhle ohledu celkem fuk :-) Zrovna co se vyse zminovaneho dnsmasq tyce - s tim uz jsem par problemu resil (stylem, ze proste neco nechtel prelozit), zatimco in-place replacement za unbound problem s prekladem vyresil...
A vetsina tech problemu s cache je spis o tom, ze spravce nejake autoritativni zony zbrkle zacne menit zaznamy a soucasne ma historicky vysoke TTL. No to je pak logicky, ze se veci rozbijou, zejo :D Ale za to cache nemuze...
-
No, lokalni cache delalo nscd. Od te doby, co je default systemd-resolved neustale resim problemy, ktere jsem drive resit nemusel, a zabere to nasobne vice casu.
Ta lokalni cache vcetne negative cache je uplne na h...o, v okamziku, kdy se dynamicky prepinaji sitova rozhranni, typicky pouzivaji ruzne VPN klienty.
Za prve, ony casto o systemd-resolved nemaj tuchy, a modifikuji resolv.conf - sice je v nem text a'la nepouzivat, ale soubor tam je, da se do nej zapsat, jenze to nevyplachne cache, nema precedens a funguje jen docasne a na nove dotazy.
Cache se mezitim naplni nesmyslnymi negative zaznamy.
Jeste hur, kdyz to afektuje (a ono afektuje) doplnovani short names (domain search), pak se z toho stava uz jen nepouzitelny paskvil.
Pritom kdo chce pouzit z dobreho duvodu cache pro zrychleni, ma kupu moznosti. unbound, pdnsd, cache (a nejen dns) v http proxy ....
Prijde mi to podobne humpolacky bez rozmyslu zbastlene, jako kdyz v avahi nejaky "sikula" zacal TLD ".local" mapovat na interni komunikaci v avahi, a kolidovalo to takto pojmenovanymi lokalnimi nazvy realne interni domeny (jako priklad se ".local" uvadel v dokumentacich snad 30 let).
Obdobna zbytecna "inovace"
-
To rfc je z roku 2013, ale ".local" se pouzival o vic nez dekadu driv, a nejen v MS produktech.
BTW MS DNS server existuje od roku 2003, od Win NT3.5
Ten samoliby fracek z Apple se proste v roce 2013 vubec nenamahal nejdriv se naucit neco o DNS a zjistit si pouzivane a zazite best practices, nez zacal spatra vymyslet standardizaci toho mDNS.
BTW, problem jsem s tim nemel a par Apple PC v domene mel, to az s prichodem Avahi mi to zacalo afektovat linux resolving.
-
otazka je, zda uz v te dobe vedeli, ze pouziji ".local", a pokud ano, nemuseli cekat a mohli ho dat do jineho rfc, konkretne 2606 z roku 1999, ale na to holt byli lini a nedusledni.
Ja se taky od svych 18-ti chystam vydat vlastni OS (jmenem NaserOS a'ka "nevykonny a neseriozni OS"), ale doted jsem si ten nazev z lenosti nijak nezarezervoval a nezaregistroval. Snad mne nikdo nepredbehne a Ne-na-se-re
-
Cca. 10 let nazpatek jsem nahledl do starsi knihy v cestine o MS AD (popravde netusim, zda to byla oficialni publikace MS), kde se v ramci prikladu instalovala "domena.local". Kdyz jsem o par let pozdeji dostal do spravy AD "domena.local", tak jsem vedel odkud vitr fouka...
Jinak myslim, ze pri trose hledani by clovek na webu stale nasel spoustu MS dokumentu, kde .local pouzivaji a to (bez ohledu na doporuceni) k napachani skody stacilo - spousta administratoru pouze mechanicky opisovala/replikovala postup MS. -
viz článek i ostatní zdroje k systemd-resolved, neřeší to potenciální problém, ale reálné problémy.
Invalidaci dns cache v systemd-resolved dělá nejeden vpn klient pro linuxu. Rozdíl jestli mít nějakou cacahe a občas jí zahodit a nemít vůbec žádnou je velký.
Je to ale na tobě, systemd-resolved je dnes výchozí, ale pořád dobrovolná část, nemusíš používat.
-
Systemd-resolvd funguje mizerne s VPN, protoze smicha originalni a VPN konfiguraci. Pokud chci vytvorit nekolik jmennych sitovych prostoru, kazdy s vlastni VPN, tak staci pred vytvorenim nakopirovat resolv.conf z initnet do /etc/netns/jmeno_prostoru/resolv.conf a kazdy jmenny prostor ziska nezavislou konfiguraci DNS. U systemd-resolvd je toto temer nemozne zaridit, protoze neni nikde popsane, co vsechno je treba duplikovat a navic ip podporuje pouze nahradu souboru v /etc, takze by to clovek musel resit vlastni konfiguraci mount jmeneho prostoru.
-
Prave naopak, systemd-resolved je jediny lokalny resolver, ktory funguje korektne s local-specific a zone-specific upstream resolvermi.
To, ze pomiesa "originalnu" a VPN "konfiguraciu" by default je v poriadku. Globalne DNS resolvery maju vracat rovnake odpovede. System sa moze spytat hociktoreho z nich a musi dostat rovnaku odpoved, takze pomiesanie nevadi. V tomto robi vacsina ludi chybu, ze si myslia, ze lokalny resolver sa bude pytat kazdeho z nich v poradi, az kym nedostane vysledok. Nebude.
Poznamka: toto je vytka k clanku. Medzi najvacsimi benefitmi systemd-resolved malo byt spomenute prave moznost link-specific a zone-specific resolverov. Linux v tom konecne dobehol... Windows. (macOS vie zone-specific, ale nie link-specific; takze kludne sa bude pytat resolvera na zonu, ku ktoremu je linka dole).
Takze ak ma VPN nejaku specificku zonu, treba ju nastavit. Napr. v NetworkManageri vlastnost "ipv4.dns-search" a zadat tam zony, ktore ma extra voci globalnemu resolveru.
`resolvectl query` zase zobrazi pre kazdy link a) "Current DNS Server", b) "DNS Servers" a c) "DNS Domain". A c) je presne to, ze na tuto zonu sa cez tento link sa bude pytat serverov v b), pricom zacne serverom a) - toho sa bude pytat dovtedy, kym query nebude mat timeout. Potom preskoci na dalsi v poradi.
-
Zkuste si to a pak napiste, jak jste byl uspesny. Nikde totiz neni popsano jak provozovat nekolik instanci najednou a podle me to ani nejde. Musel by se spustit plnohodnotny kontejner i se systemd, dbusem a tak. Pritom z normalnim resolverem je tento scenar trivialni, jak pisu ve svem prvnim prispevku na toto tema.
-
systemd-resolved umožňuje nadefinovat search domain a routy. Pokud je netns dostupný z systemd-resolved služby (což předpokládám), nic tomu nebrání to řídit přes routy, tak to i děláme.
Popsané to je třeba tdy https://systemd.io/RESOLVED-VPNS/
Musím říct, že naopak s systemd-resolved hromadu problémů ubylo, zejména na stanicích, kde uživatelé přeskakují mezi více sítěmi a chodí všude možně. Na serverech nám to je jedno, tam je konfigurace sejně řízená a spíše statická, dotazy jsou cachované v infra tak nebo tak
-
Nepopisoval jsem problem s preskakovanim mezi VPN, ale s provozem nekolika VPN najednou. Momentalne mam pro kazdou VPN vlastni jmenny prostor a pres /etc/netns/ ma kazda VPN "svuj" resolv conf. Kdyz chci pote prohlizet stranky pres VPN1, udelam ip netns exec VPN1 firefox. Firefox pote prohlizi stranky a pouziva DNS, ktere nastavilo DHCP z VPN1 (takze mi funguje intranet). Ve stejnou chvili chci udelat ssh na stroj ve VPN2, tak udelam ip netns exec VPN2 bash a v nem pak treba ssh interni_jmeno a interni_jmeno se mi prelozi na DNS, ktere nakonfigurovale dhcp na VPN2. Delat to stejne se systemd-resolved, je asi tak pohodlne, jako drbat se za uchem skrz zadek.
-
Takže máš postavené něco vlastního?
Pokud ti nevadí, že o všech překladech bude vědět systémový systemd-resolved, tak přes domain search a routy můžeš nasměrovat překlady z VPN1 do nameserverů v netns pro VPN1 (samozřejmě si musíš buď přidat routování nebo překlad do netns). Firefox si pak adresy přeloží a jen on bude v síti, kde budou dané IP adresy.
Pokud to chceš úplně odstínit nebo je tam takový chaos v doménách, že domain search nelze aplikovat, tak pro tebe systemd-resolved není a prostě si v udržuj upravený resolv.conf uvnitř netns a nic se ti nemění nebo si můžeš provozovat jinou službu v netns, která ti ten překlad zajistí. Tak to dělám na svém počítači pro více VPN já, každá má svůj snadbox a nechci to míchat.
-
Mne na obycejnem /etc/resolv.conf vyhovuje to, ze to neni zadna sluzba. Tedy to nemuze "spadnout". Jinak moc dalsich vyhod nema, zejmena proto, ze ma natvrdo limit 3 nameserveru, coz je v dnesni dobe dost malo - obycejny dualstack s dvema rekuzrory = 4 IP ...
Ta cache u toho systemd-resolved (a podobne dnsmasq etc) je sice fajn, ale zase je to otrava, kdyz clovek z centralnich rekurzoru vymaze nejakou fqdn, aby doslo k zmene ip vzhldem k ttl a ted by to mel mazat jeste na cele farme serveru...
-
Stub resolver v glibc funguje tak, ze sa spyta prveho resolvera v /etc/resolv.conf, a ked dostane timeout, preskoci na druhy, ak aj ten je dole, preskoci na treti a potom naspat na prvy. Je pritom uplne fuk, ci su ipv4 alebo 6.
Aka je sanca, ze vsetky tri resolvery budu dole? Cim by to zachranil stvrty?
-
Spatne pochopeno. Meli jsme tu treba takovou situaci...
Jsou 4 resolvery, kazdy ma ipv4/ipv6, celkem tedy 8. V /etc/resolv.conf s omezenim na 3 adresy je teda napr.:
ipv6 resolver1
ipv6 resolver2
ipv4 resolver3No a sikovny docker nemel nahozenou ipv6 sit, takze fungoval jen proti ipv4 resolver3. Redundance byla najednou fuc. A protoze resolver3 byl za firewalem, ktery zahazoval nahodne pakety, zlobilo to...
Nebo si ted vezmu nove fortigate. Je mozne uvest 2x ipv4 a 2x ipv6 do globalniho dns. Ja bych ale chtel treba 4x ipv6 ...
17. 6. 2025, 13:01 editováno autorem komentáře
-
VladkiStříbrný podporovatel
A 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ý podporovatel
Prijit 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.
-
Ondřej CaletkaZlatý podporovatel> Až příště zavoláte gethostbyname…
Prosím, už ne. Je rok 2025, už celkem dlouho je v manuálové stránce
gethostbyname(3)hned na začátku napsáno:> The getaddrinfo(3) and getnameinfo(3) functions are preferred over the gethostbyname(), gethostbyname2(), and gethostbyaddr() functions.
gethostbyname(3)je IPv4-only funkce a existuje jen kvůli kompatibilitě velmi starých aplikací. Psát použití této funkce jako příklad v článku v roce 2025 je vyloženě škodlivé. Ostatně i funkcegetaddrinfo(3)je zastaralá v tom smyslu že používá synchronní API, ale aspoň podporuje jak IPv4 tak i IPv6 a seřadí odpovědi podle preferencí nastavených v/etc/gai.conf.Lepší příklad (v Pythonu, verze v C je v manuálové stránce
getaddrinfo(3)):>>> import socket >>> socket.getaddrinfo("www.seznam.cz", "https", type=socket.SOCK_STREAM) [(<AddressFamily.AF_INET6: 30>, <SocketKind.SOCK_STREAM: 1>, 6, '', ('2a02:598:2::1222', 443, 0, 0)), (<AddressFamily.AF_INET6: 30>, <SocketKind.SOCK_STREAM: 1>, 6, '', ('2a02:598:a::79:222', 443, 0, 0)), (<AddressFamily.AF_INET: 2>, <SocketKind.SOCK_STREAM: 1>, 6, '', ('77.75.79.222', 443)), (<AddressFamily.AF_INET: 2>, <SocketKind.SOCK_STREAM: 1>, 6, '', ('77.75.77.222', 443))]
ČLÁNKY DO MAILU