= Сообщение: 5164 из 8555 ========================================= RU.LINUX = От : Alexey Vissarionov 2:5020/545 14 Jul 18 12:40:00 Кому : Alexandr Kruglikov 14 Jul 18 12:40:00 Тема : Разница между type static-stub и type forward в zone у bind FGHI : area://RU.LINUX?msgid=2:5020/545+5b49ca63 На : area://RU.LINUX?msgid=2:5053/58+5b48b87f = Кодировка сообщения определена как: CP866 ================================== ============================================================================== Доброго времени суток, Alexandr! 13 Jul 2018 18:32:56, ты -> All:
AK> Собственно, $SUBJ. Если можно - по-русски. Гуглом нашёл, что: AK> Stub zones: only available as a single level beyond one's AK> "authoritative core", i.e. the stub server must be able to talk AK> directly to one or more authoritative servers for the zone. AK> Forward zones: can be daisy-chained an arbitrary number of levels AK> from the authoritative core (but this is not recommended due to AK> manageability, performance and reliability concerns).
Ну написано же человеческим по фоновому: stub - спрашиваем у первоисточника, forward - спрашиваем у апстримного ресолвера.
AK> Stub zones: will use whatever is in the NS records of the zone (or AK> descendants of the zone, if not otherwise defined) to resolve queries AK> which are below a zone cut. AK> Forward zones: will always use the configured forwarders, which must AK> support recursion, even for names which are known to be deeper in the AK> delegation hierarchy and whose delegated/authoritative nameservers AK> might respond more quickly than the forwarders, if asked.
Здесь то же самое, но другими словами. Заодно сказано, что первоисточником считаются серверы, указанные в записях NS.
AK> As a general rule, use "type forward" zones only if you have some AK> connectivity issue you need to work around, e.g. trying to resolve AK> Internet names from behind a restrictive firewall.
Пример высосан из пальца. Реальное применение для сейчас - в ресолвере на пластмассовом роутере (да и то проще сделать его forward only, чтобы только кешировал). Ну, если локальных зон нет, разумеется.
AK> Use slave zones if you want a full copy of the zone available at all AK> times (unless it expires of course), thus maximizing fault-tolerance AK> and client-to-resolver performance, but subject to the replication AK> overhead, storage space and willingness of the zone owner to allow AK> zone transfers.
Вторичники - хорошо, ога. Но помимо требования AXFR возникают риски cache poisoning, поэтому лучше фпень (у меня 4 высоконагруженных сервера, и все - первичники).
AK> And use stub zones if you want a more lightweight alternative to AK> slaving, at the expense of some fault-tolerance and client-to-resolver AK> performance.
Игого: сервер, где описан stub - это такой недовторичник, который не всю зону тащит по AXFR, а только свои же запросы кеширует, но при этом не проходит всю цепочку от ".", а сразу обращается к первоисточнику.
AK> но моего английского не хватило для чёткого понимания...
"Учите немецкий - он таки на ваш идиш похож" // (ц)
-- Alexey V. Vissarionov aka Gremlin from Kremlin gremlin ПРИ gremlin ТЧК ru; +vii-cmiii-ccxxix-lxxix-xlii
... Чужие темплейты читают только ламеры с IQ<64 --- /bin/vi * Origin: http://openwall.com/Owl/ru (2:5020/545)
