Top 10 DNS Best Practices

Top 10 DNS Best Practices

Очень часто встречаются ситуации, когда начинающие администраторы (хотя я встречал и начинающих архитекторов) не могут правильно сконфигурировать настройки DNS, или не понимают фундаментальных основ. Эта короткая статья написана как сборник рекомендаций, которые помогут правильно настроить клиентские настройки DNS на контроллере домена без вопиющих ошибок, рекомендаций подобного рода можно встретить много, но они достаточно устарели, и не совсем понятно, можно ли их использовать.

1. Если на контроллере домена установлен сервис DNS, то настройки клиента должны указывать на IP адрес самого сервера, и, как минимум, на какой-нибудь дополнительный DNS сервер. (см ниже)

2. На контроллере домена настройки клиента DNS должны указывать на другой сервер (партнер) как первичный, и на самого себя второй или третьей записью.

3. Когда мы говорим о настройке на самого себя, петлевой (loopback address) не должен быть настроен первым, только вторым или третьим адресом.

Примечание: обратите внимание на п.2 и п.3- здесь мы обсуждаем разные подходы к настройке. Я склоняюсь к третьему варианту, ибо считаю, что  проблемы островов и производительности серверов DNS уже в далеком прошлом, но иногда Вам может потребоваться конфигурация п.2 – все зависит от требований и обстоятельств.

4. В настройках клиентов никогда не должны фигурировать внешние DNS адреса, если только вы не работаете в google, тогда смело можете конфигурировать клиентские рабочие станции настройками вида 8.8.8.8. Если же это так, то при такой настройке ваши рабочие станции(или серверы) будут дружно пытаться найти сервер dc01.myfirma.ru по адресу, указанному выше, и, разумеется, не найдут его там. Итог такой настройки- таймауты и ошибки в доменной среде. Итоговое значение- клиенты должны использовать внутренние адреса ваших контроллеров.

5. Все внешние адреса могут присутствовать только в одном месте: это вкладка пересылка (forwarders) в настройках сервера DNS. Все адреса, которые сервер (или клиент) не разрешил, будут запрошены у серверов(провайдера), которые указаны на этой вкладке, либо, если эта вкладка не сконфигурирована,  запрос пойдет к корневым серверам интернета, что с точки зрения клиента одно и то же.

6. Все контроллеры домена должны держать как минимум зону своего домена, и все контроллеры в лесу должны держать зону _MSDCS. Это значение по умолчанию, начиная с Windows 2003 и более поздних версий, и эта настройка должна оставаться без изменений.

7. Клиенты должны получать настройки минимум двух DNS серверов посредством DHCP сервера, скриптов, групповых политик- как угодно, но только так, во избежание ошибок администратора и некорректной ручной конфигурации. При такой настройке вы выравниваете клиентов по подсетям и конкретным DNS серверам, при настройке локального контроллера домена разрешение имен в удаленном офисе будет продолжать работать, даже если WAN канал будет недоступен.

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

9. Используйте Best Practices Analyzer для проверки правильности ваших настроек; постарайтесь не использовать multihomed контроллеры домена- при настройке такого контроллера легко запутаться и допустить ошибку при настройке или использовании. Основная рекомендация здесь- постараться отказаться от использования подобной конфигурации. Если же Вы все же используете такую конфигурацию, не забудьте изменить порядок приоритета сетевых адаптеров: Выполните ncpa.cpl-alt-Дополнительно-Дополнительные параметры. Убедитесь, что на вкладке "Адаптеры и привязки" адаптер, смотрящий в  доменную локальную сеть идет первым в списке.

10.  Не забывайте про защиту критически важного сетевого компонента организации - трафика DNS, используйте для этого
DNSSec.
http://technet.microsoft.com/ru-ru/library/hh831411.aspx

Справочная документация, рекомендуемая к ознакомлению:

Windows Server 2008 R2 BPA for DNS

DNS Namespace Planning Solution Center
http://support.microsoft.com/namespace

Creating a DNS Infrastructure Design
http://technet.microsoft.com/ru-ru/library/cc725625(WS.10).aspx

DNS Portal
http://technet.microsoft.com/ru-ru/network/bb629410.aspx

Сортировать по: Дата публикации | Последние | Самый полезный
Комментарии
  • Спасибо! Все четко и по делу. Опишите пожалуйста ситуацию с 7м пунктом более подробно, а именно "... при настройке локального контроллера домена разрешение имен в удаленном офисе будет продолжать работать, даже если WAN канал будет недоступен" Вы имеете ввиду локальный кеш запросов на удаленном доменном контроллере?

  • Имеется ввиду цитата

    "при настройке локального контроллера домена разрешение имен в удаленном офисе будет продолжать работать, даже если WAN канал будет недоступен."

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

  • Если вы поднимите любой мало-мальский даже кеширующий сервер (неважно на какой платформе) - то во-первых сэкономите WAN канал - банально быстрее будет работать разрешение имен- ну и стабильность, линк лежит а в кеше есть записи, которые клиенты могут быстро забирать.Дилемма всегда только в том, нужно или нет ставить сервер в офис, но это уже тема для отдельной статьи )

  • 2Антон-

    При настройке DNS и создании зон, выбрать переключатель

    (использовать только безопасные  обновления\ репликацию).

    Но как правило нужно планировать структуру DNS \AD DNS.

    Мне кажется, Вы забываете здесь, что это

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

  • "ncpa.cpl-alt-Дополнительно-Дополнительные параметры"

    Полагаю, нужно использовать английские ("родные") названия, прийти к единой форме описания операций и давать русскую операционную форму отдельно (допустим, в скобках).

Страница 1 из 1 (элементов: 5)