DNS: 2 master сервера для одной зоны

сделать dlz с зонами в SQL и добавлять записи сразу в бд.

http://jpmens.net/2010/10/21/using-binds-statistics-server-to-list-zones-and-...

http://jpmens.net/2013/03/01/processing-bind-s-xml-statistics-with-xsl/

Юзая интерфейс статистики BIND'a можно синхронизировать всё что угодно без всяких SQL.

http://www.zytrax.com/books/dns/ch7/xfer.html

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

PS: Один из серверов это связка cobbler 2.4 + puppet3 + bind9 на rhel6 based дистрибутиве.

понял, что это не то, что нужно

понял, что это не то, что нужно

А что именно не устраивает? На первый взгляд там есть все, что нужно: можно указать куда слать и откуда принимать уведомления. Да и опция multi-master есть.

Как сделать так, чтобы клиенты видели записи на 2 днс?

Это 2 одинаковых мастер-сервера или зоны на самом деле немного разные должны быть? Если одинаковые, то самое простое,доступное и понятное, к тому же идеально ложащееся на структуру LDAP - это использовать BIND+OpenLDAP либо PowerDNS+OpenLDAP. Тогда Вы можете прицепить DNS-сервера к одному LDAP-серверу (решение «не очень»), либо реплицировать OpenLDAP-каталог в режиме зеркала (формально это hot-standby, фактически упрощённый вариант мультимастера).

Это 2 одинаковых мастер-сервера или зоны на самом деле немного разные должны быть?

ТС просто очень общЁ поставил задачу. В реальности есть некоторая виртуалку с предустановленной samba4 и какой-то гуевой утилиткой, через которую управляются виндовые машины. На залезть туда и что-то поправить ниукого компетенции не хватит. Если DNS-ом рулить только ей, то все замечательно.

Сейчас собирается виртуалку со связкой cobbler + puppet для управления некторой частью linux машин. Если рулить DNS-ом только им, то тоже все замечательно. Здесь правда чуть большая свобда действий. Скажем подложить скриптик, который дергается по cobbler sync проблем нет. Дописывать дополнительные записи в шаблон cobbler'а шаблоном puppet'а тоже. Правда он предполагается неустойчивым (покрайней мере пока)

Таким образом задача стоит администрировать одну часть записей в домене ourdep.local из puppet-а через cobbler, а вторую из черного ящика c samba4

Мда. А зачем было городить столько сущностей, тем более если в той же Samba4 не разбираетесь?
Ну OK, а вариант засасывать LDAP-записи из встроенного в Samba4 LDAP-сервера не подходит наверное потому, что опять же ничего о LDAP не знаете...
В качестве некоей полезной подсказки:
а) PowerDNS может форвардить зону на опред. вышестоящий сервер
б) Если зона прописана на самом PowerDNS (он авторитативен для неё), но при этом есть и настройка forward'а этой зоны вышестоящему серверу...
в) То... описание зоны на PowerDNS «дополняется» зоной на вышестоящем сервере.
Это очень простая для понимания и очень удобная на практике вещь отсутствует напрочь в погрязшем в бездумном следовании RFC сервере BIND.
При этом именно «дополнение» зоны позволяет легко и просто добиться того, чего в BIND'е нереально: часть зоны (только LAN) можно хранить на одном сервере DNS, а другую часть (только внешние адреса) - на другом. Сравните это с маразмом ISC, где вы просто обязаны поддерживать полностью «Internal View» и «External View», даже если эти Internal с External'ом на 98% совпадают!! (второй вариант с высасыванием из пальца внутреннего названия зоны специально для LAN я даже рассматривать не буду - это феерический идиотизм за гранью добра и зла).

Мда. А зачем было городить столько сущностей, тем более если в той же Samba4 не разбираетесь?

Ну сущностей здесь всего ничего.

Почему для samba4 была выбрана именно та виртуалка с предустановленной самбой это вопрос к ТС, я этим не занимаюсь.

Про puppet: Контора занимается разработкой нескольких продуктов под linux на j2ee. Eсть стенд, на котором должны демонстрироваться продукты и есть виртуалки для тестирования. Вот чтобы не мучиться по пол для со сборкой стенда вполне разумным кажется написать несколько модулей для puppet, запихнуть описание нодов под mercurial и наслаждаться полной переустановкой нажатием пары клавиш. Плюс к тому через него можно уже после установки вносить мелкие изменения, и все ходы будут записаны. Да и элементарных удобств хочется: ssh по хостнейму куда приятнее чем по ip.

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

Ну и фразу «для управления некоторой частью linux машин» следует понимать, что оставшаяся будут администрироваться методом «собрать что-нибудь на коленке».

Ну OK, а вариант засасывать LDAP-записи из встроенного в Samba4 LDAP-сервера не подходит наверное потому, что опять же ничего о LDAP не знаете...

Ну если бы не было более простых решений, шаблон на для puppet'а, который это делает я бы осилил. Там же доступен вполне полноценный Ruby.

Это очень простая для понимания и очень удобная на практике вещь отсутствует напрочь в погрязшем в бездумном следовании RFC сервере BIND.

Вот это первое, что было попробовано :)

Вот это первое, что было попробовано :)

BIND очень не любит следовать принципу бритвы Окама («не плоди новых сущностей без веской на то причины») и принципу KISS («делай это проще, придурок»), поэтому даже реализация хранения зоны в LDAP него сделана настолько через Ж.,что ничего кроме брезгливости и отвращения не вызывает (они просто запихнули в LDAP файловое описание зоны) - в том же AD сделано и то лучше , хотя обязательное разделение на прямую и обратную зоны, даже в распространённом случае, когда одна является точным отражением другой, и там обязательно. Я советую PowerDNS: здесь простые конфиги «var = val» без всяких секций с подробно описанными в документации и в самом файле переменными, полная обратная совместимость с файлами зон для BIND'а, плюс простота в типичном UNIX-style'е: если технически это возможно, значит - это возможно и фактически, никаких высосанных из пальца ограничений при максимуме функциональности. Плюс конечно разделение DNS-сервера на атомарный и фантастически быстрый recursor и собственно авторитативный сервер зоны - на мой взгляд концептуально верно и позволяет избежать типичных проблем мега-гипер-«комбайна» (читаешь конфиг BIND'а и не понимаешь, а какую же роль он в итоге выполняет в данной конфигурации).