Názory k článku Nasazujeme Knot DNS na vlastní doméně: praktický návod

Díky za užitečný článek, jenom škoda, že tam není odstavec o tom, čím se Knot vyznačuje ve srovnání s jinými autoritativními DNS jako např. bind, nsd atd...

Pokud vim, ve srovnani s bind mu chybi jenom rekurze (a s tim souvisejici veci). Jak uz je v clanku spomenuto, na to je "knot resolver", jenze ten zas neumi byti autoritativni. A soubezne na stejnem stroj bezet "nemuzou", protoze oba potrebuji port 53.

Osobne mi tohle deleni funkci spis vadi, a byl bych radsi kdyby tady byl jen jeden Knot, kterej by ale umel vsechny podstatne veci kolem dns. Vzdyt mit dn-server jako autoritativni (pro sve domeny) a zaroven rekurzivni+cache (pro vse ostatni) je pomerne bezna konfigurace, alespon v pripade "malych" uzivatelu. Knot ale spise cili na isp/backbone, a tam je oddeleni autoritativnich a rekurzivnich resolveru bezne.

Pro malého uživatele Knot evidentně určen není, tam je výborný dnsmasq, ale mít autoritativní i rekurzivní dns na jednom stroji jde alespoň v typickém případě, kdy ten autoritativní poslouchá jenom na externích adresách a ten rekurzivní zase jenom na nějaké lokální (typický např. 127.0.0.53).

On treba powerdns ma taky oddelen auth a rekurzor.

Ono stejne dneska asi vetsina firem predradi rekurzor, aby se nezatezoval auth server, a mit tak treba nasobne vic rekurzoru nez auth. Svou logiku to ma, ale taky jsem v prvni fazi z toho byl nestastny, dnes uz bych nemenil.

Míchání autoritativní a rekurzivní funkce na jednom serveru je velmi silně nedoporučováno a způsobuje to mnohé problémy. Sám už jsem tohle v praxi několikrát řešil, teď zrovna před několika málo dny.

Typický příklad: v datacentru byl server, kam si klienti dávali zóny a ten pro ně zároveň fungoval jako rekurzor. Můj klient ale změnil záznam v nadřazené zóně a začal používat jiné autoritativní servery. V tu chvíli mu přestala chodit pošta od jiných klientů ve stejném datacentru, což byl dost zásadní problém, protože zrovna mezi nimi probíhala běžně čilá komunikace (různé úřady v jednom datacentru).

Ukázalo se, že na vině byl právě místní autoritativní server, který pro vybrané domény nechodil do globálního DNS stromu, ale vyřizoval je sám jako autoritativní server. Tím pádem neměl jak zaregistrovat globální změnu delegace zóny a tvrdošíjně odpovídal vlastními autoritativními záznamy z disku.

To je jen jeden příklad, ale demonstruje ten hlavní problém, kvůli kterému já nikdy nemíchám tyhle dvě funkce. Používám mnoho různých DNS serverů (Knot, NSD, BIND, Unbound…) a jedině BIND umí takhle smíchat funkce dvou různých DNS prvků. Nikdy to nepoužívám, protože je to nebezpečné.

Jistě mohou běžet na stejném stroji, například každý na jiné IP adrese.

Svůj lokální DNS resolver nedoporučuji vystavovat do internetu ("open resolver"), nabízí se tedy použít něco z privátních IPv4 rozsahů. Naopak autoritativní DNS musí být přístupné odevšad a tedy mít veřejnou adresu... se stejnou IP-port kombinací by to i na firewallu nebylo jednoduché odlišit.

Použití dnsmasq jako autoritativního serveru... snad nebylo myšleno opravdu vážně. Jako DNS "proxy" (+DHCP) na minimalistickém SOHO routeru to smysl nejspíš má (a třeba si tam i přihoďte definici několika "autoritativních jmen"), ale to je něco jiného.

Jsem vývojář Knot Resolveru.

Souhlasím, že u velmi primitivních nasazení je řešení all-in-one výhoda. Ale jinak jsou s tím jen problémy. Ještě bych rád upozornil, že implementačně se autoritativní a rekurzivní DNS server liší velmi výrazně a jejich průnik je malý.

Prečo? Ja som práve rád, že existuje Knot Resolver, ktorým som nahradil dnsmasq na svojej vlastnej sieti - čo by malo byť to primitívne nasadenie. Robí to presne tú jednu vec, čo chcem (PS: Aj v Knot Resolver-e sa dajú vytvoriť svoje vlastné interné domény a priradiť im konkrétna IP adresa a ako bonus to zvláda DoH.)

14. 10. 2021, 16:47 editováno autorem komentáře

Nevím přesně na co se ptáte. Proč se interně liší? Prostě je to tak. Každý server dělá něco jiného, a proto se liší jak struktury pro uložení dat (správa a reprezentace zón vs keš), tak i jejich zpracování (autoritativní odpovídání a podepisování vs resolver a validátor). I síťování se liší mezy Knoty (asynchronní vs synchronní). Samozřejmě to lze všechno naházet na jednu hromadu, ale kromě zmíněných nevýhod pro uživatele se takový projekt i hůře spravuje, trpí výkon a zbytečně to celé bobtná. Jinak společné obecné části kódu máme ve sdílených knihovnách. Rekurzor má být co nejjednodušší. Jak píšete, tak pro vaše použití evidentně vystačí jen DNS resolver s možností definice pár výjimek. To nabízí snad všechny implementace.

Jak píšou ostatní, mít autoritativní i rekurzivní server v jediné instanci prakticky vždycky znamená, že to máte špatně – a je jenom otázka času, kdy se ta chyba projeví. Pro správné vyřízení dotazu je totiž potřeba vědět, zda se má server chovat jako rekurzivní nebo jako autoritativní. A z dotazu klienta se to nedá poznat. Takže v téhle konfiguraci by si autoritativní server měl při každém dotazu ověřovat u nadřazeného serveru, zda je ještě stále autoritativní pro danou doménu – a to žádný server nedělá, pokud vím. Pak přesně dochází k těm situacím, co popisoval Petr – někdo se zeptá rekurzivního serveru, ten si myslí, že je na ten dotaz autoritativní a iniciativně odpoví ze své zóny, jenže odpoví špatně, protože skutečná zóna je dávno někde jinde.

Máte pravdu, seznam funkcí jsem mohl zmínit. Tak alespoň https://www.knot-dns.cz/docs/3.1/html/introduction.html#knot-dns-features. Pokud vás zajímá velmi hrubé srovnání, můžete kouknout třeba na https://en.wikipedia.org/wiki/Comparison_of_DNS_server_software Obecné porovnání by ale měl dělat někdo nezávislý např. https://blog.apnic.net/2021/02/25/putting-dnssec-signers-to-the-test-knot-vs-bind/ Ještě mohu nabídnout https://www.knot-dns.cz/benchmark/ a starší https://www.knot-dns.cz/benchmark-old/

Měl bych otázku, teda je to spíš na kresd než knot ale asi to bude podobný:
Jakým způsobem to nabindovat v případě anycastu?

Pokud jsem správně pochopil dokumentaci, tak se výrazně nedoporučuje listen: * protože si nedokáže odlišit adresu přes kterou přišel dotaz.

Mám 2 anycastové adresy, jednu IPv6 a jednu IPv4 + 2 unicastové. Můžu do listen uvést všechny? Můžu tam dát alespoň ten anycast nebo tam dát unicastové adresy a na ně ten anycast musím natovat?

Problém je v tom, že než přidávám anycastovou adresu tak testuji zda DNS funguje. Pak ji teprve přidám a ohlásím přes OSPF do sítě. Takže při startu resolveru tam ta adresa ještě není. Věděl by někdo jak tento uzel rozseknout? Provozujete někdo knot-resolver v anycastu?

Anycast adresy mám na dummy interface, který je normálně up už při spouštění kresd, kde je listen na unicast + anycast adresy. Celé to pak hlídá anycast-healthchecker, který upravuje filtr v birdu a podle ne/dostupnosti zapíná a vypíná šíření do OSPF.

Díky za tip (oběma), vyzkouším.

Taky dávám anycast na dummy, ale dosud jsem ho měl na bindu kterému * na listen nevadí a řešil jsem to přidáním/odebráním adresy místo filtru/protokolu v birdu. Šlo mi hlavně o to aby mi kresd nevracel odpovědi z jiné adresy, pokud se to neděje, tak je to dobrá zpráva.

S adresami se mi to chová korektně. Při požadavku na anycast odpovídá zpět s anycast adresou, směrem do internetu se ptá s unicast. Nevím jak se to chová s listen *, protože s takovou konfigurací jsem to ani nezkoušel.

Anycast mám na dummy trvale, hlavně kvůli tomu, že ten anycast-healthchecker kontroluje funkci proti anycast adrese, musí tedy být funkční ještě dřív, než se to odfiltruje a pustí do sítě.

Že kresd překládá kontroluji proti pár vybraným doménám z internetu a každý server z clusteru kontroluje jiné domény, ať ty servery případně nelehnou všechny stejně.

Směr k upstream serverům je nezávislý a tam by neměly být žádné problémy. Dokonce jde nakonfigurovat s jakou zdrojovou adresou se kresd ptá.

listen na 0.0.0.0 nebo :: skutečně může být problém pro odpovědi na dotazy klientů. Jednoduše řečeno, zdrojovou adresu vybírá OS dle adresy klienta, tedy pokud je možností více, může jít o špatnou adresu (tedy jinou než adresa kam byl dotaz poslán). Z hlediska kresd je to tedy potřeba obejít přes listen na konkrétních adresách (možno s freebind volbou), alespoň zatím.

Podobné detailní dotazy myslím bývá lepší pokládat v kanálech projektu a v Angličtině. Také je sledujeme více než diskuse na Rootu ;-)

Můžu ještě jeden doplňující dotaz tady? :-)

Moc nerozumím tomuhle:

Jednoduše řečeno, zdrojovou adresu vybírá OS dle adresy klienta, tedy pokud je možností více, může jít o špatnou adresu (tedy jinou než adresa kam byl dotaz poslán). Z hlediska kresd je to tedy potřeba obejít přes listen na konkrétních adresách (možno s freebind volbou), alespoň zatím.

Nemám teď v hlavě detaily socketového API, ale mám za to, že listen a send (pro UDP) jsou z hlediska OS dvě naprosto nezávislé operace, a při odeslání UDP paketu je volba na aplikaci, zda nastaví zdrojovou IP adresu nebo nechá její volbu na OS. Z toho by mi vycházelo, že pokud kresd nechává vždy volbu zdrojové IP adresy na OS, může i při naslouchání na víc IP adresách dojít k tomu, že OS zvolí pro odchozí paket nechtěnou IP adresu. Dokonce může OS zvolit jinou IP adresu, než na kterých kresd poslouchá, a to i když poslouchá jen na jedné adrese. Nebo když jsou v konfiguraci kresd uvedeny konkrétní IP adresy pro poslouchání, nastavuje kresd sám explicitně odchozí adresy?

Je otazka jestli by tady nepomohlo zapnout v kernelu net.ipv4.ip_non­local_bind a net.ipv6.ip_non­local_bind, potom muze aplikace bindovat IP, ktere jeste nejsou na zadnem interface. Hodne se to pouziva na redunantnich loadbalancerech, na DNS jsem to jeste nezkousel.

Mám otázku. Zaujaly mě krátké časy TTL/refresh/retry v příkladu. Má to nějaké důvody? Zvláště pro tak malo zónu?

Pak mám ještě poznámku, na debianu po instalaci balíku knot automaticky nenastartuje po rebootu. Je to bug balíku pro debian (příklady jsou pro ubuntu), nebo to jen chybí zmínit v článku?

Jak souvisí uvedené časy s velikostí zóny? Krátké časy se dávají proto, aby bylo možné rychle reagovat na změnu – při výpadku přesměrovat komunikaci na jiný server apod. Dlouhý čas je dobrý vlastně jenom k tomu, že šetří prostředky serveru a konektivitu (server není dotazován tak často), a to dnes nebývá problém.

Přesně z toho důvodu jak píšete. Server není dotazován tak často, zvláště pokud se zóna nemění moc často. Ale mé znalosti DNS zamrzly před mnoha lety a vlastně se přiznám, že jsem nikdy pořádně nevěděl jak časy nastavit, takže jsem často slepě kopíroval návody, kde to nikdy nebylo pořádně vysvětleno. Proto můj dotaz.

Četnost dotazování závisí mnohem víc na typu a používanosti služby než na počtu záznamů v zóně.

Dříve se dávaly delší časy (klidně ve dnech), aby se dotazování urychlilo (roundtrip mezi klientem a serverem, který znal odpověď, byl delší), případně aby se překlenuly výpadky. Dnes tyhle dva důvody prakticky pominuly a důležitá je ta schopnost reagovat na změnu.

Žádný velký záměr v těch uvedených hodnotách SOA nehledejte. Jen jsem chtěl, aby to nebylo málo nebo hodně :-) Opravdu záleží na konkrétní situaci: jak často se zóna mění, jak stabilní je sychronizace serverů, jak moc vadí, když se zónu nepodaří synchronizovat atd. A hlavně, pokud funguje správně NOTIFY, tak je to skoro jedno.

Chování na Debianu není záměr. Jakou verzi používáte? Klidně mi napiště email s podrobnostmi. Ale trochu podezírám nějaký lokální problém, protože by se nám už určitě někdo ozval. Díky.