Portál AbcLinuxu, 10. května 2025 20:57
Záleží na obsahu zón. Patrně jste koukal pouze na deployment pro Root server. U všech ostatních konfigurací v benchmarku spotřeba paměti mezi 1.4 a 1.5 klesla. Když se podíváte třeba na Hosting (100k zón), tak tam RSS spadla z 3280 MB na 1038 MB.
Podařilo se nám zredukovat některé interní struktury pro ukládání obsahu zóny. Ale také jsme chtěli zvýšit výkon odpovídání pro kořenové servery a TLD, kdy server velmi často vrací delegace. A u delegací je nutné v zóně ještě dohledat záznamy do Additional sekce odpovědi, což tvoří velkou část zpracování dotazu. Takže tyto záznamy dohledáváme už při načítání zóny. Cenou za to je paměť navíc pro zóny, které obsahují velké množství různých delegací, což je právě případ kořenové zóny. Ale to je dost specifický případ.
V každém případě Knot DNS používá hodně velkých hosterů (ne jako výhradní řešení). Napadá mě: .cz doména, .dk doména, Netriplex, RIPE NCC, Hosting90, Igloonet, O2, ...
Obecně doporučujeme postup 1. knotc flush, 2. upravit zónový soubor, 3. zvýšit serial a 4. knotc reload.Promiň mi blbý dotaz, to obecně doporučujeme znamená, že to má i nějaké prominentní místo v dokumentaci nebo se to šíří jen ústně?
Co se trochu zlepšilo je formát zónového souboru. Teď se postupně do souboru zapisují nejdříve "běžné" záznamy, pak RRSIG záznamy a nakonec NSEC/NSEC3 chain. Takže se běžné záznamy nemíchají s těmi automaticky vygenerovanými a ten soubor je výrazně přehlednější.To je skvělý nápad.
Ideální to ale není. Snažíme se najít nějaký lepší způsob a uvítáme nápady.Z diskuze vyplynulo že (1) řešení není zcela triviální a hlavním problémem jsou ta sériová čísla a (2) BIND to nějak řeší. Takže pokud byste měli čas trochu analyzovat jak to funguje v BINDu (já to asi sám nedám, jedině se pobavit s Petrem), docela by mě zajímal výstup a informace jestli je nebo není možné jejich postup aplikovat na Knot a proč.
Promiň mi blbý dotaz, to obecně doporučujeme znamená, že to má i nějaké prominentní místo v dokumentaci nebo se to šíří jen ústně?V dokumentaci to není, takže ústně. Ale mohu se vymluvit na to, že automatické podepisování stále považujeme za technical preview.
Z diskuze vyplynulo že (1) řešení není zcela triviální a hlavním problémem jsou ta sériová čísla a (2) BIND to nějak řeší. Takže pokud byste měli čas trochu analyzovat jak to funguje v BINDu (já to asi sám nedám, jedině se pobavit s Petrem), docela by mě zajímal výstup a informace jestli je nebo není možné jejich postup aplikovat na Knot a proč.Ano, problém jsou především sériová čísla. BIND 9.9 to řeší tak, že si udžuje zvlášt nepodepsanou a podepsanou zónu. A sériová čísla počítá pro nepodepsanou a podepsanou zónu zvlášť. Pokud sériové číslo u nepodepsané zóny je vyšší než u podepsané zóny, tak sériové číslo podepsáné zóny zvedne na stejnou hodnotu. Knot DNS má pouze jeden zónový soubor, jedno sériové číslo a snaží se ho nezvedat, pokud to není potřeba. Oba přístupy mají výhody a nevýhody.
Ale mohu se vymluvit na to, že automatické podepisování stále považujeme za technical preview.A toto už je součástí psané dokumentace, doufám.
BIND 9.9 to řeší tak, že si udžuje zvlášt nepodepsanou a podepsanou zónu. A sériová čísla počítá pro nepodepsanou a podepsanou zónu zvlášť.To mi dává docela smysl.
Oba přístupy mají výhody a nevýhody.Jak moc složité by bylo implementovat v Knotu obojí a volbu nechat na uživateli? Pochopím, když mě s tím pošleš do háje ;).
A toto už je součástí psané dokumentace, doufám.Ano.
Jak moc složité by bylo implementovat v Knotu obojí a volbu nechat na uživateli? Pochopím, když mě s tím pošleš do háje ;).Já osobně bych se přikláněl pro jedno lepší řešení, na kterém se usneseme. Ale nezáleží to jenom na mně. Oddělení nepodepsané a podepsané zóny stále diskutujeme. Líbí se nám to, ale zatím jsme se nerozhodli, jakým konkrétním způsobem to implementovat. Takže nevím, neumím na to odpovědět.
Ano, problém jsou především sériová čísla.A co tenhle pristup: 1) Mame uzivatelsky zonovy soubor (treba v /etc/..., nepodepsany) a interni zonovy soubor (treba ve /var/..., automaticky podepsany). Uzivatelsky zonovy soubor demon nemodifikuje (jen ho cte), na interni zonovy soubor by zas nemel sahat uzivatel. 2) Uzivatelsky zonovy soubor *neobsahuje* seriove cislo, management serioveho cisla je plne v rezii demona (a je ulozeno v internim zonovem souboru). 3) Pri startu ci pozadavku na reload zony demon pozna, zda doslo ke zmene uzivatelskeho zonoveho (napr. podle timestampu, hashe ci porovnani s prislusnou cast interniho zonoveho souboru), v takovem pripade si updatuje interni kopii, vygeneruje podpisy a zvysi seriove cislo.
2) Uzivatelsky zonovy soubor *neobsahuje* seriove cislo, management serioveho cisla je plne v rezii demona (a je ulozeno v internim zonovem souboru).To by se mi hodně líbilo. Spravovat sériové číslo v texťáku je věc, která mě na BINDu nejvíc nebaví.
Uzivatelsky zonovy soubor *neobsahuje* seriove cislo, management serioveho cisla je plne v rezii demonaTam může vzniknout problém, pokud se přechází z jiného serveru. Chtělo by to umět KnotDNS říct alespoň počáteční sériové číslo. Nebo pokud by někdo chtěl provozovat různé servery vedle sebe stále a chtěl je mít na sobě úplně nezávislé (tj. i data synchronizovat přes zdrojové zónové soubory). Každopádně pro běžný provoz by tenhle způsob byl podle mne nejjednodušší.
Chtělo by to umět KnotDNS říct alespoň počáteční sériové číslo.To lze osetrit tak, ze pokud by v uzivatelske zone seriove cislo bylo uvedene, tak by ho demon vzal jako dolni mez a pripadne realne seriove cislo navysil.
Nebo pokud by někdo chtěl provozovat různé servery vedle sebe stále a chtěl je mít na sobě úplně nezávislé (tj. i data synchronizovat přes zdrojové zónové soubory).V takovem pripade by je uzivatel nemel provozovat v rezimu, kdy si sami upravuji zonu (napr. podepisuji).
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.
6.6.2014 11:18
6.6.2014 11:36
6.6.2014 15:54