Добавка


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

Сталкиваюсь до сих пор, что средний сетевик или другой повелитель DNS проверяет всякое используя nslookup или dig, в зависимости от вероисповедания, и не знает о таких штуках. Хочется поэтому рассказать о них, и побудить читателя ими попользоваться.

Крайне полезны такие сервисы, когда вы определяете жалобы пользователей на скорость работы О365. Еще полезней они если вы прогоните такие и подобные тесты до побега в облако, ибо на форумах технета даже в русскоязычном сегменте я с подобными вещами сталкивался, что уж говорить о других, где облака прочно и давно обосновались. Щупаем, привыкаем, используем. На сегодня все. Будьте здоровы.

 

 

 

 

DNS Best Practices


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

Установка и настройка DNS на Windows Server

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

Оригинал статьи на технете

PrerequisitesSection_image001

Как предотвратить регистрацию DNS записей для контроллеров домена в филиале?


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

Для того чтобы клиентам, не имеющим возможности подключиться к своему контроллеру  возвращались только записи контроллеров домена в центральных сайтах, необходимо настроить контроллеры домена в филиалах для регистрации записей DNS, относящихся к конкретному сайту.Чтобы выполнить это изменение, нам нужно будет изменить редактором  групповой политики объект Default Domain Controllers, и включить параметр “DC Locator DNS records not registered by the DomainControllers” по пути: Computer Configuration, Administrative Templates, System, Net Logon, DC Locator DNS Records и выполнить следующее изменение:

LdapIpAddress Ldap Gc GcIPAddress Kdc Dc DcByGuid Rfc1510Kdc Rfc1510Kpwd Rfc1510UdpKdc Rfc1510UdpKpwd GenericGc

Эти параметры подробно объяснены в “Windows Server 2003 Active Directory Branch Office Guide,” но по сути, они предотвращают регистрацию всех записей контроллеров домена, кроме записей, относящихся к сайту. Проблема в том, что данная настройка повлияет на все контроллеры домена, поэтому гораздо лучше будет изменить параметр HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNS\Parameters\DnsAvoidRegisterRecords на нужном контроллере. Можно включить эти же параметры, включив в групповой политике  настройку  “DC Locator DNS records not registered by the DCs” .

После применения этих изменений, общее пространство DNS имен (например, _ldap._tcp.) должно содержать SRV записи только для контроллеров, к которым не было применено ручное изменение реестра.

Подробности – в библиотеке Technet.

Предоставление клиентам возможности искать контроллер домена в следующем ближайшем сайте