Как заставить BIND и Microsoft DNS хорошо работать вместе?

Я хотел бы попытаться перенести как можно больше конфигурации DNS нашей компании в BIND, потому что мне кажется, что с ним легче работать, но наличие Active Directory означает, что мы должны иметь по крайней мере зону домена в Microsoft DNS.

Возможно, я могу иметь зону домена (например, company.local) в MSDNS, но иметь другую зону в BIND (например, company.org), которая имеет прямую и обратную зоны для тех же компьютеров. Сервер DHCP может назначить BIND первичный и вторичный DNS, а мы просто используем эту зону для повседневного использования. Мы также можем создать подчиненные зоны для доменной зоны в BIND, мы просто перенесем все явные операции DNS в BIND, но сохраним доменную зону доступной через BIND, чтобы AD мог функционировать. Кто-нибудь делал это и добился успеха? Или это плохая идея?

Ответ 1

Я не уверен, что рекомендую это делать, но мы это делаем так:

Сервер Solaris под управлением BIND:

1. Работает авторитарно для каждого прямого домена, кроме example.ad

2. Работает авторитетным для каждой зоны in-addr.arpa, кроме тех, которые обслуживаются AD DHCP

3. Извлекает slave для example.ad и диапазонов DHCP с DNS-серверов AD

4. Сервер linux под управлением BIND

5. Тянет slave для example.ad и диапазонов DHCP с серверов AD DNS

6. Тянет slave для всего остального с основного solaris

Серверы AD DNS:

1. Запускает master для example.ad

2. Работает ведущим для любой зоны in-addr.arpa, обслуживаемой AD DHCP

3. Перенаправляет все рекурсивные запросы на установки BIND в Solaris/linux

Клиенты Windows:

1. Назначение серверов AD DNS с помощью AD DHCP. Мы экспериментировали с этим и обнаружили, что «семейству продуктов microsoft», которые мы использовали, не понравилось отсутствие сервера AD DNS. Возможно, мы сдались слишком рано, но, насколько я помню, все прошло не очень хорошо.

UNIX/Linux/операционные клиенты:

1. Жестко закодированные DNS-серверы BIND.

На практике, вот некоторые политики, которые мы ввели:

1. Любая запись, относящаяся к услугам IT-класса (обмен и т. д.), получает запись A в example.ad и CNAME к record.example.ad в example.com.

2. Любая запись, относящаяся к операционному или сетевому оборудованию, получает запись A в example.com и CNAME в example.ad.

Наша настройка на самом деле даже немного сложнее, чем эта, потому что мы приобрели компанию, которая использует Netware/AD для DNS/DHCP, поэтому у нас есть аналогичный набор правил для них.

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

Одна из проблем, с которой мы столкнулись, это кэширование на сервере AD DNS. Мы пытались объяснить нашим операционным клиентам, что их ноутбуки используют AD DNS, но изменения вносятся в BIND, поэтому, если они вносят изменения и хотят проверить их, им приходится вручную искать их на нужных серверах. Это раздражает, но эта проблема возникает на удивление часто.

Надеюсь, это поможет.

Ответ 2

Ключевой проблемой является динамическое обновление DNS в Active Directory, которое он делает для записей A контроллеров домена, записей PTR и самой записи domain.com, плюс подчеркнутые зоны _msdcs.domain.com, _sites.domain.com, _tcp.domain.com, _udp.domain.com.

Если ваша версия BIND может поддерживать эти динамические обновления, вы можете просто использовать BIND. Если нет, то вы должны использовать MS-DNS для зон с подчеркиванием, однако вы можете вручную закодировать записи A, PTR и domain.com самостоятельно и поддерживать их при добавлении/удалении DC. Сделайте MS-DNS авторитетом для зон с подчеркиванием и передавайте/перенаправляйте их в BIND, чтобы клиенты могли их найти. Или используйте другой домен полностью для AD (если можете), например corp.domain.com, разместите его полностью в MS-DNS и передавайте/перенаправляйте его в BIND. Клиентские машины Windows также захотят динамически создавать записи A/PTR, поэтому BIND сам должен сделать это за них или позволить им сделать это, или снова использовать MS-DNS для всей зоны.

Ответ 3

Смешивание Bind и MSDNS довольно хорошо документировано, быстрый поиск привел к http://support.microsoft.com/kb/255913, но, вероятно, там есть еще больше статей.

Вы должны решить, что вам важнее... В предыдущей компании я установил bind для всего, кроме _{msdcs,sites,tcp,udp} и поддомена, где размещались настольные компьютеры, чтобы они могли делать безопасные динамические обновления. Это просто работает (DHCP был на Unix). Смешивание этих двух систем дает дополнительную работу по поддержанию чистоты и актуальности.

Ответ 4

Я уже делал это раньше и попытаюсь восстановить по памяти, что я делал.

Ситуация:

Контроллер домена Win7, различные настольные компьютеры Windows, среда AD. DNS-сервер нужно было перезапускать каждые несколько дней, потому что он просто переставал работать.

Решение:

У меня была Linux-машина в сети, на которой работал небольшой интранет-сайт, поэтому я сбросил BIND на эту машину. Я установил BIND как ведомое устройство в зоне и настроил устройство Win7 на отправку на него доменных трансферов. Затем я настроил DHCP-сервер на Win7-комплексе на то, чтобы BIND-комплекс был первичным DNS-сервером, а Win7-комплекс – вторичным DNS-сервером. Теперь все обновления в таблице DNS на Win7 (включая клиентские блоки, поскольку все они были DHCP) публиковались на BIND-сервере, и все работало отлично. Больше никогда не приходилось перезапускать DNS-сервер Win7.