Показать сообщение отдельно
  #2  
Старый 14.07.2018, 14:22
Alexey Vissarionov
Guest
 
Сообщений: n/a
По умолчанию Разница между type static-stub и type forward в zone у bind

Alexey Vissarionov написал(а) к Alexandr Kruglikov в Jul 18 12:40:00 по местному времени:

Доброго времени суток, 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
Ответить с цитированием