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.