Сетевые сервисы Windows 2012 — DNS
В своё время открыл для себя простую истину: хочешь запомнить что-то — веди конспект (даже при чтении книги), а хочешь закрепить и систематизировать — донеси до людей (напиши статью). Поэтому, после двух лет работы в системной интеграции (сфере, которую я в бытность свою системным администратором, считал просто рогом изобилия для жаждущих прокачки специалистов), когда я понял, что знания постепенно вытесняются навыками правки документации и конфигурированию по мануалам и инструкциям, для поддержания формы я начал писать статьи о базовых вещах. Например вот — о DNS. Делал тогда я это больше для себя, но подумал — вдруг кому пригодится.
Сервис в современных сетях если не ключевой, то один из таковых. Те, для кого служба DNS — не нова, первую часть могут спокойно пропустить.
Содержание:
1. Основные сведения
2. Немного о формате сообщения DNS
3. TCP и UDP
4. DNS в Windows Server 2008 и 2012
5. DNS и Active directory
6. Источники информации
(анкеров нет, поэтому содержание без ссылок)
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-сервер не знает обо всех доменах в интернете. Поэтому, при получении запроса на неизвестный ему адрес, например metro.yandex.ru, инициируется следующая последовательность итераций:
DNS-сервер обращается к одному из корневых серверов интернета, которые хранят информацию о полномочных держателях доменов первого уровня или зон (ru, org, com и т.д.). Полученный адрес полномочного сервера он сообщает клиенту.
Клиент обращается к держателю зоны ru с тем же запросом.
DNS-сервер зоны RU ищет у себя в кэше соответствующую запись и, если не находит, возвращает клиенту адрес сервера, являющегося полномочным для домена второго уровня — в нашем случае yandex.ru
Клиент обращается к DNS yandex.ru с тем же запросом.
DNS яндекса возвращает нужный адрес.
Такая последовательность событий редко встречается в наше время. Потому что есть такое понятие, как рекурсивный запрос — это когда DNS-сервер, к которому клиент изначально обратился, выполняет все итерации от имени клиента и потом возвращает клиенту уже готовый ответ, а также сохраняет у себя в кэше полученную информацию. Поддержку рекурсивных запросов можно отключить на сервере, но большинство серверов её поддерживают.
Клиент, как правило, обращается с запросом, имеющим флаг «требуется рекурсия».
2. Немного о формате сообщения DNS
Сообщение состоит из 12-байтного заголовка, за которым идут 4 поля переменной длины.
Заголовок состоит из следующих полей:
Формат DNS-сообщения
Идентификация — в это поле клиентом генерируется некий идентификатор, который потом копируется в соответствующее поле ответа сервера, чтобы можно было понять на какой запрос пришёл ответ.
Флаги — 16-битовое поле, поделенное на 8 частей:
- QR (тип сообщения), 1-битовое поле: 0 обозначает — запрос, 1 обозначает — отклик.
- opcode (код операции), 4-битовое поле. Обычное значение 0 (стандартный запрос). Другие значения — это 1 (инверсный запрос) и 2 (запрос статуса сервера).
- AA — 1-битовый флаг, который означает «авторитетный ответ» (authoritative answer). Сервер DNS имеет полномочия для этого домена в разделе вопросов.
- TC — 1-битовое поле, которое означает «обрезано» (truncated). В случае UDP это означает, что полный размер отклика превысил 512 байт, однако были возвращены только первые 512 байт отклика.
- RD — 1-битовое поле, которое означает «требуется рекурсия» (recursion desired). Бит может быть установлен в запросе и затем возвращен в отклике. Этот флаг требует от DNS сервера обработать этот запрос самому (т.е. сервер должен сам определить требуемый IP адрес, а не возвращать адрес другого DNS сервера), что называется рекурсивным запросом (recursive query). Если этот бит не установлен и запрашиваемый сервер DNS не имеет авторитетного ответа, запрашиваемый сервер возвратит список других серверов DNS, к которым необходимо обратиться, чтобы получить ответ. Это называется повторяющимся запросом (iterative query). Мы рассмотрим примеры обоих типов запросов в следующих примерах.
- RA — 1-битовое поле, которое означает «рекурсия возможна» (recursion available). Этот бит устанавливается в 1 в отклике, если сервер поддерживает рекурсию. Мы увидим в наших примерах, что большинство серверов DNS поддерживают рекурсию, за исключением нескольких корневых серверов (коневые сервера не в состоянии обрабатывать рекурсивные запросы из-за своей загруженности).
- 0 — Это 3-битовое поле должно быть равно 0.
- rcode это 4-битовое поле кода возврата. Обычные значения: 0 (нет ошибок) и 3 (ошибка имени). Ошибка имени возвращается только от полномочного сервера DNS и означает, что имя домена, указанного в запросе, не существует.
Следующие четыре 16-битных поля указывают на количество пунктов в четырех полях переменной длины, которые завершают запись. В запросе количество вопросов (number of questions) обычно равно 1, а остальные три счетчика равны 0. В отклике количество ответов (number of answers) по меньшей мере равно 1, а оставшиеся два счетчика могут быть как нулевыми, так и ненулевыми.
Пример (получен с помощью WinDump при выполнении команды ping www.ru):
IP KKasachev-nb.itcorp.it.ru.51036 > ns1.it.ru.53: 36587+ A? www.ru. (24)
IP ns1.it.ru.53 > KKasachev-nb.itcorp.it.ru.51036: 36587 1/2/5 A 194.87.0.50 (196)
Первая строка — запрос: имя моего ПК, 51036 — случайно выбранный порт отправки, 53- заранее известный порт DNS-сервера, 36587 — идентификатор запроса, + — «требуется рекурсия», А — запрос записи типа А, знак вопроса означает, что это запрос, а не ответ. В скобках — длина сообщения в байтах.
Вторая строка — ответ сервера: на указанный исходный порт с указанным идентификатором запроса. Ответ содержит одну RR (ресурсную запись DNS), являющуюся ответом на запрос, 2 записи полномочий и 5 каких-то дополнительных записей. Общая длина ответа — 196 байт.
3. TCP и UDP
На слуху сведения о том, что DNS работает по протоколу UDP (порт 53). Это действительно по умолчанию так — запросы и ответы отправляются по UDP. Однако, выше упоминается наличие в заголовке сообщения флага TC (Truncated). Он выставляется в 1, если размер отклика превысил 512 байт — предел для UDP-отклика — а значит был обрезан и клиенту пришли только первые 512 байт. В этом случае клиент повторяет запрос, но уже по TCP, который ввиду своей специфики, может безопасно передать большие объёмы данных.
Также передача зон от основных серверов к дополнительным осуществляется по 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 отсутствует
Сравнительно недавно случайно заметил, что на рабочих серверах 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
Начать необходимо с создания зоны прямого просмотра с нужным нам именем (нужны права администратора предприятия). Подробно весь процесс расписан на скриншотах ниже:
Новая зона должна быть основной (1), храниться в AD (2), реплицироваться на все КД в лесу (3) и иметь имя _msdcs.ForestName (4), где ForestName — имя корневого домена леса AD. Обновления записей зоны должны быть только безопасными (5).
После того как зона создана, необходимо зайти в её свойства и добавить серверы DNS, которые будут обслуживать эту зоны:
Дальше нужно перезапустить службу Netlogon на каждом контроллере домена и дождаться пока только что созданная зона автоматически заполнится необходимыми для работы записями. При этом может пройти достаточно продолжительный период времени — у меня процесс заполнения занял примерно 10 минут. Командную строку нужно запустить с правами администратора.
Также вместо существовавшей зоны _msdcs на уровне поддомена должна появиться запись делегирования. У меня это произошло без моего участия, но если вдруг у вас эта зона автоматически не создалась (у меня так было на тестовой инфраструктуре. Возможно из-за нехватки терпения), можно её создать вручную. Для этого:
Msdcs зона что это
Зона _ msdcs и ее полномочные сервера в лесу AD
Доброго времени суток.
Ответ на вопрос, который я хочу задать, с одной стороны интуитивно понятный и возможно даже очевидный, но тем не менее, мне бы очень хотелось узнать мнение экспертов.
Итак, создаем новый лес. Будем использовать мастер DCPROMO . На первом контроллере в корневом домене example . com создаются две DNS зоны: _ msdcs . example . com и, собственно, example . com . В зоне example . com создается запись делегирования _ msdcs , в которой полномочным сервером для зоны _ msdcs.example.com записывается наш первый контроллер. При добавлении второго и последующего контролеров в корневой домен и последующей установки на них DNS сервисов автоматического обновления записи делегирования в плане добавления в нее даных FQDN и IP адресов новых контроллеров не происходит. Почему? Ведь очевидно, что новые контроллеры являются не менее полномочными представителями зоны _ msdcs . example . com , чем первый контроллер. Приходится обновлять запись делегирования вручную.
Далее. У нас появляется дочерний домен branch . example . com . На первом контроллере дочернего домена до запуска мастера DCPROMO устанавливаем DNS сервис, создаем зону branch . example . com , настраиваем условную пересылку запросов на DNS сервер корневого домена, в зоне example . com создаем запись делегирования для зоны branch будущему контроллеру и т.д.
Тест « dcdiag / test : dcpromo / DnsDomain : branch . example . com / ChildDomain » на member – сервере и разрешение имен проходят успешно. Спустя некоторое время после успешного повышения рядового сервера до роли первого контроллера дочернего домена в его оснастке DNS появляется зона _ msdcs . example . com .
Вопрос: нужно ли данные этого контролера ( FQDN и IP адрес) добавлять в запись делегирования зоны _ msdcs . example . com на контроллерах корневого домена, ведь раз контроллер дочернего домена содержит реплику зоны _ msdcs . example . com (или другими словами, содержит раздел каталога приложений ForestDnsZones. example . com ), значит, является полномочным для нее. И, опять же, почему запись делегирования не обновляется автоматически, ведь появляются же автоматически данные о новом контроллере на вкладке «Серверы имен» в свойствах зоны _ msdcs . example . com . Нужно ли обновлять запись делегирования вручную?
Заметки сисадмина о интересных вещах из мира IT, инструкции и рецензии. Настраиваем Компьютеры/Сервера/1С/SIP-телефонию в Москве
Протокол, определявший порядок обмена информацией в Интернете, описывал в том числе и систему адресации компьютеров, объединенных в эту Сеть. Согласно этой системе, каждому компьютеру присваивался уникальный четырехбайтовый адрес, который стали называть IP-адрес. Стандарт нового протокола и, соответственно, системы адресования были приняты в 1982 году.
Однако человеку гораздо проще запомнить некоторое слово, чем четыре бессодержательных для него числа. Из-за этого сразу после начала работы новой сети у пользователей стали появляться списки, в которых хранились не только адреса, но и соответствующие им имена узлов.
Эти данные, обычно хранившиеся в файле с именем hosts, позволяли при указании имени узла мгновенно получить его IP-адрес. Позже процесс внесения корректуры в эти файлы был усовершенствован — последнюю версию файла hosts можно было скачать с нескольких серверов с заранее определенными адресами.
С ростом числа компьютеров в сети корректировать эти файлы вручную стало невозможно. Появилась необходимость в глобальной базе имен, позволяющей производить преобразование имен в IP-адреса без хранения списка соответствия на каждом компьютере. Такой базой стала DNS (Domain Name System) — система именования доменов, которая начала работу в 1987 году.
Структура DNS
В Интернете существует множество DNS-серверов, предоставляющих клиентам необходимую информацию об именах узлов сети. Важнейшим качеством DNS является порядок их работы, позволяющий DNS-серверам синхронно обновлять свои базы. Добавление адреса нового сайта в Интернете проходит за считанные часы.
Вторая особенность системы — это организация DNS-серверов в виде иерархической структуры. Например, запрос от клиента об имени ftp.microsoft.com может пройти через несколько DNS-серверов, от глобального, содержащего информацию о доменах верхнего уровня (.com, .org, .net и т. п.), до конкретного сервера компании Microsoft, в чьих списках перечислены поддомены вида *. miсrosoft.com, в числе которых мы и находим нужный нам ftp.microsoft.com. При этом множество DNS-серверов организуется в зоны, имеющие права и разрешения, делегированные вышестоящим сервером. Таким образом, при добавлении нового поддомена на местном сервере уведомления остальных серверов в Глобальной сети не производятся, но информация о новых серверах оказывается доступной по запросу.
Зоны, домены и поддомены
С ростом числа доменных имен работа между серверами была распределена по принципу единоначалия. Идея проста. Если организация владеет собственным доменным именем (например microsoft.com или white-house, gov), то именование внутри своего домена она производит самостоятельно. Единственная сложность при такой работе — предоставление вышестоящими серверами этих прав нижестоящим серверам.
Уточним термины. Домен — это некий контейнер, в котором могут содержаться хосты и другие домены. Имя домена может не совпадать с именем контроллера домена, то есть домен — это виртуальная структура, не привязанная к компьютеру. Хост же, напротив, соответствует физическому компьютеру, подключенному к сети. Имя хоста является именем конкретного компьютера. Имя хоста может совпадать с именем домена. Имя домена может совпадать с именем зоны, к которой он принадлежит, в этом случае домен является корневым в зоне. При этом зона не обязана содержать в себе одноименный (корневой) домен.
Зона — это контейнер, объединяющий несколько доменов в структуру с общими разрешениями на управление, то есть зоны являются контейнерами для доменов и хостов. Зоны могут быть вложены одна в другую. Разница между зонами и доменами в том, что домену может принадлежать несколько зон, содержащих различные его поддомены. Это дает возможность делегировать полномочия для поддоменов и управлять группами поддоменов.
Зоны используются для делегирования полномочий. Каждый домен должен находиться в составе зоны при создании поддомена последний может быть переведен в новую зону, либо оставлен в зоне стоящего над ним домена. Для каждой зоны разрешения на создание или удаление всех входящих в нее доменов делегируются отдельно. Для нормальной работы корпоративной сети в большинстве случаев хватает единственной зоны, более того, очень часто системные администраторы ограничиваются созданием единственного домена.
Интеграция DNS в Active Directory
Компания Microsoft рекомендует использовать DNS-серверы в корпоративных сетях для организации работы компьютеров в составе домена. Дело в том, что технология DNS более универсальна и эффективна, чем использующиеся на старых системах WINS и NetBIOS. Клиенты только посылают запросы серверу и получают ответы без обращения к каким-либо иным узлам сети.
С точки зрения производительности лучше всего интегрировать DNS в Active Directory, что возможно на серверных ОС компании Microsoft начиная с Windows 2000 Server. Совмещение ролей DNS-сервера и контроллера домена упрощает администрирование сети, особенно если размеры ее достаточно велики.
Что нам стоит DNS построить
DNS реализуются в соответствии с единым стандартом, основы которого изложены в RFC 1011,1034 и 1035. В Windows Server 2003 процесс развертывания и управления DNS сделан проще, чем в предыдущих версиях операционных систем, благодаря мастерам настройки ролей сервера. В Windows Server 2003 добавлены и новые функции управления Active Directory, которая может быть интегрирована с DNS воедино,
При создании контроллера домена, то есть сервера, управляющего работой Active Directory, мастер предлагает создать и настроить DNS-сервер. Для этого достаточно в настройках отметить пункт «Install and configure the DNS server on this computer, and set this computer to use this DNS server as its preferred DNS server». В этом случае запускается DNS-сервер и создается зона, одноименная с вашим доменом.
Для имени домена лучше использовать два слова, разделенных точкой (вида гпу-domen.ru). Технически возможно включить компьютеры вашей сети и в домен верхнего уровня, но Microsoft не рекомендует использовать для домена имя, состоящее из одного слова, так как в этом случае возникают сложности с организацией пересылки запросов (forwarding) и динамических обновлений.
После перезапуска системы в окне «Manage Your Server» (управление сервером) и на панели «Администрирование» появятся новые элементы — ссылки на консоли управления Active Directory (три иконки) и DNS (одна иконка). Остановимся подробнее на консоли управления DNS-сервером.
Дерево DNS содержит список ONS-серве-ров, в нашем случае список будет состоять из одного пункта — имени нашего сервера. Раскрыв его, мы увидим три папки — «Forward Lookup Zones» (зоны прямого просмотра), «Reverse Lookup Zones» (зоны обратного просмотра, пустая папка) и «Event Viewer» .
Папка зон прямого просмотра будет содержать две записи. Зона, чье имя начинается с _msdcs, относится к организации работы системы (DC расшифровывается как Domain Controller, контроллер домена), пока что нам ее трогать не нужно, так же как и папку _msdcs во второй зоне. Выбрав вторую зону, в списке справа мы увидим ее содержимое — собственно говоря, все компьютеры, чьи имена хранятся на нашем сервере, будут перечислены именно там.
Добавление новых хостов будет происходить автоматически. Все операционные системы Windows, начиная с Windows 2000 Professional, поддерживают корректное обновление базы DNS-сервера в своей локальной сети. Новые пункты в список имен хостов на DNS-сервере могут добавляться и при помощи службы «Computer Browser». Вручную же добавление новых доменов и хостов, равно как и удаление существующих, происходит из меню консоли «Action» или из контекстного меню правой клавиши мыши.
После запуска контроллера можно приступить к введению в домен клиентских машин. Повторим, что корректная работа в составе домена возможна только для систем ранга Professional, начиная с Windows 2000 Professional, то есть в домене откажутся работать компьютеры под управлением операционных систем Windows 98, Windows Me или Windows XP Home Edition.
Когда же вы добавляете в домен компьютер с установленной ОС Windows 2000 Professional или Windows XP Professional, система автоматически пошлет запрос DNS- серверу, а тот в свою очередь добавит новый IP-адрес в список.
В сети, состоящей из компьютеров с фиксированными IP-адресами, работа DNS предельно проста. Однако как быть, если в вашей сети IP-адреса должны раздаваться динамически? Тут мы сталкиваемся с определенными сложностями, поскольку в этом случае DNS-сервер должен обновлять свою базу постоянно, основываясь на данных, получаемых от DHCP-сервера.
Впрочем, чтобы настроить DNS и DHCP на совместную работу, не требуется особых усилий. Достаточно открыть «Scope Options» в консоли управления DHCP-сервером и указать имя вашего DNS-сервера в параметре «DNS Domain Name».
IP-адрес самого DNS-сервера может быть динамическим. В этом случае для каждого нового компьютера, выполняющего серверные функции, настройка сетевых параметров при его подключении будет происходить благодаря DHCP-серверу. Также не обязательно, чтобы серверы DHCP и DNS физически находились на одном компьютере. Они будут корректно работать, даже если запущены на разных машинах.
DNS-сервер может производить очистку списка, удаляя из него данные о тех хостах, которые удалены из сети. Чтобы настроить очистку списка хостов, нажмите кнопку «Aging» («Очистка») на вкладке «General» в свойствах зоны — по умолчанию удаление «просроченных» имен выключено (нужно поставить соответствующую галочку). Кроме того, там же указывается параметр автоматического обновления («Dynamic Updates») — по умолчанию он переключен в «Secure Only» и разрешает производить обновления базы на основе запросов только от безопасных источников.
Подключаемся к Интернету
У начинающих системных администраторов возникает немало проблем от некорректного обращения с настройками DMS, в том числе с соответствующими настройками на компьютерах пользователей. Во-первых, все зависит оттого, статические или динамические IP-адреса используются в вашей сети. В случае, если используются статические адреса, убедитесь, что на каждой машине корректно прописан ее IP-адрес, маска подсети и выбираемый по умолчанию DNS-сервер. Если же компьютеры получают свои IP-адреса динамически, посредством DHCP-сервера, то этот же сервер должен указывать и адрес DNS-сервера. Учтите, что для корректной работы клиентов DHCP-сервер в подсети должен быть единственным.
Другая задача, возникающая перед администраторами, — это настройка доступа в Интернет через локальную сеть. Доступ может быть организован по-разному, и, если все клиенты подключаются через прокси-сервер, настраивать DNS для работы в Интернете необходимости нет. Другое дело, если вы используете IР-маскарадинг при помощи NAT. В этом случае клиентские компьютеры в вашей сети должны будут иметь возможность получать ответы от DNS-серверов в Интернете, чтобы подключаться к веб-серверам по их IP-адресам.
Можно обойтись и одним шагом, ведь если маршрутизатор предоставляет сервис NAT для выхода в Интернет, то сам DNS-сервер может обращаться непосредственно к провайдеру. Однако такой метод менее грамотен. Например, если вы поменяете провайдера, вам придется править настройки уже на нескольких компьютерах. Кроме того, подключение к Интернету через NAT менее безопасно, чем перенаправление запросов посредством прокси-сервера. Также по соображениям безопасности не рекомендуется совмещать роль DNS-сервера и маршрутизатора на одном компьютере, особенно если он же является и контроллером домена в вашей сети.
Настройка форвардинга происходит в свойствах DNS-сервера из консоли управления. Нажимаем правой кнопкой на значке сервера, затем «Properties -> Forwarders», где и указываем имя вышестоящего домена или перечисляем DNS-серверы, к которым будет обращаться наш сервер. На вкладке «Root Hints» перечисляются адреса DNS-серверов сети (не обязательно вышестоящих). Список «Root Hints» может быть заполнен автоматически при помощи мастера Configure DNS Server из меню «Action».
Ошибкой является создание зоны с именем «.». В этом случае наш DNS-сервер начнет считать себя корневым, то есть верхним в глобальном дереве DNS. Разумеется, никакие пересылки вышестоящим серверам работать не будут. При создании зоны, чье имя совпадает с частью имени уже существующих зон после точки (например, у нас есть зона trading.office, а мы создаем зону office), все принадлежащие ей зоны и домены оказываются вложенными в нее.
Если у вашего сервера в свойствах подключения к локальной сети в качестве DNS-сервера указан сам контроллер домена, это тоже не очень хорошо. DNS-запрoсы никогда не должны приходить на сервер с его же адреса — любой подобный случай однозначно свидетельствует о неправильности настроек.
Разобраться в ситуации поможет «Event Viewer». В случае корректной работы DNS-сервера в журнале должна появиться запись о старте сервера. Также новые записи будут появляться по мере добавления новых имен хостов либо при ручном управлении зонами и доменами.
Для того чтобы детектировать неисправности со стороны клиента, проще всего воспользоваться консольной утилитой nsLookup, которая поставляется вместе с операционной системой. После ввода nsLookup в командной строке на экране должно появиться имя и IP-адрес вашего DNS-сервера, а после этого вам будет предоставлена возможность протестировать сервер путем отправления запросов на преобразование имени в IP-адрес. Чтобы увидеть справку по параметрам команды nslookup, введите в командной строке nslookup help.