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

Контроллеры домена как внутренние DNS-серверы

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

Сосредоточившись на моем основном сайте HQ, у меня есть 3 контроллера домена (2 виртуальных, 1 физический), все под управлением Windows Server 2008 R2. Я хочу перейти на Windows Server 2012 R2. Я не верю в «обновление» Windows, я всегда предпочитаю «миграцию», чтобы на серверах и в среде не было артефактов обновления.

Два виртуальных контроллера домена предоставляют все службы DNS для всех моих рабочих станций и рядовых серверов. Рабочие станции получают адреса DNS через параметры DHCP, в то время как все рядовые серверы имеют статические IP-адреса DNS-серверов.

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

Вопрос: Является ли хорошей практикой использование реальных IP-адресов контроллеров домена на рабочих станциях и серверах для преобразователей DNS или мне следует использовать виртуальные IP-адреса / балансировку нагрузки?

Все еще нормально использовать контроллеры домена в качестве преобразователей DNS для всех ваших рабочих станций и серверов, или мне следует создавать новые выделенные DNS-серверы?

У меня более 2000 клиентов в моей компании и 4 контроллера домена. 2 из них также действуют как DNS-серверы без проблем уже 4 года.

Является ли хорошей практикой использовать реальные IP-адреса контроллеров домена на рабочих станциях и серверах для преобразователей DNS или мне следует использовать виртуальные IP-адреса / балансировку нагрузки?

Еще раз, для более чем 2000 клиентов я без проблем использую реальный IP-адрес DNS-преобразователя.

Эти показатели я привожу как своего рода «справочник». В зависимости от вашего количества клиентов нагрузка на DNS может быть выше, и моя топология не может относиться к вам ... Но ИМХО вы можете безопасно использовать DC + DNS

Как заявляет Microsoft:

Чаще всего вы будете устанавливать DNS-серверы на всех контроллерах домена.

Но я позволю вам прочитать полную статью здесь

Использование ваших DC в качестве DNS-серверов вполне разумно. Кроме того, вы не можете действительно скрыть их, поскольку многие вещи требуют прямого общения с ними.

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

Риск безопасности при использовании таких контроллеров домена практически равен нулю.

В качестве центра обработки данных я работаю в компании из списка Fortune 200 в сфере финансовых услуг и около года занимаю должность хост-мастера DNS на предприятии. Раньше мы использовали встроенное решение Microsoft DNS (и F5 LTM для произвольного IP-преобразования адреса преобразователя и сервера имен в SOA), которое работает, но мы решили, что оно не оптимально для наших целей.

Указывает в его пользу

  • Бесплатно как часть Active Directory
  • Работает достаточно хорошо для базового использования
  • Автоматическая регистрация DNS-записей для DHCP-клиентов (если клиенты были клиентами Windows; Mac, Linux и SunOS, не так много)

Причины, по которым нам нужно больше

  • Стремясь быть разрешительным, он не строго следует спецификации, допуская неправильную или даже невозможную информацию (включая CNAME в зоне-вершине, для которой был предложен неутвержденный RFC, но, что гораздо хуже, записи с пробелами в любом имя-записи или значение-ответа, что чертовски сбивает с толку все, что связано с BIND)
  • Механизма для синхронизации связанных записей A, TXT, SRV, PTR было недостаточно, и мы потратили значительное время на согласование вручную
  • Интегрированный демон DHCP требовал разделения области действия для HA, что означает, что в случае сбоя половина доступного пула теряется, а не стандартная дорожка (и используется в решениях на основе ISC).https://kb.isc.org/article/AA-00502/0/A-Basic-Guide-to-Configuring-DHCP-Failover.html)
  • Не было готового механизма для простой визуализации исчерпания / доступности / плотности IP-адресов на основе записей PTR.

Мы завершили реализацию интегрированного решения высшего уровня DHCP + DNS + IPAM и не оглядывались назад (включая выполнение динамической синхронизации зон и IP Anycast).

Конечно, есть предостережение: регистрация SRV-записи должна работать для Active Directory Service Discovery, а регистрация и отмена регистрации Windows Cluster Server - работать. вы должны создать ACL, содержащий все контроллеры домена и блоки MS Cluster Server, и разрешить им выполнять динамические обновления DNS. Чтобы обеспечить целостность и работоспособность данных для всех других хостов и всех других записей, вы должны разрешить им обновление только через демон DHCP или через графический интерфейс / API (другими словами, запретить динамическое обновление DNS и AXFR для всех ящиков, не внесенных в белый список). ).