DNS “views” and controlling zone transfers with TSIG
Running Bind 9.8.2. I have successfully setup TSIG keys for "views" using a DNS master/server pair. Zone transfers are working as expected between the 2 servers for each view. Before we go live into production with this I need some clarification on a couple things. Our prod servers are also allowing zone transfers to a few other servers besides the slave server. We have an acl setup that looks similar to this:
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
And in the "allow transfer" statement we have included that ACL. My question is:
Now that we are using TSIG, will I need to get with the admins of all these other servers and provide them my TSIG key so they can request zone transfers? I would think something like that needs to be done since it was required to be configured on slave server, but I am not sure.
Next,
I setup views so that clients on the "internal" network when requesting a record would be presented with different records than clients on the outside. And at the moment there is only one zone that is required to have different records. However, It is my understanding that since views are based off source IP's, if I was to ONLY include that one zone in my "internal" view, if a record was requested for another zone from that same IP, they would probably get an nxdomain answer since that IP is limited to that one view.
So, my question is, will I need to include all zones in both views so that all clients can get results, even though I would only have (at the moment) one zone that points to two different zone files? All others in both views would point to the same zone file, unless of course there is another zone we need to present a different view to for internal clients.
Now, last question.
I have a concern about the allow-query statement. On our production server we have an ACL list we'll call it "allowed". We have an allow query statement in the global options to only allow queries from IP's in the allowed ACL. However every one of our zone entries in the conf file also has an "allow-query { any; }; statement. Doesn't that defeat the purpose of have an "allowed" ACL for queries? Is this bad design? Doesn't the zone statement take precedence over the global statement?
Теперь, когда мы используем TSIG,мне нужно будет связаться с админами всех эти другие серверы и предоставить им мой ключ TSIG, чтобы они могли запросить зональные трансферы? Я думаю, что нужно сделать что-то подобное так как он должен был быть настроен на подчиненном сервере, но я не конечно.
Прежде всего, относительно «предоставить им мой ключ TSIG»: Нет, нет особого смысла просто сгенерировать один единственный ключ и поделиться им со всеми, кто участвует в вашей настройке.
Я бы сказал, создавайте по одному ключу для каждой партии, в конце концов, вы можете иметь столько ключей, сколько захотите. Таким образом вы можете предоставить разный доступ разным сторонам и отозвать доступ одной стороны, не отменяя доступ всех.
Кроме того, использование TSIG для некоторых вещей не обязательно подразумевает использование TSIG для всех вещей (хотя часто это предпочтительнее), можно смешивать управление доступом на основе IP и ключа, если это работает для вашего сценария.
Итак, мой вопрос: нужно ли мне включать все зоны в оба представления, чтобы что все клиенты могут получить результаты, даже если у меня будет только (на момент) одна зона, указывающая на два разных файла зоны? Все другие в обоих представлениях будут указывать на один и тот же файл зоны, если только Конечно, есть еще одна зона, нам нужно представить другой взгляд на для внутренних клиентов.
Каждый запрос будет попадать только в одно представление (первое соответствующее представление).
Подразумевается, что если данные недоступны в представлении, которое клиент выполняет своими запросами, либо в зоне в этом представлении, либо через рекурсию (если рекурсия доступна для клиента, и они запрашивают ее), они не могут получить к этому data.
Вполне возможно, что вам понадобится больше зон, дублированных между представлениями.
Меня беспокоит оператор allow-query. На нашем производстве server у нас есть список ACL, который мы назовем "разрешенным". У нас есть разрешение запрос в глобальных параметрах, чтобы разрешить запросы только с IP-адресов в разрешенном ACL. Однако все записи о нашей зоне в конф файл также имеет оператор "allow-query {any;};". Разве это не поражает цель иметь "разрешенный" ACL для запросов? Это плохой дизайн? Разве оператор зоны не имеет приоритет над глобальным оператором?
Да, запрос разрешения , указанный в зоне , переопределит глобальный запрос разрешения ] значение. Для запросов, которые соответствуют вашим зонам, это означает, что глобальные настройки не используются, однако, если рекурсия включена, вы также имеете дело с запросами, которые не соответствуют ни одной из ваших зон.
См. allow- * настройки в руководстве о том, как эти настройки взаимодействуют.