Что такое msdcs dns

Обновлено: 06.07.2024

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

Сервис в современных сетях если не ключевой, то один из таковых. Те, для кого служба DNS — не нова, первую часть могут спокойно пропустить.

Содержание:

(анкеров нет, поэтому содержание без ссылок)

1. Основные сведения

DNS — это база данных, содержащая, в основном, информацию о сопоставлении имён сетевых объектов их IP-адресам. «В основном» — потому что там и ещё кое-какая информация хранится. А точнее, ресурсные записи (Resource Records — RR) следующих типов:

А — то самое сопоставление символьного имени домена его IP адресу.

АААА — то же что А, но для адресов IPv6.

CNAME — Canonical NAME — псевдоним. Если надо чтобы сервер с неудобочитаемым именем, типа nsk-dc2-0704-ibm, на котором вертится корпоративный портал, откликался также на имя portal, можно создать для него ещё одну запись типа А, с именем portal и таким же IP-адресом. Но тогда, в случае смены IP адреса (всякое бывает), нужно будет пересоздавать все подобные записи заново. А если сделать CNAME с именем portal, указывающий на nsk-dc2-0704-ibm, то ничего менять не придётся.

MX — Mail eXchanger — указатель на почтовый обменник. Как и CNAME, представляет собой символьный указатель на уже имеющуюся запись типа A, но кроме имени содержит также приоритет. MX-записей может быть несколько для одного почтового домена, но в первую очередь почта будет отправляться на тот сервер, для которого указано меньшее значение в поле приоритета. В случае его недоступности — на следующий сервер и т.д.

NS — Name Server — содержит имя DNS-сервера, ответственного за данный домен. Естественно для каждой записи типа NS должна быть соответствующая запись типа А.

SOA — Start of Authority — указывает на каком из NS-серверов хранится эталонная информация о данном домене, контактную информацию лица, ответственного за зону, тайминги хранения информации в кэше.

SRV — указатель на сервер, держатель какого-либо сервиса (используется для сервисов AD и, например, для Jabber). Помимо имени сервера содержит такие поля как Priority (приоритет) — аналогичен такому же у MX, Weight (вес) — используется для балансировки нагрузки между серверами с одинаковым приоритетом — клиенты выбирают сервер случайным образом с вероятностью на основе веса и Port Number — номер порта, на котором сервис «слушает» запросы.

Все вышеперечисленные типы записей встречаются в зоне прямого просмотра (forward lookup zone) DNS. Есть ещё зона обратного просмотра (reverse lookup zone) — там хранятся записи типа PTR — PoinTeR — запись противоположная типу A. Хранит сопоставление IP-адреса его символьному имени. Нужна для обработки обратных запросов — определении имени хоста по его IP-адресу. Не требуется для функционирования DNS, но нужна для различных диагностических утилит, а также для некоторых видов антиспам-защиты в почтовых сервисах.

Кроме того, сами зоны, хранящие в себе информацию о домене, бывают двух типов (классически):

Основная (primary) — представляет собой текстовый файл, содержащий информацию о хостах и сервисах домена. Файл можно редактировать.

Дополнительная (secondary) — тоже текстовый файл, но, в отличие от основной, редактированию не подлежит. Стягивается автоматически с сервера, хранящего основную зону. Увеличивает доступность и надёжность.

Для регистрации домена в интернет, надо чтоб информацию о нём хранили, минимум, два DNS-сервера.

В Windows 2000 появился такой тип зоны как интегрированная в AD — зона хранится не в текстовом файле, а в базе данных AD, что позволяет ей реплицироваться на другие контроллеры доменов вместе с AD, используя её механизмы репликации. Основным плюсом данного варианта является возможность реализации безопасной динамической регистрации в DNS. То есть записи о себе могут создать только компьютеры — члены домена.

В Windows 2003 появилась также stub-зона — зона-заглушка. Она хранит информацию только о DNS-серверах, являющихся полномочными для данного домена. То есть, NS-записи. Что похоже по смыслу на условную пересылку (conditional forwarding), которая появилась в этой же версии Windows Server, но список серверов, на который пересылаются запросы, обновляется автоматически.

Итеративный и рекурсивный запросы.

DNS-сервер обращается к одному из корневых серверов интернета, которые хранят информацию о полномочных держателях доменов первого уровня или зон (ru, org, com и т.д.). Полученный адрес полномочного сервера он сообщает клиенту.

Клиент обращается к держателю зоны ru с тем же запросом.

DNS яндекса возвращает нужный адрес.

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

Клиент, как правило, обращается с запросом, имеющим флаг «требуется рекурсия».

Заголовок состоит из следующих полей:

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

Флаги — 16-битовое поле, поделенное на 8 частей:

Вторая строка — ответ сервера: на указанный исходный порт с указанным идентификатором запроса. Ответ содержит одну RR (ресурсную запись DNS), являющуюся ответом на запрос, 2 записи полномочий и 5 каких-то дополнительных записей. Общая длина ответа — 196 байт.

3. TCP и UDP

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

4. DNS в Windows Server 2008 и 2012

В Windows 2008 появились следующие возможности:

Фоновая загрузка зон

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

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

Поддержка IPv6-адресов

Протокол Интернета версии 6 (IPv6) определяет адреса, длина которых составляет 128 бит, в отличие от адресов IP версии 4 (IPv4), длина которых составляет 32 бита.
DNS-серверы с ОС Windows Server 2008 теперь полностью поддерживают как IPv4-адреса, так и IPv6-адреса. Средство командной строки dnscmd также принимает адреса в обоих форматах. Cписок серверов пересылки может содержать и IPv4-адреса, и IPv6-адреса. DHCP-клиенты также могут регистрировать IPv6-адреса наряду с IPv4-адресами (или вместо них). Наконец, DNS-серверы теперь поддерживают пространство имен домена ip6.arpa для обратного сопоставления.

Изменения DNS-клиента

Разрешение имен LLMNR
Клиентские компьютеры DNS могут использовать разрешение имен LLMNR (Link-local Multicast Name Resolution), которое также называют многоадресной системой DNS или mDNS, для разрешения имен в сегменте локальной сети, где недоступен DNS-сервер. Например, при изоляции подсети от всех DNS-серверов в сети из-за сбоя в работе маршрутизатора клиенты в этой подсети, поддерживающие разрешение имен LLMNR, по-прежнему могут разрешать имена с помощью одноранговой схемы до восстановления соединения с сетью.
Кроме разрешения имен в случае сбоя в работе сети функция LLMNR может также оказаться полезной при развертывании одноранговых сетей, например, в залах ожидания аэропортов.

Изменения Windows 2012 в части DNS коснулись, преимущественно, технологии DNSSEC (обеспечение безопасности DNS за счет добавления цифровых подписей к записям DNS), в частности — обеспечение динамических обновлений, которые были недоступны, при включении DNSSEC в Windows Server 2008.

5. DNS и Active directory

Active Directory очень сильно опирается в своей деятельности на DNS. С его помощью контроллеры домена ищут друг друга для репликации. С его помощью (и службы Netlogon) клиенты определяют контроллеры домена для авторизации.

Для обеспечения поиска, в процессе поднятия на сервере роли контроллера домена, его служба Netlogon регистрирует в DNS соответствующие A и SRV записи.

SRV записи регистрируемые службой Net Logon:

_ldap._tcp.DnsDomainName
_ldap._tcp.SiteName._sites.DnsDomainName
_ldap._tcp.dc._msdcs.DnsDomainName
_ldap._tcp.SiteName._sites.dc._msdcs.DnsDomainName
_ldap._tcp.pdc._msdcs.DnsDomainName
_ldap._tcp.gc._msdcs.DnsForestName
_ldap._tcp.SiteName._sites.gc._msdcs. DnsForestName
_gc._tcp.DnsForestName
_gc._tcp.SiteName._sites.DnsForestName
_ldap._tcp.DomainGuid.domains._msdcs.DnsForestName
_kerberos._tcp.DnsDomainName.
_kerberos._udp.DnsDomainName
_kerberos._tcp.SiteName._sites.DnsDomainName
_kerberos._tcp.dc._msdcs.DnsDomainName
_kerberos.tcp.SiteName._sites.dc._msdcs.DnsDomainName
_kpasswd._tcp.DnsDomainName
_kpasswd._udp.DnsDomainName

Первая часть SRV-записи идентифицирует службу, на которую указывает запись SRV. Существуют следующие службы:

_ldap — Active Directory является службой каталога, совместимой с LDAP-протоколом, с контроллерами домена, функционирующими как LDAP-серверы. Записи _ldap SRV идентифицирует LDAP серверы, имеющиеся в сети. Эти серверы могут быть контроллерами домена Windows Server 2000+ или другими LDAP-серверами;

_kerberos — SRV-записи _kerberos идентифицируют все ключевые центры распределения (KDC — Key Distribution Centers) в сети. Они могут быть контроллерами домена с Windows Server 2003 или другими KDC-серверами;

_kpassword — идентифицирует серверы изменения паролей kerberos в сети;

_gc — запись, относящаяся к функции глобального каталога в Active Directory.

В поддомене _mcdcs регистрируются только контроллеры домена Microsoft Windows Server. Они делают и основные записи и записи в данном поддомене. Не-Microsoft-службы делают только основные записи.

Записи, содержащие идентификатор сайта SiteName, нужны для того чтобы клиент мог найти контроллер домена для авторизации в своём сайте, а не лез авторизовываться в другой город через медленные каналы.

DomainGuid — глобальный идентификатор домена. Запись, содержащщая его, нужна на случай переименования домена.

Как происходит процесс поиска DC

Во время входа пользователя, клиент инициирует DNS-локатор, при помощи удалённого вызова процедуры (Remote Procedure Call — RPC) службой NetLogon. В качестве исходных данных в процедуру передаются имя компьютера, название домена и сайта.

Служба посылает один или несколько запросов с помощью API функции DsGetDcName()

DNS сервер возвращает запрошенный список серверов, рассортированный согласно приоритету и весу. Затем клиент посылает LDAP запрос, используя UDP-порт 389 по каждому из адресов записи в том порядке, как они были возвращены.

Все доступные контроллеры доменов отвечают на этот запрос, сообщая о своей работоспособности.

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

Служба Netlogon кэширует информацию о местонахождении контроллера домена, чтобы не инициировать всю процедуру при каждой необходимости обращения к DC. Однако, если используется «неоптимальный» DC (расположенный в другом сайте), клиент очищает этот кэш через 15 минут и инициирует поиски заново (в попытке найти свой оптимальный контроллер).

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

Пример: Dnscmd /Config /LocalNetPriorityNetMask 0x0000003F укажет маску подсети 255.255.255.192 для приоритетных DC. По умолчанию используется маска 255.255.255.0 (0x000000FF)

Сравнительно недавно случайно заметил, что на рабочих серверах DNS отсутствует зона _msdcs.ForestName. Каких-либо жалоб со стороны пользователей не было , как и не было проблем с доступностью сервисов домена. Поскольку эта зона выполняет достаточно важные функции для работы всего леса AD, я стал разбираться что же с ней не так.

Если вам интересна тематика Windows Server, рекомендую обратиться к рубрике Windows Server на моем блоге.

Назначение зоны _msdcs.ForestName

Главным образом эта зона предназначена для определения расположения ключевых сервисов AD DS, таких как Глобальный каталог (см. Global catalog — Глобальный каталог), PDC (см. PDC emulator — Эмулятор первичного контроллера домена), Kerberos, LDAP, а также для определения GUID контроллеров домена AD (по записи GUID клиенты найдут контроллеры домена в случае переименования домена). В этой области каждый контроллер домена регистрирует SRV-записи собственных служб и отвечает за этот процесс служба Netlogon. Сама область является частью компонента Domain controller locator (Locator) 1 , внедренного в Windows Server 2003:

The Microsoft-specific subdomain enables location of domain controllers that have specific roles in the Active Directory domain or forest. Resource records for the DNS root domain of a new Active Directory forest are stored in a _msdcs zone instead of a subdomain, and that zone is stored in the forest-wide application directory partition.

Дело в том, что в норме для версий Windows Server 2003 и старше эта зона должна располагаться на том же уровне, что и зона корневого домена. Выглядит это примерно так (пример с моей тестовой инфраструктуры):

Но на серверах DNS в продакшене она являлась поддоменом корневого домена и отсутствовала на уровне раздела леса:

На самом деле в этом нет ничего плохого, поскольку во всем лесу у меня существует лишь один домен, но если доменов будет больше, это может вызвать проблемы. В BPA (Best Practices Analyzer) при этом вылезали ошибки отсутствия зоны (скриншоты для Windows Server 2012 R2 и 2008 R2 соответственно):

Почему так произошло? Дело в том, что в версиях Windows Server старше 2003 все устроено несколько иным образом и зона _msdcs действительно должна находиться на уровне поддомена корневого домена AD и при миграции с 2000 на 2003 должна быть перенастроена. По крайней мере это единственная известная мне причина 2 .

Пришло время все привести к тому виду, в котором оно и должно быть.

Перенастройка зоны _msdcs.ForestName

Начать необходимо с создания зоны прямого просмотра с нужным нам именем (нужны права администратора предприятия). Подробно весь процесс расписан на скриншотах ниже:

После того как зона создана, необходимо зайти в её свойства и добавить серверы DNS, которые будут обслуживать эту зоны:

Также вместо существовавшей зоны _msdcs на уровне поддомена должна появиться запись делегирования. У меня это произошло без моего участия, но если вдруг у вас эта зона автоматически не создалась (у меня так было на тестовой инфраструктуре. Возможно из-за нехватки терпения), можно её создать вручную. Для этого:

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

Давайте теперь пройдемся по его настройкам и в конце посмотрим способы проверки его работоспособности.

Заходим в Пуск/Программы/Администрирование и открываем консоль DNS. Смотрите рисунок 1.

Открытая консоль DNS сервера которого мы настраивали в предыдущей теме показана на рисунке 2.

Если копнуть еще глубже, смотрите рисунок 3, то у нас еще создаются такие каталоги как DomainDnsZones и ForestDnsZones.

Акцентирую, эти каталоги создаются в Active Directory при установки DNS интегрированного с Active Directory. И данные каталоги хранятся в разделе приложений Active Directory. Это не совсем понятно на этом рисунке и это можно удивить через оснастку "ADSF Edit", и приведена на рисунке 4 в основном для любознательных. Пока просто запомните что эти два каталога DomainDnsZones и ForestDnsZones хранятся в разделе приложений в Active Directory. Мы еще к обсуждению этих понятий вернемся.

Зачем я затронул эти два раздела как DomainDnsZones и ForestDnsZones? Да потому что каждый из них связан со своим видом репликации, то есть распространяется каждый раздел по своему. Сейчас поймете.

Хотя мы уже установили наши зоны прямого просмотра в прошлой статье мы можем потом вернутся и или проверить или что либо изменить в конфигурации этих зон.

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

В этом контекстном меню выбираем "Свойства" и нам откроется картина показанная на рисунке 6.

Из рисунка 6 мы видим 6 вкладок. Пройдемся по ними. На вкладке "Общее"показанная на рисунке 6 мы видим что наша DNS зона работает и это видно возле надписи "Состояние", рядом стоит кнопка "Пауза", и что она делает думаю что объяснять не стоит.

Чуть ниже стоит надпись "Тип" и рядом описывается тип нашей зоны. В нашем случае она интегрирована в AD. Если нам нужно поменять тип зоны то мы жмем кнопку "Изменить", и перед нами появляется картина показанная на рисунке 7.

В открывшимся окне нам предлагается выбрать тип зоны в зависимости от того что нам требуется и показаны типы зон. О типах зон мы уже говорили в прошлых темах поэтому считаю что вы это знаете, а если хотите вспомнить смотрите здесь. Так же здесь мы можем указать что зону надо хранить в Active Directory или нет.

Идем дальше. тут же на этой вкладке "Общее" (рис 6) мы можем изменить область репликации. Если нажмем на кнопку "Изменит" появится такое окно показанная на рисунке 8.

Здесь мы должны выбрать то что нам нужно. Но изменение области репликации возможно лишь в том случае если зона интегрирована в Active Directory. В противном случае у нас такой возможности не будет.

Так вот что бы не забыть совсем, хочу вернутся к нашим двум зонам который создал Мастеру установки Active Directory и показать в чем их разница.

Так, после того как мы поиграли в "найди различие". тут мы слегка еще остановимся и необходимо обсудить область распространения содержимого зон. Перечень значений и как их надо понимать приведено в таблице показанной на рисунке 11.

Хочется отметить, а вам желательно запомнить что - раздел приложений Active Directory для DNS создается только в том случае, если мы устанавливаем первый контролер домена в новом лесу с установкой соответственно и интегрированного а AD DNS сервера.

Если вы хотите воспользоваться преимуществами раздела приложений каталога Active Directory для DNS после того, как установили контроллер домена, необходимо вручную создать раздел перед его использованием. Для создания раздела применяется консоль DNS или команда DnsCmd в командной строке.

При использовании консоли DNS щелкните правой кнопкой мыши на имени сервера DNS, в нашем случае это SERVER1 и из открывшегося контекстного меню выберите "Создать используемые по умолчанию разделы каталога приложений. " смотрите рисунок 12.

При использовании инструмента DnsCmd.exe откройте командную строку Cmd.exe (если правильно написать то нужно не командную строку а командный процессор Cmd.exe) в разделе "Выполнить" меню "Пуск" и наберите DnsCmd /? что бы увидеть все параметры данной команды, смотрите рисунок 13.

Наберите в командной строке >dnscmd <имяDNSсервера>/CreateBuiltinDirectoryPartitions/forest. В результате будет создан раздел ForestDnsZones. Чтобы создать раздел DomainDnsZones, используйте в конце этой команды вместо « /forest » параметр « /domain » в качестве последнего параметра в команде. Поскольку эта команда изменяет раздел конфигурации каталога в Active Directory, вы должны входить в систему как член группы Администраторы.

Да. забыл сказать что команда DnsCmd при установки операционной системы не устанавливается. Для того что бы ее использовать нам нужно установить ее с загрузочного диска с операционной системой. Для этого заходим на наш компакт диск находим папку "SUPPORT", а в данной папке, папку "TOOLS", и запускаем файл установки дополнительных инструментов под названием "SUPTOOLS.MSI", смотрите рисунок 14.

И еще. какие преимущества, что нам по сути дают эти два раздела ForestDnsZones и DomainDnsZones в составе DNS сервера хранящиеся в разделе приложений Active Directory.

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

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

• Репликация уровня леса позволяет уменьшить сетевой трафик, так как данные DNS больше не реплицируются в глобальный каталог.

Еще на этой вкладке "Общие" есть поле для выбора типа динамического обновления. О динамическом обновлении мы говорили, кто забыл читайте здесь. Тем не менее еще раз остановимся и посмотрим какой у нас выбор.

С помощью скажем так переключателя мы можем выбрать следующие механизмы динамического обновления. Смотрите рисунок 15.

Выбор "Никакие" (то есть запрет на динамическое обновление) рекомендуется если зона не интегрирована с Active Directory.

Выбор "Небезопасные и безопасные" — позволяет обновлять записи ресурса DNS всем клиентам.

Разрешить "Только безопасные" динамические обновления, думаю понятно. Но. этот выбор. скажем так. не совсем уместен если зона интегрирована с Active Directory, потому как мы вправе ограничить список клиентов, которым разрешено выполнять динамические обновления, посредством списков управления доступом. В конечном итоге решает какой механизм динамического обновления выбрать сетевой админ исходя из требований диктуемые конкретно его окружения то есть сетью.

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

Что бы настроить очистку от устаревших записей и используется кнопка "Очистка. " показанная на рисунках 6 и 15. Если ее нажать то открывается окно показное на рисунке 16.

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

С настройкам DNS зоны на вкладке "Общие" мы закончили. В следующих темах мы обсудим остальные способы и механизмы настройки DNS сервера.

DNS сервера решают одну из главных задач: для подключения к узлу необходимо знать его IP адрес, а людям гораздо проще запоминать обычные имена, чем IP адреса.

При большом стремлении можно изучить следующие RFC 1034 1035

Терминология

Домен — Единица в дереве имен, вместе со всеми подчиненными узлами. Уровни домена считаются справа налево.

ресурсная запись будет server1 и иметь формат A-Записи

Зона — Часть доменного имени вместе с ресурсными записями и поддоменами, которая хранится на одном сервере. Часто служит для передачи ответственности за актуальность данных третьим лицам.

Root-Hint — Well-known сервера отвечающие за корневой домен «.» (точка)

Ответственность — Бывает двух типов:

Authoritative — Когда DNS сервер хранит на себе запрашиваемую зону
Non-Authoritative — Когда DNS сервер не хранит на себе запрашиваемую зону

Рекурсивный и итеративный запрос

Есть два способа разрешения имен.

Первый это итеративный — это такой метод, при котором DNS сервер выступает в роли клиента и опрашивает другие DNS сервера в порядке убывания (начиная от корневых DNS серверов и заканчивая последним, авторитарным за нужную DNS зону ). Давайте рассмотрим как работает данный метод:

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

Как пример можно привести следующий сюжет:

Обратный DNS запрос

Служит для обратной цели, для разрешения из ip в имя. Для этого зарезервирован специальный домен in-addr.arpa, в котором хранятся PTR записи. Октеты IP адреса хранятся в обратном порядке, будьте внимательны. Так для ip 1.2.3.4 будет создана запись вида 4.3.2.1.in-addr.arpa

Виды записей DNS серверов

Приведем только основные, т.к. их большое количество:

Запись A (address record) — Связывает имя с IP адресом
Запись CNAME (canonical name record) — используется для перенаправление на другое имя. Используется в связке с Запись A
Запись MX(mail exchange) — Указывает на почтовый сервер
Запись NS (name server) — указывает на Name Server
Запись PTR (pointer) — Обратная Запись A
Запись SOA - Указывает где хранится начальная запись зоны, а так же ключевую информацию о зоне.
Запись SRV - Указывает на серверы для сервисов, к примеру Active Directory.

Порядок разрешения имен и поправки связанные с кэшированием

При запросе имени происходит несколько важных процедур, которые необходимо учитывать. Во первых это данные о связке имя — IP адрес может храиться в нескольких местах ( Hosts, DNS Cash, Lmhosts, DNS Server и др). Для того что бы полностью понимать принцип работы — нужно знать порядок в котором Windows пытается разрешить любое имя.

При разрешении имени сверяется с локальным именем компьютера.
Если локальное имя не совпадает с запрашиваемым, то выполнятеся поиск в DNS Cash. ВАЖНО: в DNS кэш динамически загружюется данные из файла HOSTS ( поэтому поиск по файлу hosts не происходит, его данные всегда в памяти ПК, что ускоряет обработку ). Файл Hosts расположен в %systemroot%\System32\Drivers\Etc
Если имя не разрешилось в IP адрес, то пересылается на DNS сервер, который задан в сетевых настройках.
Если имя сервера плоское ( к примеру: server1 ) и не может быть разрешено с помощью DNS, то имя конвертируется в NetBIOS имя и ищется в локальном кэше
Если имя не может разрешиться, то ишется на WINS серверах
Если имя не может быть опрделено и на WINS сервере, то ищется с помощью BROADCAST запроса в локальной подсети
Если имя не определилось, то ищется в файле LMHOSTS

На данном рисунке показывается все пункты:

Поиск по всем 7-ми шагам прекращается как только находится первое вхождение, удовлетворяющие условиям.

Примечание:
-Посмотреть DNS кэш можно по команде c:\>ipconfig /displaydns

Windows IP Configuration

Record Type . . . . . : 1

Time To Live . . . . : 158

Data Length . . . . . : 4

A (Host) Record . . . : 72.233.56.138

Record Type . . . . . : 1

Time To Live . . . . : 158

Data Length . . . . . : 4

A (Host) Record . . . : 67.19.16.228

-Очистить DNS кэш можно по команде ipconfig /flushdns
c:\>ipconfig /flushdns

Windows IP Configuration

Successfully flushed the DNS Resolver Cache.

Как можно самому посмотреть ответы на запросы?

Отличной утилитой для диагностики DNS является NSLookup.exe
На какие ключи я бы обратил внимание:

LServer — Можно принудительно подключиться к определенному DNS серверу
set type=** для выбора параметров, которые мы хотим получить, к примеру set type=mx

Состав UDP пакета

DNS сервера использую 53-й UDP порт для запросов. Обычно отвечают одной дейтаграммой.

Состав UDP датаграммы содержащей DNS запрос

Состав UDP дейтаграммы содержащей DNS ответ

Примечание: Все основные параметры и так понятны, не стану уточнять

В первой части я рассказал о основах DNS запросов, серверов и терминологии. Теперь приступим к изучении на конкретных примерах, я буду использовать стандартный DNS сервер из Windows 2008 R2. В этой части рассмотрю какие настройки можно покрутить и к чему это приведет, где хранятся данные о зонах, как планировать инфраструктуру DNS для корпоративной инфраструктуры.

Системные требования

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

DNS сервер без зон занимает порядка 4 Мб в оперативной памяти
При добавлении зон, данные загружаются в оперативную память
Каждая запись занимает порядка 100 байт. Так если у вас 1000 записей это займет еще 100 кб

Роли DNS серверов

Cashing-only — не хранят на себе никаких зон, являются только серверами, где хранится кэш DNS запросов. Поэтому они не создают Zone Transfer трафик. Можно использовать у филиальном офисе, для уменьшения DNS трафика между ним и главным офисом.
Non-recursive — Сервера, на которых хранится DNS зона и у которых отключена возможность рекурсивного разрешения имени. Это приводит к тому, что если сервер не может разрешить имя (не имеет ресурсной записи) то DNS запрос будет не разрешен. Такие сервера можно ставить в роли внешних DNS серверов компаний. Так же это защитит от использования внешними пользователями ваших DNS серверов для разрешения DNS имен в интеренете.
Forward-only — Понятно из названия, что сервера занимаются только пересылкой DNS запросов на другие сервера (обычный рекурсивный запрос — отключен). В таком случае, если сервер не получит ответа от других, то запрос будет не разрешен. Такие сервера можно использовать для управления DNS трафиком между корпоративной сетью и интернетом. В таком сценарии все внутренние сервера будет обращаться к Forward-only серверу с просьбой разрешить внешние имена. Пятно контакта с интернет уменьшится до одного DNS сервера.
Conditional forwards — Очень похоже на сервера Forward-only , но в отличии от них в том, что задается связка какой домен на какой IP нужно пересылать.

Уровни безопасности Microsoft DNS серверов

Выделяют 3 уровня:

Планирование пространства имен

При правильном планировании пространства DNS имен, не будет проблем с разрешением этих имен. В текущее время, каждая компания нуждается в связи с внешним миром. Что это означает для нас ?

Внутренние имена DNS серверов и служб — не должны быть доступны из интернета
Внутренние сервера должны уметь разрешать внешние (интернет) имена
Внешние пользователи должны иметь возможность разрешать внешние имена ( к примеру, имя сайта, точка подключения VPN, Exchange OWA и тд)

Правильным решением будет расщепить структуру DNS на области действия ( локальная сеть и интернет ). Есть несколько типовых решений. Давайте их рассмотрим и решим какие же выбрать. Одно пространство имен. К преимуществам можно отнести одно пространство имен для локальной сети и интернет. При этом разные DNS сервера отвечают за разные ресурсные записи. Если внутренний DNS используется для Active Directory и подобных ресурсов, то внешний DNS используется для WWW сайтов, VPN точки вхождения и тд. Так же различные области видения зон.

Одно пространство имен. К преимуществам можно отнести одно пространство имен для локальной сети и интернет. При этом разные DNS сервера отвечают за разные ресурсные записи. Если внутренний DNS используется для Active Directory и подобных ресурсов, то внешний DNS используется для WWW сайтов, VPN точки вхождения и тд. Так же различные области видения зон.

1. Проще в администрирование
2. Сразу понятна топология сети
3. Внутреннее пространство имен остается невидимым для внешних запросов
Есть три вида DNS зон, каждая может использоваться для своих нужд:

-Доступ на чтение и запись

-Увеливает доступность DNS зоны
- Primary - Дает возможность читать и писать в зону. Обычно Primary передает зону на Secondary сервера целиком, а потом передаются только изменения, произошедшие после последней синхронизации. Могут храниться в Active Directory ( При этом на всех DC все DNS сервера будут Primary).
- Secondary — Увеличиваю отказоустойчивость DNS зоны, из таких зон можно только читать, писать нельзя. Не могут храниться в Active Directory.
- Stub — зоны заглушки, содержат только NS и SOA сервера для требуемого домена. Это увеличивает эффективность разрешения имен. Информация в Stub зонах может реплицироваться с помощью Active Directory.
Динамические обнавления

Windows DNS сервера поддерживаю динамические обновления. Их несколько видов.
- Secured Dynamic Update in Active Directory — эта фича доступна только при интегрированных в AD DNS зон. Поскольку зона будет храниться в AD, то можно обезопасить данные использую возможности Active Directory. Можно использовать ACL (Access Control list) для определения прав на редактирование/чтение
- Dynamic DNS update from DHCP - Данная возможность позволяет обновлять записи DNS только DHCP серверам. Обновление происходит, когда клиент DHCP сервера получает IP. На DHCP серверах необходимо определить DNS зоны, в которых сервер будет динамически обновлять значения. На DNS сервере определить, что только DHCP сервера могут обновлять записи.
- DNS client dynamic update — Почти тоже самое, что и п.2. отличие заключается в том, что данные в DNS будут обновлять сами клиенты. Такая возможность есть Windows начиная с версии XP. Этот способ менее безопасен, т.к. атакующий может легко сменить запись в DNS. Разрешая данные динамические обновления, вы открываете дополнительную дверь для атакующего.
Передача зон и репликация

Поскольку для обеспечения высоко доступности DNS серверов применяют распределенные структуры. То необходимо синхронизировать обновление данных на всех серверах отвечающих за данную зону. Для этого и применяю передачу зон (репликацию в Active Directory).
- Передача зоны. При первой синхронизации передается полностью вся зона с Primary на Secondary сервер. В последующем, когда primary сервер получает запрос на синхронизацию (и у него версия зоны больше чем у secondary), то он может передать, либо всю зону, либо только последние изменения (это сокращает трафик. Инкриментальную передачу должны поддерживать оба сервера).
- Репликация в Active Directory. Все контролеры домена могу хранить у себя DNS зоны, синхронизация зон будет происходить по средствам репликации AD. Все DC в домене могут вносить изменения в зоны и такая схема называется мультимастерной репликацией. Хранение зоны в AD дает возможность легко задавать область синхронизации DNS в лесу.
  1. All DNS servers in the Active Directory forest — реплицирует на все DC в лесу Active Directory
  2. All DNS servers in the Active Directory domain — реплицирует на все DC в текущем домене Active Directory
  3. All domain controllers in the Active Directory domain — Если есть необходимость использовать DNS сервера под управлением Windows 2000
  4. All domain controllers in a specified application directory partition — Можно создать раздел приложений в Active Directory и настроить его только на нужных DC в лесу. В таком случае репликация будет проходить только между DC, в которых этот параметр задан вручную. О том как создавать разделы приложений
Места хранения зон
- File — %systemroot%\dns
- Active Directory — В зависимости от того области видимости зоны.
  1. Domain Partition. Часть раздела Active Directory, присутствующая на каждом DC в лесу. DNS зоны реплицируются на все DC в домене. Используется только для DC под управлением Windows 2000
  2. Forest-wide DNS Application directory partition. Хранится в разделе приложений Active Directory. DNS зоны, хранящиеся в данном разделе, реплицируются на все DC в лесу. Этот раздел создается автоматически, когда устанавнивается роль DNS сервера на первом DC в лесу под управлением Windows 2003 и выше.
  3. Domain-wide DNS Application directory partition. Раздел DNS для каждого отдельного домена в лесу. Хранится в разделе приложений Active Directory и реплицируется на все DC в текущем домене. Автоматички создается при установки роли DNS сервера в домене под управлением Windows 2003 и выше. Для каждого нового домена в лесу создается новая зона и область доступности, ограниченная текущим доменом.
  4. Custom DNS Application directory partition. Используется для репликации между зарание определенными DC. Хранится в разделе приложений Active Directory. Доступна во всем лесу Active Directory, на зарание определенных DC.
Передача прав

Делегирование — процесс передачи прав на часть доменного имени, к примеру, другой организации, филиалу, и тд.

Когда нужно делегировать ?
1. Когда нужно передать управление части доменного имени, что бы осуществлять администрирование без вашего участия
2. Когда есть большая база DNS, для обеспечения отказоустойчивости можно разнести базу по разным серверам
3. Когда необходимо добавить новый поддомен для нового офиса, и передать права на его администрирование.
Изучаем возможности Windows DNS сервера

Основу мы прошли, теперь давайте пробежимся по возможностям, которые дает стандартный DNS. Для этого нужно установить роль DNS Server на сервере. Эти шаги пропустим, т.к. выходят за рамки данной статьи.
- Primary, Secondary и Stub
- Store the zone in Active Directory — пусть мы будем хранить новую зону в Active Directory
DNS и Active Directory

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

Прежде всего надо отметить, что DNS должен поддерживать SRV записи, они являются ключевыми и указывают на Well-Known службы. Когда клиент подключается к домену, то он запрашивает эти записи и получает адреса нужных служб.

Во время поднятия роли сервера до DC, все необходимые записи в DNS создаются автоматически. В последующем, когда вы добавляете другие DC, сайты, удаляете данные. Все это прописывается в DNS. Именно по этой причине DNS сервер должен поддерживать динамические обновления ресурсных записей. Данные записи можно найти в файле %systemroot%\System32\Config\Netlogon.dns.

Теперь давайте поговори поподробней и начнем с _msdcs
- _msdcs— это поддомен, определнный Microsoft. Его задача определять расположение DC, которые выполняю определнные роли в лесу и в домене. Данная зона хранится в forest-wide application directory partition. Служба Net Logon регистрирует SRV записи для индентификации Well-Known ресурсов, таких как DC (Domain Controller), GC (Global Catalog), PDC (Primary Domain Controller), Domains (Globally Unique Identifier, GUID), как прфиксы в поддомене _msdcs. Определенные таким образом поддомены опрделеяют Domain Controllers, находящиеся в домене или лесу и выполнящие определнные роли. Что бы определять расположение DC по типу или по GUID, сервера Windows регистрируют SRV по следующему шаблону:
_Service._Protocol.DcType._msdcs.DnsDomainName
- SRV Записи. Когда контроллер домена загружается, служба Net Logon с помощью динамических обновлений регистрирует SRV и А записи на DNS сервере. SRV записи используются для закрепления имени службы ( к примеру LDAP) за DNS именем компьютера, на котором запущена данная служба. Когда рабочая станция подключается к домену, то она запрашивает DNS на наличие SRV записей по такой форме:
_Service._Protocol.DnsDomainName

Так как Active Directory использует TCP протокол, клиенты находять LDAP сервер в таком виде:

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

Прежде всего надо отметить, что DNS должен поддерживать SRV записи, они являются ключевыми и указывают на Well-Known службы. Когда клиент подключается к домену, то он запрашивает эти записи и получает адреса нужных служб.

Во время поднятия роли сервера до DC, все необходимые записи в DNS создаются автоматически. В последующем, когда вы добавляете другие DC, сайты, удаляете данные. Все это прописывается в DNS. Именно по этой причине DNS сервер должен поддерживать динамические обновления ресурсных записей. Данные записи можно найти в файле%systemroot%\System32\Config\Netlogon.dns.

Теперь давайте поговори поподробней и начнем с _msdcs
- _msdcs— это поддомен, определнный Microsoft. Его задача определять расположение DC, которые выполняю определнные роли в лесу и в домене. Данная зона хранится в forest-wide application directory partition. Служба Net Logon регистрирует SRV записи для индентификации Well-Known ресурсов, таких как DC (Domain Controller), GC (Global Catalog), PDC (Primary Domain Controller), Domains (Globally Unique Identifier, GUID), как прфиксы в поддомене _msdcs. Определенные таким образом поддомены опрделеяют Domain Controllers, находящиеся в домене или лесу и выполнящие определнные роли. Что бы определять расположение DC по типу или по GUID, сервера Windows регистрируют SRV по следующему шаблону:
_Service._Protocol.DcType._msdcs.DnsDomainName
- SRV Записи. Когда контроллер домена загружается, служба Net Logon с помощью динамических обновлений регистрирует SRV и А записи на DNS сервере. SRV записи используются для закрепления имени службы ( к примеру LDAP) за DNS именем компьютера, на котором запущена данная служба. Когда рабочая станция подключается к домену, то она запрашивает DNS на наличие SRV записей по такой форме:
_Service._Protocol.DnsDomainName

Так как Active Directory использует TCP протокол, клиенты находять LDAP сервер в таком виде:

Читайте также: