DNSSEC + DNS-over-TLS s nic.cz a systemd-resolved

16.9. 02:32 | Přečteno: 1303× | poslední úprava: 16.9. 04:28

Dneska mi provider poněkud zkur*vil DNSku pod nohama, a jak se říká, nouze naučila Dalibora housti...

Po nemilém zjištění, že /etc/resolv.conf je již dnes považován za passé (toto samozřejmě neplatí pro Debian, čest jim), jsem prskaje nechutí nastudoval něco málo ze systemd-resolved a se štěstím se mi podařilo nakonfigurovat ho tak, aby používal DNS servery nic.cz a zároveň s DNSSEC a DNS-over-TLS. Nejsem si jist, jak moc je to nové nebo užitečné, ale když už jsem to zjistil, tak to dávám k dispozici.

Stačí oeditovat /etc/systemd/resolved.conf a změnit tyto čtyři řádky:

DNS=193.17.47.1#odvr.nic.cz
FallbackDNS=185.43.135.1#odvr.nic.cz
DNSSEC=yes
DNSOverTLS=yes

Po restartování systemctl restart systemd-resolved by se už měl stroj ptát na DNS dotazy NICu a jako drobný bonus bude to spojení šifrované. Není to žádná výhra samo o sobě, ale každá kapka šifrování se hodí.

EDIT: DNSOverTLS=yes může způsobit problém, pokud je potřeba občas dynamicky přidat další DNS, třeba pro VPNku - pokud to další DNSko nepodporuje TLS, nebude vůbec fungovat; v takovém případě nezbývá než nastavit DNSOverTLS=opportunistic, s tím, že TLS se použije jen tehdy, pokud to jde - samozřejmě to otvírá dveře možnosti downgrade útoku

Děkuji za pozornost.

       

Komentáře

[Jendа]

toto samozřejmě neplatí pro Debian, čest jim

A jak to teda funguje v jiných distribucích? Já myslel, že program (resp. jeho glibc) se podívá do /etc/nsswitch.conf a /etc/resolv.conf a pak se zeptá DNS serveru, který takto najde. Fungovalo to takhle dříve a co se teď změnilo?

Jediné, co je poslední dobou populární je, že si spustíš nějakou službu, která /etc/resolv.conf spravuje - to vždycky dělal DHCP klient (dává to smysl, pokud chceš používat DNS servery sítě kterou konfiguruješ přes DHCP, a jde to vypnout), pak existoval resolvconf (jehož důvod defaultní přítomnosti na různých Raspbianech jsem nepochopil) a teď se občas dělá to, že se spustí lokální DNS server a do /etc/resolv.conf se zapíše ten. To má spoustu výhod (DNSSEC, možnost použití „soukromých“ TLD a split-horizon DNS třeba ve VPN, cachování) i nevýhod (je to komplikovanější). Uživatelská aplikace ale stále používá ten původní mechanismus dotazování serveru, který si přečetla v /etc/resolv.conf.

No a Debian s tím souvisí jenom tak, že defaultně tyhle věci neinstaluje/nezapíná.

[marbu]

+1 Funguje to imho pořád stejně.

Při nasazení systemd-resolved je /etc/resolv.conf symlink na /run/systemd/resolve/stub-resolv.conf, který systemd-resolved generuje dynamicky.

[Bluebear]

Se systemd-resolved to je tak, že spouští vlastní lokální DNS server a do /etc/resolv.conf potom dá odkaz na tento (tedy skutečně jedna z možností, které jsi zmiňoval).

Manuál k systemd-resolved ovšem považuje pouhé čtení /etc/resolv.conf za legacy, protože Pravý Moderní Kód(tm) by se měl dotazovat přes lokální message bus přímo resolved. :) Aspoň tak jsem to pochopil. Ale původní metoda stále chodí (taky by asi vyprovokovali lynč, kdyby to nepodporovali).

Jedna ze skvělých věcí na debianu je, že řada těchto věcí je opt-in, jak by to mělo být; řada jiných dister je v tomto ohledu ale dosti nekompromisní.

[trekker.dk]

Jo. A pak nám klienti píšou, že máme špatně nastavené nameservery. Skutečnost: ta systemd sračka při dopředném překladu vytimeoutuje na překladu reverzu. (No dobře, přibližně, už si přesně nepamatuju, proč se tam tomu člověku ten překlad reverzu dělal, jenom že to rozhodně nebylo potřeba.)

Hm, tak jsem si to našel. Při práci s poštou (IMAP) se pixla rozhodla, že k něčemu potřebuje reverzy IMAP serveru. Proč? Těžko říct. Každopádně milej systemd rozhodl, že dvě sekundy je na odpověď od DNS serveru dost (v ideálním světě by to tak bylo, v reálném ne) a že cache pro negativní odpovědi je buržoazní přežitek. A klient (životný) nemohl pracovat s poštou, protože poštovní klient (neživotný) čekal a čekal a čekal a čekal.

[j]

To vis, to je tak, kdyz neco vymejsli neytelygentnejsi clovek na planete ... ;D

On totiz kupodivu kdyz nekdo chce lokalni dns, tak si pusti lokalni dns, ale 99% lidi(a adminu) rozhodne nechce provozovat lokalni dns na kazdym stroji, uz jen proto, ze to je dalsi bezpecnostni dira a v tomhle pripade doslova a dopismene jak doprdele.

---

Dete s tim guuglem dopice!

[MP]

Nevim do ceho kopete. 2s timeout je i default pro resolv. A jak jsem si vsiml, resolv ani zadnou cache nema.

[Max]

Cache pro negativní odpovědi považuji za nejhorší vymoženost. Je to první věc, které se zbavuji.
Zdar Max

[trekker.dk]

Když myslíte, že je lepší se na to samé ptát furt dokola, tak proti gustu...

[Max]

Přijde mi to nespolehlivé. Několikrát jsem řešil nefunkčnost některých služeb a vždy to bylo kvůli tomu, že se do negativní cache dostala nějaká doména. Jestli to způsoboval nějaký zlobící prvek, už přesně nevím.
Zdar Max

[_]

nemluv sám se sebou Jirko

[Vantomas]

Má stále DNSoverTLS tu vlastnost, že je pořád otevřený jeden šifrovaný tunel s dlouhou životností? Trpělo to potom na to, že když se resolvnulo něco co ztotožnilo uživatele, tak se k němu dají přiřadit všechny ostatní requesty ze session.