IT2web

Системному администратору Windows Server

Главная --> DNS --> DNS. Основы. Характеристики. Терминология.

DNS. Основы. Характеристики. Терминология.

Article Index
DNS. Основы. Характеристики. Терминология.
Терминология
Рекурсивный и итеративный запрос
Обратный DNS запрос
Порядок разрешения имен
Как можно самому посмотреть ответы на запросы?
Состав UDP пакета
DNS сервера на основе платформы MS Windows
Роли DNS серверов
Уровни безопасности Microsoft DNS серверов
Планирование пространства имен
Виды DNS зон
Динамические обнавления
Передача зон и репликация
Места хранения зон
Передача прав
Изучаем возможности Windows DNS сервера
DNS и Active Directory
SRV записи регистрируемые службой Net Logon
Дополнительные поля SRV записей
Заключение
All Pages

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

Основы работы DNS серверов

Ключевые характеристики:

  • Распределенность хранения информации Данные о разных зонах хранятся на разных серверах
  • Распределенность администрирования За различные зоны отвечают разные сотрудники
  • Возможность кэширования запросов Для снижения загрузки и уменьшение времени отклика.
  • Отказоустойчивость Несколько серверов отвечают за хранение информации об одной зоне

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

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



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

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

  • Корневым доменом является «.» (точка, которая ставится в конце DNS имени. Пример: server1.moscow.domain.org. ). Обычно ее опускают при наборе имени, но можно ее ставить, тогда это определит имя как FQDN (Fully Qualified Domain Name).
  • Домены первого уровня ( обычно это org, com, me, tv, ru и тд ) относятся к тематическим или региональным. Определяющими страну или род деятельности.
  • Домены второго уровня ( пример: mail, gmail, yandex ) Такие обычно и встречаются в интернете, их продают регистраторы. Некоторые стоят копейки, другие же как несколько самолетов.
  • Домены третьего и остальных уровней редко когда продаются и регистрируются. Исключением может являться, к примеру, ****.com.ru и подобные имена.

Поддомен – Подчиненный домен.

К примеру: server1.moscow.inadmin.ru

    • Для домена inadmin.ru поддоменом будет moscow
    • Длина может составлять до 127 поддоменов, каждый из которых до 63 символов. Но при этом общая длина не должна превышать 254 символов

Ресурсная запись – Единица хранения информации, имеет имя и привязана к доменному имени.

К примеру: server1.moscow.inadmin.ru, то ресурсная запись будет server1 и иметь формат A-Записи

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

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

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

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

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

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

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

  1. Пользователь хочет получить доступ по имени www.inadmin.ru и отправляет запрос на свой DNS сервер.
  2. DNS сервер видит, что пришел запрос и у него в кэше нет значения.
  3. Так как сервер не знает где находится этот WWW, то нужно обратиться к корневому DNS серверу (их на самом деле несколько десятков), к примеру 198.41.0.4, и спрашивает, где находится www.inadmin.ru.
  4. Корневой DNS сервер (198.41.0.4) не знает где хранятся записи для домена www.inadmin.ru , но знает кто ответственный за домен первого уровня ru. и возвращает нашему DNS серверу его IP 193.232.142.17
  5. Наш DNS сервер обращается к нему (193.232.142.17) с просьбой сообщить IP для www.inadmin.ru. Но этот DNS тоже не знает ничего про наш адрес. Но знает, что есть DNS который отвечает за inadmin.ru. и возврщает его IP 195.128.64.3
  6. Наш DNS сервер обращается к нему 195.128.64.3 с просьбой сообщить IP для www.inadmin.ru. А вот он уже знает про запись www для нашего домена и возвращает нужный нам IP
  7. Наш DNS сервер отдает данный IP клиенту. Теперь клиент может подключиться по имени к серверу.

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

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

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

  1. Resolver посылает рекурсивный запрос на свой DNS сервер NameServer1
  2. NameServer1 итеративными запросами обращается к root-hint
  3. Т.к. данные не могу разрешится, то возвращается IP DNS сервера, ответственного за зону COM
  4. NameServer1 итеративными запросами обращается к NS, ответственного за зону COM
  5. Т.к. данные не могу разрешится, то возвращается IP DNS сервера, ответственного за зону Reskit.com
  6. NameServer1 итеративными запросами обращается к NS, ответственного за зону Reskit.com
  7. Получает нужные данные
  8. Отправляет данные обратно клиенту Resolver

Обратный 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) – используется для перенаправление на другое имя. Используется в связке с Записью А типа
  • Запись MX (mail Exchange) – Указывает на почтовый сервер
  • Запись NS (name server) – указывает на Name Server
  • Запись PTR (pointer) – Обратная Запись A
  • Запись SOA — Указывает где хранится начальная запись зоны, а так же ключевую информацию о зоне.
  • Запись SRV — Указывает на серверы для сервисов, к примеру Active Directory.

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

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

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

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

Процесс разрешения имен в сети

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

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

c:\>ipconfig /displaydns

Windows IP Configuration

api.wordpress.org
----------------------------------------
Record Name . . . . . : api.wordpress.org
Record Type . . . . . : 1
Time To Live . . . . : 158
Data Length . . . . . : 4
Section . . . . . . . : Answer
A (Host) Record . . . : 72.233.56.138
Record Name . . . . . : ns1.mobiusltd.com
Record Type . . . . . : 1
Time To Live . . . . : 158
Data Length . . . . . : 4
Section . . . . . . . : Additional
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

Приведу пример использования утилиты NSLookup. Допустим нам надо узнать MX и NS записи для домена mail.ru

C:\>nslookup
Default Server: china-lo-oldnbn.ti.ru
Address: 212.1.224.53

> set type=mx
> mail.ru
Server: china-lo-oldnbn.ti.ru
Address: 212.1.224.53

Non-authoritative answer:
mail.ru MX preference = 10, mail exchanger = mxs.mail.ru
mail.ru nameserver = ns.mail.ru
mail.ru nameserver = ns1.mail.ru
mail.ru nameserver = ns3.mail.ru
mail.ru nameserver = ns4.mail.ru
mail.ru nameserver = ns5.mail.ru
mail.ru nameserver = ns2.mail.ru
mxs.mail.ru internet address = 94.100.176.20
ns4.mail.ru internet address = 94.100.178.64
ns.mail.ru internet address = 94.100.178.70
ns1.mail.ru internet address = 94.100.179.159

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

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

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

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

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


DNS сервера на основе платформы MS Windows в доменной структуре.

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

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

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

  1. DNS сервер без зон занимает порядка 4 Мб в оперативной памяти
  2. При добавлении зон, данные загружаются в оперативную память
  3. Каждая запись занимает порядка 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 нужно пересылать.


contoso.msft 10.10.0.10
talspintoys.msft 172.16.0.20

Таким образом все запросы связанные с contoso.msft , к примеру www.corp.contoso.msft будут перенаправлены на 10.10.0.10


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

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

  • Низкий уровень безопасности
    1. Ваша DNS инфраструктура полностью выставлена в интернет
    2. Обычное разрешение имен DNS выполняют все сервера в вашей сети
    3. Все DNS сервера сконфигурированы на использование Root-Hint`ов
    4. Все DNS сервера позволяют перемещение зоны на любые сервера
    5. Все DNS сервера слушают на всех своих IP
    6. Отключено очистка от старых записей в кэше
    7. Динамическое обновление разрешено для всех зон
    8. На пограничном Firewall пропускается DNS трафик в обе стороны
  • Средний уровень безопасности
    1. Ваша DNS инфраструктура имеет ограниченный доступ в интернет
    2. Все DNS сервера настроены на использование пересылки запросов на специальные сервера, когда они не могут разрешить имя локально
    3. Перемещении зоны разрешено только для своих NS серверов
    4. Сервера настроены прослушивать только на определенных IP
    5. Включена очистка загрязнений в DNS кэше
    6. Общение между внутренним и внешними DNS серверами происходит через Firewall, который частично ограничивает запросы. Есть жесткий список от кого и кому разрешены DNS запросы.
    7. Внешние DNS сервера настроены на использование Root-Hints
  • Высокий уровень безопасности – немного больше закрученных гаек по сравнению со средним уровнем. В такой структуре полностью отсутствует взаимодействие с интернетом. Это не стандартная конфигурация, но она идеальна, если не нужен доступ в интернет.
    1. Ваша DNS инфраструктура полностью не доступна из интернета
    2. Внутри сети используются DNS сервера, которые являются корневыми и хранят все адресное пространство.
    3. Сервера, настроенные для пересылки запросов используют только внутренние IP DNS серверов
    4. Перемещение зоны жестко ограничено IP адресами
    5. Сервера настроены прослушивать только на определенных IP
    6. Включена очистка загрязнений в DNS кэше
    7. Внутренние DNS сервера настроены на использование root-hint прикрепленным к корневым внутренним DNS, на которых хранится корневая зона для вашего пространства имен
    8. Все DNS сервера хранятся на Domain controllers и имеют ограниченный доступ (DACL)
    9. Все зоны хранятся в Active Directory и имеют ограниченный доступ (DACL)
    10. Безопасные динамические обновления разрешены за исключением верхнего уровня корневых зон.

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

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

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

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

  • Одно пространство имен. К преимуществам можно отнести одно пространство имен для локальной сети и интернет. При этом разные DNS сервера отвечают за разные ресурсные записи. Если внутренний DNS используется для Active Directory и подобных ресурсов, то внешний DNS используется для WWW сайтов, VPN точки вхождения и тд. Так же различные области видения зон. Same DNS name. split dns
  • Поддомен. Случай когда для внутренний инфраструктуры мы выделяем от основного домена поддомен.
    1. Проще в администрирование
    2. Сразу понятна топология сети
    3. Внутреннее пространство имен остается невидимым для внешних запросов
    4. Domain DNS
  • Отдельное пространство имен. Довольно похоже на второй случай, мы тоже разделяем пространство имен. Но в данном случае, к примеру по воле религиозных мировоззрений или иных задач — есть необходимость не разделять публичный домен. В таком случае мы сделаем отдельный домен для внутренних нужд, и отдельный для внешних. Хоть у меня на рисунке и домены второго уровня совпадают, но это не обязательное условие.local DNS

Виды DNS зон

Есть три вида DNS зон, каждая может использоваться для своих нужд:





Primary Active Directory Реплицируется в интегрированые DNS зоны в Active Directory -Является точкой обновления для зоны — Доступ на чтение и запись
File Перемещается на Secondary DNS сервера
Secondary обеспечивает ограниченную отказоустойчивость обеспечивает ограниченную отказоустойчивость -Доступ только на чтение — Увеливает доступность DNS зоны
Stub Active Directory Переодически запрашивает зону на изменения -Увеличивает эффективность разрешения имен-Упрощает администрирование
File
  • 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 серверов применяю Primary -Secondary. То необходимо синхронизировать обновление данных на всех серверах отвечающих за данную зону. Для этого и применяю передачу зон (репликацию в 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 на сервере. Эти шаги пропустим, т.к. выходят за рамки данной статьи.

  1. Запустим мастер создания новой DNS зоны.
  2. Выберем тип зоны и место ее расположения Primary, Secondary и Stub. Store the zone in Active Directory – пусть мы будем хранить новую зону в Active Directory

Мастер DNS. Создание зоны DNS

3. Зададим имя зоны (без www или других поддоменов)

Создание  зоны DNS

4. Если вы экспортировали зону, то есть возможность просто ее вставить из файла (Use the existing file). При этом файл должен быть помещен в %systemroot%\system32\dns

Создание зоны DNS

5.Выберем нужны ли динамические обновления для зоны. Т.к. Я создаю зону для своего веб сайта, то обновления мне ни к чему. Я буду сам ручками добавлять записи, т.к. записей будет не больше десятка.

Создание зоны DNS

6. Ну вот и все, зону мы создали. Теперь можно посмотреть ее свойства

  • Serial Number – номер зоны, на него ориентируются DNS сервера, сверяя не произошло ли обновлений после последней синхронизации.
  • Primary Server – Сервер, отвечающий за данную зону
  • Responsible person – введите адрес электронной почты, который Вы хотите (в формате «username.domain.com»). Например, если адрес электронной почты - hostmaster@inadmin.ru, введите hostmaster.inadmin.ru.
  • Тут же можно настроить информацию о том как долго кэширующие сервера должны хранить у себя данные, через сколько повторять попытки обновления.
  • Создание зоны DNS

7. Во вкладке Name Servers можно указать, где еще будет храниться данные о этой зоне, т.е. другие NS сервера.

Создание зоны DNS

8. Во вкладке Zone Transfers можно определить кому разрешено передавать зону. Самым простым вариантом является вариант Only to servers listed on the Name Servers tab. Который указывает, что только на явно указанные NS сервера возможна передача зоны. Так же можно разрешить всем серверам или только выбранным IP

Создание зоны DNS


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 сервер в таком виде:

_ldap._tcp. DnsDomainName


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



_ldap._tcp. DnsDomainName . Позволяет клиенту найти сервер с запущенным LDAP сервисом в домене DnsDomainName. К примеру: _ldap._tcp.inadmin.ru
_ldap._tcp. SiteName . _sites. DnsDomainName . Позволяет клиенту найти сервер с запущенным LDAP сервисом в домене DnsDomainName в сайте SiteName. SiteName относительное имя, которое хранится в контейнере Configuration в Active Directory. К примеру: _ldap._tcp.Moscow._Sites.inadmin.ru
_ldap._tcp.dc._msdcs. DnsDomainName . Позволяет клиенту найти контроллер домена в домене DnsDomainName. Все DС регистрируют данную SRV запись.
_ldap._tcp. SiteName . _sites.dc._msdcs. DnsDomainName . Позволяет клиенту найти контроллер домена в домене DnsDomainName в сайте SiteName. Все DС регистрируют данную SRV запись.
_ldap._tcp.pdc._msdcs. DnsDomainName . Позволяет клиенту найти PDC в домене DnsDomainName.Только PDC сервер регистрирует данную SRV запись.
_ldap._tcp.gc._msdcs. DnsForestName . Позволяет клиенту найти PDC в лесу DnsForestName.Только GC сервера регистрируют данную SRV запись.
_ldap._tcp. SiteName . _sites.gc._msdcs. DnsForestName . Позволяет клиенту найти GC в лесу DnsForestName.Только GC сервера принадлежащие данному лесу регистрируют данную SRV запись. К примеру: _ldap._tcp.Moscow._Sites._gc._msdcs.inadmin.ru
_gc._tcp.DnsForestName. Позволяет клиенту найти GC в данном домене. Только GC сервера принадлежащие данному лесу DnsForestName регистрируют данную SRV запись. К примеру: _gc._tcp.inadmin.ru
_gc._tcp.SiteName. _sites.DnsForestName. Позволяет клиенту найти GC в данном лесу DnsForestName в сайте SiteName. Только GC сервера принадлежащие данному лесу DnsForestName регистрируют данную SRV запись. К примеру: _gc._tcp._Moscow._Sites.inadmin.ru
_ldap._tcp. DomainGuid . domains._msdcs. DnsForestName . Позволяет клиентам найти DC по GUID. GUID это 128-битный уникальный указатель. Расчитано на тот момент, когда DnsDomainName и DnsForestName изменились. К примеру: _ldap._tcp.4f904480-7c78-11cf-b057-00aa006b4f8f.domains. _msdcs.inadmin.ru
_kerberos._tcp. DnsDomainName . Позволяет клиентам найти Kerberos KDC в данном домене DnsDomainName. Все DC регистрируют данную SRV запись.
_kerberos._udp. DnsDomainName . Тоже самое, что и _kerberos._tcp. DnsDomainName только через UDP
_kerberos._tcp. SiteName . _sites. DnsDomainName . Позволяет клиентам найти Kerberos KDC в данном домене DnsDomainName в сайте SiteName. Все DC регистрируют данную SRV запись.
_kerberos._tcp.dc._msdcs. DnsDomainName . Позволяет клиентам найти DC на котором запущена роль Kerberos KDC в данном домене DnsDomainName. Все DC с ролью KDC регистрируют данную SRV запись.
_kerberos.tcp. SiteName . _sites.dc._msdcs. DnsDomainName . Позволяет клиентам найти DC на котором запущена роль Kerberos KDC в данном домене DnsDomainName в сайте SiteName. Все DC с ролью KDC регистрируют данную SRV запись.
_kpasswd._tcp.DnsDomainName. Позволяет найти Kerberos Password Change для текущего домена. Все DC c ролью kerberos KDC регистрирую данную SRV запись
_kpasswd._udp.DnsDomainName. Тоже самое, что и _kpassword._tcp. DnsDomainName только через UDP

Так же у SRV записей есть дополнительные поля:



Priority Приоритет сервера. Клиенты пытаются подключиться к серверам с меньшим приоритетом.
Weight Используется в роли Load-balanced для серверов с одинаковым приоритетом. Клиенты рандомно выбирают сервер с вероятностью, пропорциональной весу.
Port Number Порт, на котором сервер «слушает»
Target FQDN сервера

Заключение

Ну вот по основам работы DNS мы пробежали, тут еще опущены некоторые технические детали и моменты. Более подробно об взаимодействии DNS и Active Directory в следующей статье. Вместить все в одной статье – нет возможности.

Баканов Денис
MCSE+S; MCITP EA