Конфигурация с разделенным DNS: невозможно обновить внешнюю зону из внутренней системы с помощью nsupdate

Я настроил один DNS-сервер с bind9 и конфигурацией split dns, чтобы все внутренние запросы для моего доменного имени получали внутренний IP-адрес, а все запросы извне моей сети получали официальный адрес (которые маршрутизируются через брандмауэр Cisco ASA). но в итоге дойдет до тех же систем).

Когда я использую nsupdate из своей внутренней сети, внутренняя зона обновляется. Аналогично, когда я запускаю nsupdate на внешней системе (с TSIG), внешняя зона обновляется.

Однако я бы предпочел обновить все данные DNS из внутренней сети. Кажется, проблема в том, что я могу определить несколько представлений для моего доменного имени, но bind9 идентифицирует зону для использования по IP-адресу клиента, согласно моему views.conf. Поэтому, когда это внутренний IP-адрес, внутренняя зона извлекается или обновляется, но невозможно обновить внешнюю зону из внутренней системы.

Я также попытался использовать два разных ключа TSIG в надежде, что bind9 сможет идентифицировать внешнюю зону по ключу, который тоже не работает:

Aug 26 11:04:22 s1006 named[13444]: client 10.1.1.6#39841: view internal: signer "external" denied
Aug 26 11:04:22 s1006 named[13444]: client 10.1.1.6#39841: view internal: update 'example.org/IN' denied

Вот соответствующие параметры конфигурации bind9:

view "internal" {
        match-clients {
                10.1.1.6;
        };
        recursion yes;
        include "/etc/bind/named.conf.default-zones";

        include "/etc/bind/zones/example.org-internal.conf";
};

view "external" {
        match-clients {
                10.1.1.3;
        };
        recursion no;
        include "/etc/bind/named.conf.default-zones";

        include "/etc/bind/zones/example.org-external.conf";
};

key internal {
        algorithm hmac-md5;
        secret "x2ZKW4SxbeySMK7PmV1Nng==";
};

key external {
        algorithm hmac-md5;
        secret "kiHB9BR6IeSmUUnp1QMCcA==";
};

zone "example.org" {
        type master;
        file "/var/cache/bind/example.org-internal/example.org";
        notify yes;
        allow-update {
                key internal;
        };
};

zone "example.org" {
        type master;
        file "/var/cache/bind/example.org-external/example.org";
        notify yes;
        allow-update {
                key external;
        };
};

Примечание: в целях тестирования представления настраиваются таким образом, чтобы все запросы из 10.1.1.3 были "внешними" и из 10.1.1.6 считались "внутренними".

Посоветуйте, пожалуйста, как настроить это так, чтобы я мог обновить внешнюю зону, запустив nsupdate на 10.1.1.6 вместо 10.1.1.3. Также, если вы думаете, что эта конкретная установка - действительно глупая идея, пожалуйста, дайте мне знать.

Источник

1 ответ

Я думаю, что лучшим решением будет просто использовать специальные ключи TSIG для доступа к различным представлениям.

Я знаю, что в вопросе упоминается об этом и говорится, что это не сработало, но это должно быть потому, что директивы сопоставления клиентов двух представлений не были обновлены должным образом.

Если предположить, что есть два ключа TSIG с именем internal и external для этой цели (похоже, в вопросе) представления должны быть обновлены в соответствии с этими строками:

view "internal" {
        match-clients {
                key "internal";
                !key "external";
                ... # existing IP-based matching as it was
        };
        ... # all the other stuff from the view as it was
};

и

view "external" {
        match-clients {
                    key "external";
                    !key "internal";
                    ... # existing IP-based matching as it was
        };
        ... # all the other stuff from the view as it was
};

Таким образом, любые входящие сообщения (запросы / обновления), подписанные одним из этих двух ключей, всегда будут попадать в соответствующее представление, поскольку новые записи сопоставления на основе ключей перечисляются перед любым сопоставлением на основе IP и исчерпывают все возможные комбинации представлений / клавиш в отношении этих ключи.

(Технически в моем предлагаемом решении есть некоторая избыточность, поскольку порядок представлений также является фактором, который можно использовать для исключения некоторых комбинаций представления / клавиш, но я бы рекомендовал явно перечислить все комбинации независимо. Если бы вы переупорядочили представления, я бы не развалился, и я лично также нахожу более ясным, какова реальная цель.)

Источник

nsupdate имеет local подкоманда, которая позволяет вам выбрать адрес источника. Теоретически это позволит вам инициировать обновление внешнего представления из внутренней сети с использованием адреса внешнего источника. На практике ваша политика брандмауэра может предотвратить это.

Источник
Другие вопросы по тегам