Názory k článku Novinky v Knot Resolveru 6.x: správce procesů a přehlednější konfigurace

Jak se v 6.x nastavuji vyjimky pro domeny, kde se DNSSEC kontrolovat nema?

Ve starem custom.conf souboru jsem mel nasledujici (kvuli nejakym problemum na Mozilla webech):

trust_anchors­.set_insecure({ 'mozilla.net', 'cloudfront.net', 'mozaws.net','ce­dexis.net' })


Zdokumentovano jsem to nasel tady: https://knot.pages.nic.cz/knot-resolver/config-lua-dnssec.html . Je to tedy tak, ze vyjimky se pres YAML zadavat nedaji?

To jste zavítal do sekce konfigurace s legacy lua konfigurací. Bohužel vyhledávání v dokumentaci není nic moc (dle mého názoru), ale struktura nalevo by měla pomoct najít co potřebujete.

Tohle konkrétně: https://knot.pages.nic.cz/knot-resolver/config-dnssec.html#cmdoption-arg-negative-trust-anchors

Diky. Ono kdyz clovek nevi, co hleda, tak se hleda blbe =)

Hmm, na jednom místě používám hack, kdy dotazy na AAAA záznamy posílám na jiný DNS server než dotazy na A záznamy. Je to kvůli nějakým problémům s kompatibilitou, nemá cenu to rozebírat. V původním LUA konfiguráku jde taková věc celkem snadno naskriptovat.

Podobné skripty tedy už možné nebudou?

Možnost skriptovat s lua nemizí. Představa je taková, že 99% budou lidi dělat v YAML. A pokud někdo potřebuje něco speciálního, může si pořád k tomu přidat trochu lua. https://knot.pages.nic.cz/knot-resolver/config-lua.html

No chtelo by to hlavne nejake funkcni prechodove mechanismy. Neni nic horsiho, nez kdyz se s upgradem baliku zmeni config-style natolik, ze daemon proste odmitne nastartovat. A treba konkurencni bind tohle umi - nastartuje, jen vam to do logu vynada, ze nejaka konfiguracni volba je deprecated...

V repozitářích spravovaných námi nebude aktualizace z 5.x na 6.x probíhat automaticky, přesně z toho důvodu. Nevidím(e) moc význam se v tomto případě pokoušet o automatickou migraci nebo něco podobného.

A 5.x bude nějakou dobu udržováno pro důležité (bezpečnostní) aktualizace, aby byl čas přejít – a třeba se i vyrovnat s nějakými nečekanými nevýhodami těch historicky největších změn. Třeba se ukáže, že nějaký use case se tím rozbil, apod.

Jenze podobnou vcelku zasadni zmenu jsme neutrpeli zdaleka poprve. Je to uz ponekud otravny. Nonic, zpetna vazba poskytnuta.

Krasny priklad toho, proc aplikaci nepouzivat ...

Predstava tvurcu o aktualizaci = uzivatel(spravce) si udela mesic casu, nastuduje, jak svoji aktualni konfiguraci prepsat ponovu, pak dalsi mesic bude travit tim, ze bude testovat, jestli se to i stejne chova, a kdyz to nasadi, tak dalsich par mesicu bude zjistovat, co vsechno se chova jinak a nevsim si toho pri testech. Jako bonus se dovi, ze to co predtim slo snadno a rychle, nove nejde bud vubec, nebo za cenu obetovani peti prstu.

vs ... a mame tu hnedle dva priklady, postfix, a trebas strogswan

postfix konfiguraci i chovani verzuje, a tudiz pokud je v konfiguraku napsano ze je to verze X, tak nejen ze tu konfiguraci stejne jako verze X zpracuje, ale stejne jako verze X se i defaultne chova.

swan ma dva naprosto diametralne syntakticky odlisne zpusoby konfigurace ... a ...voiala, funguji (roky) oba. Typicky kdyz nekdo dela novou konfiguraci, tak pouzije tu novejsi (a vyrazne neprehlednejsi) syntax, ale pokud nekde neco provozuje, tak to neresi a funguje mu to.

BTW: I iptables se daji do nft (vicemene) automaticky prekonvertovat. Dokonce i ten nefunckni ifconfig se da vlasne pouzit ze?

Takže i když mám systemd distro, tak se jako manager bude používat supervisord? Přijdu tedy o možnost hlídat jednotlivé procesy přes systemd unity? Budu si muset do monitoringu implementovat hlídání procesů přes supervisor? CPUAffinity pro jednotlivé kresd nastavím kde?

Pokud to správně počítám, tak to bude již potřetí, kdy budu opět překonfigurovávat celý cluster a pak další půlrok odchytávat nuance. Jak dlouho bude vývojáři podporován běh bez manažeru a s Lua konfigurací?

Systémy se systemd zůstávají jako primární use case. Stejně jako jiné démony teď budeme mít (v defaultu) pouze jednu systemd unitu, která bude obsahovat všechny části Knot Resolveru. Procesy uvnitř toho celku bude spravovat supervisord, úplně identicky jako na nasazeních bez systemd.

Nevím jestli u jiných démonů monitorujete jednotlivá vlákna procesů a nastavujete z vnějšku jejich afinity. Jinak ty afinity jednotlivých procesů, to by mohl být dobrý námět na doplnění konfigurace. Je to zase věc, která bude dávat smysl i bez systemd. Budeme rádi, pokud nám popíšete své představy o nastavení afinit, ideálně s vysvětlením co Vás k tomu vede, ale prosím jiným kanálem než tady, vizte https://www.knot-resolver.cz/support/free/

5.x bude dostávat minimálně důležité bezpečnostní aktualizace, minimálně celý rok 2024. Dál se uvidí dle situace, včetně zpětné vazby jako tato.

6.x s manažerem podporuje přidávání lua skriptů - a lua API zůstalo z většiny nezměněno. (Manažer generuje tohle lua z YAML.) Běh bez manažeru jako doteď bude v 6.x fungovat, ale v našich balících, dokumentaci a podpoře bude preferován manažer s YAML.

Příliš často se stávalo, že to lua lidi popletou - a sice je výsledkem zcela korektní lua program, ale nedělá to co čekají a oni netuší proč. Například neexistující identifikátor se v lua vyhodnotí jako nil, což je na mnoha místech zcela korektní hodnota...

Systémy se systemd zůstávají jako primární use case.

Z vašeho pohledu možná zůstává systemd jako primární use-case, ale vlastně ho zcela kastrujete a vracíme se někam do doby tranzice Debianu ze SysV, kde systemd volal "/etc/init.d/knot-resolver start" a o stavu, kondici a běhu samotné služby už něvěděl zhola nic.

Nevím jestli u jiných démonů monitorujete jednotlivá vlákna procesů

Ano, u služeb, které chci nastavit a pak na to "několik let nesáhnout" hlídám vše co jde, protože pak když se něco řeší, jde z těch dat zjistit i něco zpětně. U kresd mám navíc zkušenost, že to trpělo na pády nebo memory leaky a tak sledování obsazené paměti, uptime procesů, retval a důvod restartu, bylo vždy takové jedno z prvních varování, že se po update něco nepodařilo a je čas to opravit dřív, než si někdo všimne, že je to rozbitý.

Nyní se přesouváme někam k Postfixu, kde si jeho manager taky naspouští hromadu procesů, které si můžu nějak monitorovat, ale když se tam začne něco dít, musím jít kutat do spoustu různých zákoutí a co ta konkrétní věc vypsala do stderr ani nikde pořádně nezjistím, protože si někde musím povolit verbose, který zase nemůže být povolený trvale v produkci.

Jinak ty afinity jednotlivých procesů, to by mohl být dobrý námět na doplnění konfigurace.

Úplně přehnaně poslední kapky výkonu z toho neždímu, ale když se to polechtá dnstracem a chci dostat latence co nejníž to jde, tak affinita je jasná volba.

5.x bude dostávat minimálně důležité bezpečnostní aktualizace, minimálně celý rok 2024.
...

Pohnutkům proč manažer, i proč se zbavit Lua rozumím, i z toho vidím kam a proč to takhle směřujete a tak nebudu jen zbytečně brečet, že chci zpátky svůj spacebar heating, ale přesto si musím postěžovat, že v začátku to bylo postavené na nějakých vlastnostech a ideích, o které se s každým major updatem přichází.

Možná jsem to na začátku špatně pochopil a váš cíl nebyl projekt, který se bude krásně provozovat na anycast clusterech, kde to běží v nějakém časem odladěném prostředí a kde jakákoliv větší změna způsobí velkou bolest, ale uspokojit Pepíka, který si přečetl, jak je Turris super a pak sáhne tam kam nemá a nepozná rozdíl mezi kulatou a hranatou závorkou.

Sledování logů je možné úplně stejně jako dosud.

Velká nasazení jsou pro nás rozhodně velmi důležitá. Celkem dost se věnujeme výkonu. Sami anycast cluster s Knot Resolverem provozujeme už dlouhou řadu let. Na jejich konfiguraci nebylo třeba sáhnout roky, občas tak jeden řádek změny, dokud se neupgradoval hardware. Teď přichází ještě mnohem větší nasazení, DNS4EU. Také existují velcí ISP používající Knot Resolver. Zatím jste první z velkých nasazení, kdo si na tohle stěžuje.

(Na druhou stranu, naši podporu si neplatíte, takže popravdě prioritizujeme spíše přání těch co ano.)

Noooo... to ze bylo na tom odvr anycastu vzdy bezproblemove bych rozhodne netvrdil - Zdenek to tu nasledne samozrejme vysvetlil, cim to bylo... ale navenek to vzdy uplne rock-stable to nebylo. A vznikaly z toho samozrejme lidsky neprijemne situace, kdy vam pak pribuzenstvo vola, ze jim nefunguje internet - protoze kvuli chybam v DoH to neresolvovalo projistotu vubec... samozrejme ultimatnim resenim tady je multi-instance, kdy smrt jednoho rozhrani nezabije vsecko (a v 6.x to zachovane je, takze vlastne dobry).

Nyní se přesouváme někam k Postfixu, kde si jeho manager taky naspouští hromadu procesů, které si můžu nějak monitorovat, ale když se tam začne něco dít, musím jít kutat do spoustu různých zákoutí a co ta konkrétní věc vypsala do stderr ani nikde pořádně nezjistím, protože si někde musím povolit verbose, který zase nemůže být povolený trvale v produkci.
Tohle je trochu obecnější problém, že spousta služeb se skládá z více procesů (nejen Postfix, i qmail, aplikační nebo databázové servery, třeba i Apache když vytváří procesy pro obsluhu požadavku nebo pro CGI) – a vlastně každá aplikace si to pak musí řešit sama. Správnější by bylo, kdyby na tom měl nějakou podporu přímo systemd – jenže pak by zase příslušná aplikace byla závislá na systemd. Nebo by musela mít dva režimy, vlastního správce procesů nebo použít externí správce procesů jako systemd, což by samozřejmě byla zase komplikace pro vývoj.

Vzhledem k tomu, že se spousta věcí přesouvá do kontejnerů, kde je to z pohledu systemd nebo jiného správce služeb také jeden proces, který si možná spustí své další procesy, čekal bych spíš, že se půjde cestou monitoringu. Tedy že ty podřízené procesy nebudou přímo řízené systemd, ale budou moci být alespoň nějak monitorované (včetně využití paměti, pádů apod.).

to nebude dotaz o knot, ale o dns.
nechystaji se nove typy zaznamu vedle a, txt, mx, aaaa pro jine systemy?
treba letsencrypt pouziva extra txt zaznam, treba decentralizovane socialni site, bitchain systemy by mohly dns vyuzit.

Otázkou spíš je, který velký hráč něco co je dlouhá léta v RFC začne aktivně používat.
Třeba takový DNS type 65 (SVCB HTTPS), který se začal hojně vyskytovat někdy předloni, kdy ho začal používat Cloudflare a ptát se na něj Apple, některé DNS vendory docela překvapil.

Na tohle mame uz leta RFC3597. Aneb tak clovek do zonefile namisto "citelneho" CAA timto zpusobem vkladal TYPE257... a HTTPS by analogicky byl TYPE65, takto vlozite do zony vlastne cokoliv (cisla viz Vladimiruv link nize).

Tak tím překvapil nemyslím ani (ne)možnost vkládání, jako spíš třeba u nejmenovaného produktu řádově větši CPU utilizace při resolvování 65ky, kterou řeší do teď.

A je duvod produkt nejmenovat? Ja na to treba nikde nenarazil a to si s podobnymi vecmi v DNS hraju rad :-)

OK, to je mimo téma, ale ne až tak moc – a tyhle standardizační procesy sleduji.

Nové typy záznamů průběžně přibývají. V podstatě stačí si jen říct a rozumně popsat obsah a účel. Současný seznam ale moc dlouhý není: https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-4

Prostor 64K typů se tedy zdá, že je velký více než dost. Rozhodně IETF DNS komunita preferuje alokaci nových typů před hacky, jako že se strká vše do TXT záznamů.

Už dvacet let mají DNS servery povinnost plně podporovat i neznámé typy záznamů. Samozřejmě, na internetu to tak bývá, že ne úplně všichni dodržují úplně všechny části standardů...