Vlákno názorů k článku Nasazujeme Knot DNS na vlastní doméně: praktický návod od ... - Měl bych otázku, teda je to spíš na...

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.