Задержка обновлений динамической зоны BIND, которая используется совместно для представлений

Вот быстрое и грязное: на 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 && 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. Если в разных представлениях есть зоны с одинаковыми именами, это просто совпадение, они по-прежнему являются совершенно отдельными зонами, не более связанными, чем любые другие зоны.

При использовании нескольких отдельных зон один и тот же файл зоны не работает в ситуациях, когда bind самостоятельно обновляет содержимое зоны (подчиненные зоны, зоны с динамическими обновлениями и т. Д.). Я не уверен, есть ли риск повреждения самого файла зоны.

Возможно, вы сможете настроить что-то наподобие того, что вы хотите сделать, сделав зону в одном представлении подчиненной для зоны с таким же именем в другом представлении. Очевидно, это будет довольно сложная конфигурация, но с использованием ключей TSIG для сопоставления клиентов, а также уведомлений / передач, я думаю, это должно быть выполнимо.

Изменить: ISC опубликовал статью KB для этого сценария, Как я могу разделить динамическую зону между несколькими представлениями? , предлагая тот же вид конфигурации, упомянутый выше.

Это их пример конфигурации с несколько улучшенным форматированием:

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 доступным только из указанных сетей и сделать другие зоны общедоступными.