У меня есть небольшая настройка схемы 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 декларация?
Спасибо.
Я не верю, что есть вариант конфигурации, который сделает то, о чем вы просите. Однако я также не верю, что двойные уведомления действительно вызывают беспокойство.
Хотя в этой конфигурации он избыточен, накладные расходы, к которым он приводит, минимальны и обычно не вызывают никаких проблем.
Вообще говоря, получение нескольких уведомляющих сообщений не выходит за рамки нормы, первоначально в основном от главного + других подчиненных, но теперь также и с двухстековых хостов, до такой степени, что даже исходная спецификация ожидала этого:
4.2. Каждое ведомое устройство, вероятно, получит несколько копий одного и того же запроса NOTIFY: одну от основного ведущего и по одной от каждого другого ведомого, поскольку это ведомое устройство передает новую зону и уведомляет своих потенциальных партнеров. Протокол NOTIFY поддерживает эту множественность, требуя, чтобы NOTIFY отправлялся подчиненным / главным устройством только ПОСЛЕ того, как он обновил SOA RR или определил, что обновление не требуется, что на практике означает после успешной передачи зоны. Таким образом, если запретить переупорядочивание доставки, последнее сообщение NOTIFY, которое получит любой ведомый, будет тем, которое указывает на последнее изменение. Поскольку ведомое устройство всегда запрашивает SOA и AXFR / IXFR только у своих известных мастеров, у него будет возможность повторить свой ЗАПРОС для SOA после того, как каждый из его мастеров завершит каждое обновление зоны.