☰

Bind9: Главный->Подчиненный Уведомление IPv6 с откатом на IPv4

tag-icon • tag-icon bind ipv6 failover
Bind9: Главный->Подчиненный Уведомление IPv6 с откатом на IPv4

У меня настроена небольшая схема DNS Master->Slave между двумя машинами, работающими под управлением Debian 8 + Bind9 в двухстековом IP-адресе.

Ведущее и ведомое устройства владеют IPv4 и IPv6, используемыми привязкой, что определяется параметрами конфигурации listen-on listen-on-v6 transfer-source transfer-source-v6 notify-source notify-source-v6 query-source address query-source-v6 address.

В настоящее время мой мастер настроен на уведомление подчиненного устройства следующим образом:

notify yes;
also-notify { xxxx:xxxx:xxxx:xxxx::xxx5; x.x.x.5; };

Так как у моего подчиненного устройства есть конфигурация зоны, то вот так:

zone "example.dev" {
    type slave;
    masters { xxxx:xxxx:xxxx:xxxx::xxx2; x.x.x.2; };
    file "...";
};

Эта настройка работает нормально, однако, если проверить файлы журналов (и как я и ожидал), то видно, что главный сервер уведомляет подчиненный сервер дважды о каждом изменении зоны:

May 20 20:57:53 salvedns named[8568]: zone example.dev/IN: notify from x.x.x.2#52041: zone is up to date
May 20 20:57:53 salvedns named[8568]: zone example.dev/IN: notify from xxxx:xxxx:xxxx:xxxx::xxx2#51347: zone is up to date

Один раз по IPv4, а другой по IPv6.

Есть ли способ сообщить серверу привязки, что xxxx:xxxx:xxxx:xxxx::xxx5 x.x.x.5это действительно адреса для одного и того же DNS-сервера, и попытаться сначала уведомить его по IPv6, а если это не удастся, повторить попытку по IPv4? Кроме того, как сделать то же самое в mastersобъявлении salve?

Спасибо.

решение1

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

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

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

4.2. Каждый подчиненный, скорее всего, получит несколько копий одного и того же запроса NOTIFY: одну от основного главного устройства и одну от каждого другого подчиненного устройства, когда это подчиненное устройство переносит новую зону и уведомляет своих потенциальных одноранговых пользователей. Протокол NOTIFY поддерживает эту множественность, требуя, чтобы NOTIFY отправлялся подчиненным/главным устройством только ПОСЛЕ того, как оно обновило SOA RR или определило, что обновление не требуется, что на практике означает после успешной передачи зоны. Таким образом, за исключением переупорядочивания доставки, последний NOTIFY, который получает любое подчиненное устройство, будет тем, который указывает на последнее изменение. Поскольку подчиненное устройство всегда запрашивает SOA и AXFR/IXFR только у своих известных главных устройств, у него будет возможность повторить свой ЗАПРОС на SOA после того, как каждое из его главных устройств завершит каждое обновление зоны.

Связанный контент