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

Автор: genadie от 6-04-2013, 22:39, посмотрело: 55750

2

 

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

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

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.domain.org

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

Ресурсная запись — Единица хранения информации, имеет имя и привязана к доменному имени. К примеру: server1.moscow.domain.org

  • ресурсная запись будет 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 сервер просто пересылает данные от клиента  другому серверу, что бы  он обработал данный запрос и вернул конечные данных. (другой сервер  может работать рекурсивно или точно так же интерактивно )

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

 
  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) — используется для перенаправление на  другое имя. Используется в связке с  Запись A
  • Запись 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 кэш можно по команде c:\>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

 

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 n

s4.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 серверов

  1. Cashing-only — не хранят на себе никаких зон, являются только серверами, где хранится кэш DNS запросов. Поэтому они не создают Zone Transfer трафик. Можно использовать у филиальном офисе, для уменьшения DNS трафика между ним и главным офисом.
  2. Non-recursive — Сервера, на которых хранится DNS зона и у которых отключена возможность рекурсивного разрешения имени. Это приводит к тому, что если сервер не может разрешить имя (не имеет ресурсной записи) то DNS запрос будет не разрешен. Такие сервера можно ставить в роли внешних DNS серверов  компаний. Так же  это  защитит от использования внешними пользователями ваших DNS серверов для  разрешения DNS имен в интеренете.
  3. Forward-only — Понятно из названия, что сервера  занимаются только пересылкой  DNS запросов на  другие сервера (обычный рекурсивный запрос — отключен). В таком случае, если сервер не получит ответа от других, то запрос будет не разрешен. Такие сервера можно использовать  для управления  DNS трафиком между корпоративной сетью и интернетом. В таком сценарии все внутренние сервера будет обращаться к Forward-only серверу с просьбой разрешить внешние  имена. Пятно контакта с интернет уменьшится  до одного DNS сервера.
  4. 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 точки вхождения и тд. Так же различные области видения зон.
  •  
     
  • Поддомен. Случай когда  для внутренний  инфраструктуры мы выделяем  от основного домена поддомен.
    1.  
      1. Проще в администрирование
      2. Сразу понятна топология сети
      3. Внутреннее пространство имен  остается невидимым для внешних запросов
  • Отдельное пространство имен. Довольно похоже на второй случай, мы тоже разделяем пространство имен. Но в данном случае, к примеру по воле религиозных мировоззрений или  иных задач — есть необходимость  не  разделять  публичный  домен. В таком случае мы сделаем отдельный домен для  внутренних нужд, и отдельный  для  внешних. Хоть у меня на рисунке и домены второго уровня совпадают, но  это не обязательное условие.
  • Виды 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 серверов  применяют распределенные структуры. То необходимо синхронизировать обновление данных на всех серверах отвечающих за  данную  зону. Для  этого и применяю передачу зон  (репликацию в 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
  3. Зададим имя зоны (без www или других поддоменов)
     
  4. Если вы  экспортировали  зону, то есть возможность просто ее вставить из файла (Use the existing file).  При этом файл должен быть помещен в %systemroot%\system32\dns
     
  5. Выберем нужны ли  динамические обновления  для  зоны. Т.к. Я создаю  зону для своего веб сайта, то  обновления мне ни к чему. Я буду сам ручками  добавлять  записи, т.к. записей будет не больше десятка.
     
  6. Ну вот и все, зону мы создали. Теперь можно посмотреть  ее свойства
    • Serial Number — номер зоны, на него ориентируются DNS сервера, сверяя не произошло ли обновлений  после  последней синхронизации.
    • Primary Server — Сервер, отвечающий  за  данную зону
    • Responsible person — введите адрес электронной почты, который Вы хотите (в формате «username.domain.com»). Например, если адрес электронной почты -hostmaster@inadmin.ru, введитеhostmaster.inadmin.ru.
    • Тут же можно настроить  информацию о том как долго кэшируюшие сервера  должны  хранить  у себя данные, через сколько повторять попытки обновления.
       
  7. Во вкладке Name Servers можно указать, где еще  будет храниться  данные о этой  зоне, т.е. другие NS сервера.
     
  8. Во вкладке Zone Transfers можно определить кому разрешено передавать  зону. Самым простым вариантом является  вариант Only to servers listed on the Name Servers tab. Который указывает, что только  на явно указанные NS сервера  возможна передача зоны. Так же  можно разрешить всем серверам или  только выбранным IP
     

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 сервера

Категория: Информация / сервер / Windows Server 2008

Уважаемый посетитель, Вы зашли на сайт как незарегистрированный пользователь.
Мы рекомендуем Вам зарегистрироваться либо войти на сайт под своим именем.
<
  • 0 комментариев
  • 0 публикаций
4 августа 2013 00:35

Mypejoupe

  • Группа: Гости
  • Регистрация: --
  • Статус:
 
Спасибо вам очень полезная вещь

<
  • 0 комментариев
  • 0 публикаций
13 апреля 2014 22:16

Сергей

  • Группа: Гости
  • Регистрация: --
  • Статус:
 
Спасибо, толково рассказано. Однако же остаются вопросы. По умолчанию при начальной установке создаются следующие записи DNS сервера. В зоне прямого просмотра _msdcs.имя (Вашего домена).имя домена первого уровня (local, com, ru и так далее) для примера _msdcs.bublik.com. (Артель Московские бублики) Я так понимаю речь была о нём. "_msdcs — это поддомен, определнный Microsoft. Его задача определять расположение DC, которые выполняю определённые роли в лесу и в домене." Тогда что за запись в зоне прямого просмотра с названием Вашего домена. Ну то есть верхняя запись bublik.com, а подветвь _msdcs? Кроме того - очень интересный момент. Видел настройку DNS сервера в домене с отсутствие данных записей. Как ни странно - всё работает. У самого так не получилось. Ошибки стандартные time out 2 сек. Unknown domen kontroller. Time out удалось обойти при указании Вкладка DNS, Имя DNS сервера, свойства, корневые ссылки, копировать и указать на самого себя. Но unknown сервер при lnsookup - так и лезет. А запись в зоне прямого просмотра - создана ручками, PTR - в зоне обратного, тоже ручками. Однако Unknow. И хотелось бы посмотреть примеры настройки среднего уровня безопасности и высокого. Потому как, когда наглядно оно и понимается проще.

Информация
Посетители, находящиеся в группе Гости, не могут оставлять комментарии к данной публикации.