Запуск Bind 9.8.2. Я успешно установил ключи TSIG для "представлений" с помощью пары "главный / сервер DNS". Зональные передачи между двумя серверами для каждого представления работают должным образом. Прежде чем мы перейдем к производству, мне нужно кое-что прояснить. Наши прод-серверы также позволяют передавать зоны на несколько других серверов, помимо подчиненного сервера. У нас есть настройка acl, которая выглядит примерно так:
other_xfer_allowed {
x.x.x.x; // This is our Secondary DNS server
127.0.0.1; // localhost can make zone transfers
x.x.x.x/24; // Corporate server farm range is allowed to make zone-transfers
x.x.x.x/24; // NAT pool for internal DNS server Zone Transfers
}; // end of "other_xfer_allowed" ACL
И в оператор «разрешить передачу» мы включили этот ACL. У меня вопрос:
Теперь, когда мы используем TSIG, нужно ли мне связываться с администраторами всех этих серверов и предоставлять им свой ключ TSIG, чтобы они могли запрашивать передачу зоны? Я бы подумал, что нужно сделать что-то подобное, поскольку это требовалось настроить на ведомом сервере, но я не уверен.
Следующий,
Я настраиваю представления так, чтобы клиентам во «внутренней» сети при запросе записи представлялись записи, отличные от клиентов во внешней сети. И на данный момент есть только одна зона, в которой требуются разные записи. Однако, насколько я понимаю, поскольку представления основаны на исходных IP-адресах, если бы я должен был ТОЛЬКО включить эту одну зону в свое «внутреннее» представление, если бы запись была запрошена для другой зоны с того же IP-адреса, они, вероятно, получили бы nxdomain ответ, так как этот IP ограничен одним представлением.
Итак, мой вопрос: нужно ли мне включать все зоны в оба представления, чтобы все клиенты могли получать результаты, даже если у меня будет (на данный момент) только одна зона, указывающая на два разных файла зоны? Все остальные в обоих представлениях будут указывать на один и тот же файл зоны, если, конечно, нет другой зоны, в которой нам нужно представить другое представление для внутренних клиентов.
Теперь последний вопрос.
Меня беспокоит инструкция allow-query. На нашем производственном сервере у нас есть список ACL, который мы назовем «разрешенным». У нас есть оператор allow query в глобальных параметрах, чтобы разрешать запросы только с IP-адресов в разрешенном ACL. Однако каждая из наших записей зоны в файле conf также имеет оператор «allow-query {any;};». Разве это не противоречит цели «разрешенного» ACL для запросов? Это плохой дизайн? оператор зоны имеет приоритет над глобальным оператором?
Теперь, когда мы используем TSIG, нужно ли мне связываться с администраторами всех этих серверов и предоставлять им свой ключ TSIG, чтобы они могли запрашивать передачу зоны? Я бы подумал, что что-то подобное нужно сделать, поскольку это требовалось настроить на подчиненном сервере, но я не уверен.
Прежде всего, что касается «предоставить им мой ключ TSIG»: нет, нет особого смысла просто сгенерировать один единственный ключ и поделиться им со всеми, кто участвует в вашей настройке.
Я бы сказал, создавайте по одному ключу для каждой партии, в конце концов, вы можете иметь столько ключей, сколько захотите. Таким образом, вы можете предоставить разный доступ разным сторонам и отозвать доступ для одной стороны, не отменяя доступ для всех.
Кроме того, использование TSIG для некоторых вещей не обязательно подразумевает использование TSIG для всех вещей (хотя часто это предпочтительнее), можно смешивать управление доступом на основе IP и ключа, если это работает для вашего сценария.
Итак, мой вопрос: нужно ли мне включать все зоны в оба представления, чтобы все клиенты могли получать результаты, даже если у меня будет (на данный момент) только одна зона, указывающая на два разных файла зоны? Все остальные в обоих представлениях будут указывать на один и тот же файл зоны, если, конечно, нет другой зоны, в которой нам нужно представить другое представление для внутренних клиентов.
Каждый запрос будет попадать только в одно представление (первое соответствующее представление).
Подразумевается, что если данные недоступны в представлении, которое клиент выполняет своими запросами, либо в зоне в этом представлении, либо через рекурсию (если рекурсия доступна для клиента, и они запрашивают ее), они не могут получить к этому данные.
Вполне возможно, что вам понадобится больше зон, дублированных между видами.
Меня беспокоит инструкция allow-query. На нашем производственном сервере у нас есть список ACL, который мы назовем «разрешенным». У нас есть оператор allow query в глобальных параметрах, чтобы разрешать запросы только с IP-адресов в разрешенном ACL. Однако каждая из наших записей зоны в файле conf также имеет оператор «allow-query {any;};». Разве это не противоречит цели создания «разрешенного» ACL для запросов? Это плохой дизайн? оператор зоны имеет приоритет над глобальным оператором?
Да, allow-query указано в zone переопределит глобальный allow-query стоимость. Для запросов, которые соответствуют вашим зонам, это означает, что глобальные настройки не используются, однако, если рекурсия включена, вы также имеете дело с запросами, которые не соответствуют ни одной из ваших зон.
Пожалуйста, посмотрите allow-* настройки в руководстве как эти настройки взаимодействуют.