DNSSEC + DNS-over-HTTP s nic.cz a systemd-resolved (diskuse)

[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.