Назад | Перейти на главную страницу

реплицированные с несколькими мастерами динамические поддомены DNS

За неимением лучшего названия. В нашей среде требуются поддомены, в которых мы разрешаем динамические обновления с использованием bind в качестве DNS-сервера и его утилиты nsupdate, аутентифицирующей себя с помощью файлов ключей. Мы хотим сделать это более избыточным. В настоящее время у нас есть один первичный сервер имен для всех этих поддоменов и несколько вторичных серверов для нашего домена верхнего уровня (но не для поддоменов). В качестве примера используется bar.com в качестве TLD и foo.bar.com в качестве поддомена. В файле зоны поддомена foo.bar.com будут записи, похожие на:

        NS      ns1.bar.com
        A       1.2.3.4
        MX      mx1.bar.com
 www    A       1.2.3.5

...

а в файле первичной зоны будут записи для 'foo', например:

foo NS ns1.bar.com

В настоящее время поддомены не реплицируются на другие серверы имен, т.е. ns1 - единственный сервер имен, который может их разрешить, даже если ns2, ns3 и т. Д. настроены как вторичные для домена bar.com. Есть идеи, как это настроить более надежным способом? Если связующая запись в файле зоны bar.com была удалена и несколько записей NS были настроены в каждом поддомене (и настроены как подчиненные на вторичных серверах имен), это помогло бы разрешить домены, но не помогло бы с предоставлением альтернативного Сервер обновления, если необходимо обновить поддомен. Если в этом примере ns1 не работает, как разрешить клиентам nsupdate обновить свою зону и реплицировать ее на другие серверы имен, а также когда ns1 вернется в режим онлайн? Возможно ли это вообще с Bind?

BIND9 (опять же - с соответствующими патчами) может использовать базу данных LDAP в качестве бэкэнда. Fedora и RHEL 6.4+ содержат исправленный BIND с поддержкой LDAP, если вы хотите его попробовать.

Возможна работа с несколькими мастерами с бэкэндом LDAP, каждый главный сервер DNS считает свой серийный номер и объявляет себя главным (в имени главного сервера SOA), поэтому обновления от клиентов распространяются на все серверы. В этом случае репликация данных выполняется на уровне LDAP.

Описанный multi-master DNS используется в проекте FreeIPA. FreeIPA может настроить для вас реплицированную среду LDAP. (Интегрированный / реплицированный / мультимастер DNS поставляется с FreeIPA в качестве бонуса, основное внимание FreeIPA уделяется управлению идентификацией.)

Домашняя страница FreeIPA: http://freeipa.org/

Сам бэкэнд LDAP можно найти по адресу https://fedorahosted.org/bind-dyndb-ldap/ Патч с «интерфейсом» для BIND9 можно найти по адресу: https://github.com/mnagy/bind-dynamic_db/downloads

Возможно, это поможет - BIND может использовать MySQL в качестве бэкэнда (вам, возможно, придется перекомпилировать его с включенной правильной опцией), а у MySQL есть версия Cluster (тоже бесплатная), которая является своего рода мульти-мастером. Возможно, его можно объединить вместе для достижения ваших нужд ... также есть PowerDNS, который также может использовать SQL в качестве бэкэнда.

В протоколе DNS (не говоря уже о BIND) нет механизма, позволяющего объединять динамические обновления, полученные на разных «мастерах», и реплицировать их на несколько подчиненных (и на первичный «мастер», когда он появляется).

Вы должны либо придерживаться поддерживаемой модели «один главный, несколько вторичных» с динамическими обновлениями и IXFR, либо использовать некоторую форму внеполосного механизма для обновления всех ваших серверов.