Вот быстрое и грязное: в BIND9 с динамической зоной, разделяемой между Просмотры, выполняя nsupdate, обновление / создание / удаление записи будет работать нормально, если я запрошу эту запись у клиента, который попадает в то же представление, из которого я выполнял nsupdate.
Запрашивая с точки зрения не тот же, что и тот, который я использовал для nsupdate, выдаст NXDOMAIN (при добавлении новой записи) или покажет информацию о старой записи в случае изменения / обновления, пока не пройдет какой-то произвольный промежуток времени (скажем, 15 минут), или я принудительно сделаю $ rndc freeze && rndc thaw
. $ rndc sync
Похоже, что вообще ничего не делает для решения проблемы - я надеялся, что это просто файл журнала, так как журнальные сбросы документированы для очистки около 15 минут.
Если это не ясно, вот какой-то псевдокод, с которого мы можем начать:
BIND Просмотры
view "cdn-redir" {
match-clients { 10.1.1.0/24; 10.1.2.0/24; };
include "cdn-zone.db";
include "dynamic-zone.db";
};
view "default" {
match-clients { any; };
include "dynamic-zone.db";
};
Пример командной строки
user@ns:~$ nsupdate -k rndc.key
> server localhost
> zone example.com.
> update add foohost.example.com. 600 A 10.5.6.7
> send
> quit
user@ns:~$ dig foohost.example.com (resolv.conf points to 127.0.0.1)
[ responds with correct answer 10.5.6.7 ]
В другом месте хост попадает в ту же точку зрения, что и nsupdate
user@10.11.12.50:~$ foohost.example.com (resolv.conf points to above nameserver)
[ responds with correct answer 10.5.6.7 ]
В другом месте хост попадает в разные рассматривать как nsupdate
user@10.1.1.50:~$ dig foohost.example.com (resolv.conf points to above nameserver)
[ responds with NXDOMAIN even though I'm asking the same server ]
На этом этапе, если я буду терпелив, проблема в конечном итоге разрешится сама собой (возможно, через 15 минут), но мне часто не хватает терпения, поэтому я вынужден $ rndc freeze && rndc thaw
на сервере имен, чтобы принудительно устранить проблему.
С другой стороны
С другой стороны, если я выполняю nsupdate для сервера с адреса, который попадает в представление «cdn-redir», проблема полностью меняется. Последующие запросы от клиентов, соответствующих "cdn-redir", получают правильную запись сразу после nsupdate, без использования "rndc freeze / thaw", но запросы с адресов, которые не попадают в поле зрения "cdn-redir", теперь имеют глупость delay / rndc.
Мой главный вопрос
Если бы было так просто, как 42, я бы воспринял это с распростертыми объятиями ...
Я бы хотел избежать необходимости «rndc freeze && rndc thaw» из-за страха пропустить динамическое обновление с DHCP-сервера. Кто-нибудь знает, как более эффективно / действенно синхронизировать обновленные записи между представлениями, или может пролить свет на то, где я могу ошибаться?
Изменить: BIND 9.9.5 / Ubuntu 14.04, но это произошло в предыдущих версиях Ubuntu и BIND.
Спасибо всем!
По просьбе Эндрю Б., вот отредактированная (и частичная) зона:
$ORIGIN .
$TTL 3600
example.com IN SOA ns1.example.com. HOSTMASTER.example.com. (
2009025039 ; serial
900 ; refresh 15
600 ; retry 10
86400 ; expire 1 day
900 ; minimum 15 min
)
NS ns1.example.com.
$ORIGIN example.com.
$TTL 30
AEGIS A 10.2.1.60
TXT "31bdb9b3dec929e051f778dda5abd0dfc7"
$TTL 86400
ts-router A 10.1.1.1
A 10.1.2.1
A 10.1.3.1
A 10.1.4.1
A 10.1.5.1
A 10.1.6.1
A 10.1.7.1
A 10.1.8.1
A 10.2.1.1
A 10.2.2.1
A 10.2.3.1
ts-server A 10.2.1.20
ts-squid0 A 10.2.2.20
ts-squid1 A 10.2.2.21
$TTL 600
tssw4 A 10.2.3.4
tssw5 A 10.2.3.5
tssw6 A 10.2.3.6
tssw7 A 10.2.3.7
; wash rinse repeat for more hosts
$TTL 30
wintermute A 10.2.1.61
TXT "003f141e5bcd3fc86954ac559e8a55700"
Различные представления действуют отдельно, это, по сути, удобство запуска отдельных экземпляров named. Если в разных представлениях есть зоны с одинаковыми именами, это просто совпадение, они по-прежнему являются полностью отдельными зонами, не более связанными, чем любые другие зоны.
Использование одного и того же файла зоны в нескольких отдельных зонах не работает в ситуациях, когда связывание обновляет содержимое зоны самостоятельно (подчиненные зоны, зоны с динамическими обновлениями и т. Д.). Я не уверен, есть ли даже риск повредить сам файл зоны.
Вы можете установить что-то вроде того, что вы хотите сделать, если зона в одном представлении будет подчиненной для зоны с тем же именем в другом представлении. Это явно будет несколько сложная конфигурация, но с использованием ключей TSIG для сопоставимых клиентов, а также уведомления / передачи, я считаю, что это должно быть выполнимо.
Изменить: ISC опубликовала статью в базе знаний для этого сценария, Как разделить динамическую зону между несколькими представлениями?, предлагая ту же конфигурацию, о которой говорилось выше.
Это их пример конфигурации с несколько улучшенным форматированием:
key "external" {
algorithm hmac-md5;
secret "xxxxxxxx";
};
key "mykey" {
algorithm hmac-md5;
secret "yyyyyyyy";
};
view "internal" {
match-clients { !key external; 10.0.1/24; };
server 10.0.1.1 {
/* Deliver notify messages to external view. */
keys { external; };
};
zone "example.com" {
type master;
file "internal/example.db";
allow-update { key mykey; };
also-notify { 10.0.1.1; };
};
};
view "external" {
match-clients { key external; any; };
zone "example.com" {
type slave;
file "external/example.db";
masters { 10.0.1.1; };
transfer-source { 10.0.1.1; };
// allow-update-forwarding { any; };
// allow-notify { ... };
};
};
Имея аналогичные проблемы с представлениями, я решил избавиться от них и вместо этого перенести авторизацию в зоны.
Вы можете заменить представления в вопросах простым включением обоих файлов зоны, оставить текущую общую зону (зоны) нетронутой и добавить allow-query {} в определение "dynamic-zone.db", например:
zone "dynamic.zone" {
allow-query { 10.1.1.0/24; 10.1.2.0/24; };
type master;
file "/etc/bind/zones/master/dynamic.zone";
update-policy { .... };
};
Этим вы достигнете предполагаемой цели - сделать dynamic.zone доступным только из указанных сетей и сделать другие зоны общедоступными.