Разница между type static-stub и type forward в zone у bind

Alexandr Kruglikov написал(а) к All в Jul 18 18:32:56 по местному времени:

Привет, All!

Собственно, $SUBJ.
Если можно - по-русски. Гуглом нашёл, что:

Stub zones: only available as a single level beyond one's "authoritative
core", i.e. the stub server must be able to talk directly to one or more
authoritative servers for the zone.
Forward zones: can be daisy-chained an arbitrary number of levels from
the authoritative core (but this is not recommended due to
manageability, performance and reliability concerns).

Stub zones: will use whatever is in the NS records of the zone (or
descendants of the zone, if not otherwise defined) to resolve queries
which are below a zone cut.
Forward zones: will always use the configured forwarders, which must
support recursion, even for names which are known to be deeper in the
delegation hierarchy and whose delegated/authoritative nameservers might
respond more quickly than the forwarders, if asked.

As a general rule, use "type forward" zones only if you have some
connectivity issue you need to work around, e.g. trying to resolve
Internet names from behind a restrictive firewall. Use slave zones if
you want a full copy of the zone available at all times (unless it
expires of course), thus maximizing fault-tolerance and
client-to-resolver performance, but subject to the replication overhead,
storage space and willingness of the zone owner to allow zone transfers.
And use stub zones if you want a more lightweight alternative to
slaving, at the expense of some fault-tolerance and client-to-resolver
performance.

To answer your specific question, the non-intuitive[1] "forwarders { };"
is needed to inhibit forwarding which has presumably been defined at a
higher level (semantically) in your config, either at the
1.10.in-addr.arpa level, or somewhere above that, explicitly, or
so-called "global forwarding" defined in the "options" clause. By
default, named does not forward, so if those were the only 2 zone
definitions in named.conf, and there was nothing about forwarding in
your "options" clause, then you wouldn't need "forwarders { };" in any
of your zone definitions. You only see that directive in "hybrid"
configs, where forwarding is used at one level of the namespace
hierarchy, and then overridden with regular iterative forwarding at a
lower level.

но моего английского не хватило для чёткого понимания...

* Оригинал написан в RU.LINUX
* Скопировано в RU.UNIX

С наилучшими пожеланиями, Alexandr.

--- "GoldED+/LNX 1.1.5-b20170303" ---

Eugene Grosbein написал(а) к Alexandr Kruglikov в Jul 18 02:59:06 по местному времени:

13 июля 2018, пятница, в 16:32 NOVT, Alexandr Kruglikov написал(а):

AK> Собственно, $SUBJ.
AK> Если можно - по-русски.

А тебе какая разница? :-)
У тебя есть какая-то проблема и ты хочешь её решить при помощи
стаб- или форвард-зоны? Так излагай проблему.

А если речь идёт просто об образовательном моменте, то улучшай
свой английский.

Eugene
--
Что делать?! Мир стоит на воровстве!..
Воруют в Самарканде и в Хиве,
В Ширазе, в Тегеране и в Стамбуле
И даже - страшно вымолвить - в Москве!..
--- slrn/1.0.3 (FreeBSD)

Alexandr Kruglikov написал(а) к Eugene Grosbein в Jul 18 08:15:48 по местному времени:

Привет, Eugene!

* Ответ на сообщение из CarbonArea (Мыльце для меня).

14 июл 18 02:59, Eugene Grosbein писал(а) к Alexandr Kruglikov:

AK>> Собственно, $SUBJ.
AK>> Если можно - по-русски.
EG> А тебе какая разница? :-)
EG> У тебя есть какая-то проблема и ты хочешь её решить при помощи
EG> стаб- или форвард-зоны? Так излагай проблему.

Нужно, чтобы кеширующий bind брал одну из зон с определённого NS.

EG> А если речь идёт просто об образовательном моменте, то улучшай
EG> свой английский.

Ежедневно этим занимаюсь.

С наилучшими пожеланиями, Alexandr.

--- "GoldED+/LNX 1.1.5-b20170303" ---

Eugene Grosbein написал(а) к Alexandr Kruglikov в Jul 18 12:59:00 по местному времени:

16 июля 2018, понедельник, в 06:15 NOVT, Alexandr Kruglikov написал(а):

AK>>> Собственно, $SUBJ.
AK>>> Если можно - по-русски.
EG>> А тебе какая разница? :-)
EG>> У тебя есть какая-то проблема и ты хочешь её решить при помощи
EG>> стаб- или форвард-зоны? Так излагай проблему.
AK> Нужно, чтобы кеширующий bind брал одну из зон с определённого NS.

Если у данного NS разрешен zone transfer или на нём можно это включить,
то самое производительное будет просто завести на кеширующем bind
эту зону как secondary, указав "определенный NS" в качестве master для зоны.

Тогда будет обеспечена максимальная скорость ресолва записей этой зоны
и даже если связь с NS прервется на время, не превышающее expire зоны
(обычно часы или дни), юзера кеширующего bind этого даже не почуствуют,
так как он будет обслуживать запросы к зоне из собственной копии,
как и любой другой secondary. Изменения в саму зону при этом вносить
не требуется (добавлять bind в список NS необязательно).

Если zone transfer включить нельзя, то опиши зону как type forward
с forward only и укажи определённый NS в качестве forwarders,
как это в своё время делалось после разделегирования torrents.ru:

zone "torrents.ru" {
type forward;
forward only;
forwarders {
195.82.146.50;
195.82.147.50;
};
};

Eugene
--
Устав от радостных пиров,
Не зная страхов и желаний
--- slrn/1.0.3 (FreeBSD)

Alexandr Kruglikov написал(а) к Eugene Grosbein в Jul 18 12:23:00 по местному времени:

Привет, Eugene!

* Ответ на сообщение из CarbonArea (Мыльце для меня).

16 июл 18 12:59, Eugene Grosbein писал(а) к Alexandr Kruglikov:

AK>>>> Собственно, $SUBJ.
AK>>>> Если можно - по-русски.
EG>>> А тебе какая разница? :-)
EG>>> У тебя есть какая-то проблема и ты хочешь её решить при помощи
EG>>> стаб- или форвард-зоны? Так излагай проблему.
AK>> Нужно, чтобы кеширующий bind брал одну из зон с определённого NS.
EG> Если у данного NS разрешен zone transfer или на нём можно это
EG> включить, то самое производительное будет просто завести на кеширующем
EG> bind эту зону как secondary, указав "определенный NS" в качестве
EG> master для зоны.
EG> Тогда будет обеспечена максимальная скорость ресолва записей этой зоны
EG> и даже если связь с NS прервется на время, не превышающее expire зоны
EG> (обычно часы или дни), юзера кеширующего bind этого даже не
EG> почуствуют, так как он будет обслуживать запросы к зоне из собственной
EG> копии, как и любой другой secondary. Изменения в саму зону при этом
EG> вносить не требуется (добавлять bind в список NS необязательно).

Это была первая мысль, но, к сожалению, админы того NS не хотят мне её пересылать =(

EG> Если zone transfer включить нельзя, то опиши зону как type forward
EG> с forward only и укажи определённый NS в качестве forwarders,
EG> как это в своё время делалось после разделегирования torrents.ru:

Спасибо, так и сделал. Всё работает!

С наилучшими пожеланиями, Alexandr.

--- "GoldED+/LNX 1.1.5-b20170303" ---