Главная Windows, Новое DNS как ключевая фигура в сети интернет и доменной структуре
  • DNS как ключевая фигура в сети интернет и доменной структуре

    old-school

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

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

    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
    • Поддомен. Случай когда для внутренний инфраструктуры мы выделяем от основного домена поддомен.
      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

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

    Заключение

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

    Баканов Денис
    MCSE+S; MCITP EA
    Оригинал статьи

    • Рубрика: Windows,Новое
    • Автор: Баканов Денис
    • Дата: Вторник 02 Мар 2010

Комментарии

  1. Повторение — мать учения ©

    В мемориз однозначно!

    Буду еникейщикам давать линк

  2. Отличная статья. Сотрудникам пойдет в обязательное прочтение.

  3. И сам рад, своим сотрудникам уже дал на изучение 🙂

  4. Динь, молодец. Я статью до конца не осилил. 😉

    Есть в статье кое-какие допущения и неточности — например, процесс разрешения имен может разниться ну и т.п., но статью они не сильно портят. Жаль, что не упомянул о кэше имен NetBIOS, о debug-режиме nslookup («set debug»), о «GlobalNames»... Ну и мог бы уж перевести «forest-wide application directory partition». Материал надо было бы преподнести в двух частях: теория, практика.

    Желаю успехов в публицистике! 🙂

  5. хорошо написано,но не хватает описания случаев исползования dns сервером протокола tcp.

  6. Материала по DNS слишком много, хотелось написать о всем да и поглубже. Но когда начал писать, статья все начинала сгребать все больше и больше материала.Появлялись куча «частных» вариантов, когда поведение может меняться. В итого пришлось опускать некоторые моменты. Теперь понимаю, что нужно было делить тупо на три больших статьи: Основы работы, настройка и отладка DNS, DNS при использовании AD.

    Статью по DNS и AD потихоньку пишу.

  7. Спасибо за статью!

    Однако, на мой взгляд, она вышла немного скомканной.

  8. 2 Андрей Шимкин

    Смотрите 6-й комментарий.

  9. Спасибо, хорошая статья, хотелось бы побольше статей по DNS

  10. 2Anton

    Уже в процессе, только с работой надо разобраться...

  11. 6 Баканов Денис

    DNS вообще штука интересная. Когда нам лекции читали мы быстро прошли их глубоко не вникали. А когда введут 6 версию айпи днс будет просто необходим.

  12. 2 Немного админ =)

    А сейчас разве DNS не является ключевой технологией для IPv4 ?

  13. >А сейчас разве DNS не является ключевой технологией для IPv4 ?

    Пока это мертвая оторванная от жизни технология... Вся надежда на «6 версию айпи»

  14. Статья хорошая.

    Просьба, поделитесь источниками на основе которых статью собирали... скорее всего technet правда? (4f904480-7c78-11cf-b057-00aa006b4f8f) (^__^ не угадал?)

    Рекурсивные и итеративные запросы можно было рассмотреть по отдельности.

    Обычно, когда говорят про типовые решения, чуть подробней рассказывают где установлен Primary, а где Secondary.

    Понятно, что тема избитая, но добавили бы побольше от себя... опыт, историю там, какую-нибудь, а то получается next gen. technet какой-то ^__^

    Просто, хочется уникального интересного контента ... удачи!

  15. Да технет, служит хорошей справочной информацией. Ну могу я поменять GUID на свой, а толку?

    Статья первая, писанная лично. Буду исправляться в некоторых направлениях, оказывается писать не так-то просто.

  16. Толк будет в передаче лично Вашего опыта — это всегда самое ценное...

  17. Думаю в ближайшие 50 — 100 лет она будет реализована и тогда каждой молекуле воздуха на квадратный метр присвоить свой номер, причем уникальный, тогда и маски пропадут. Облегчится наша админская работа. ГЫ.

    Простите немного от темы ушел.

  18. //Немного админ =)

    тут согласен, ipv6 хорош. А что собственно хотели от старичка Ipv4, с его костылями ...

  19. В общем интересно было так пробежаться, но не рассмотрен очень интересный момент. Это DNS в связке с NLB и динамические ответы в зависимости от клиента.

  20. Есть несколько ошибок — неплохо бы перечитать статью и проверить орфографию. (Динамические обнавления, рекурсивно или точно так же интерактивно)

  21. Очень хотелось бы увидеть на сайте кнопочку «Версия для печати»

  22. >Очень хотелось бы увидеть на сайте кнопочку «Версия для печати»

    Она появилась, сразу после статьи:

    Версия для печати

    21 комментарий

  23. Спасибо, для начинающего меня — отличная статья.

  24. Доброго! Переустановили контроллер в филиале, и на всех DNS вылезло сообщение 4515

    Зона ашкьф.kz была ранее загружена из раздела каталога MicrosoftDNS, однако в разделе каталога DomainDnsZones.firma.kz обнаружена другая копия зоны. DNS-сервер будет игнорировать новую копию зоны. Этот конфликт должен быть разрешен максимально быстро.

    По рекомендации microsoft мало что понял, ибо копию зоны в DomainDnsZones.firma.kz через adsiedit не нашел. Руки опускаются, как лечить?? И чем это грозит? На вас вся надежда

  25. Прошу прощения за дубликат, но в первый раз ваш сайт выдал что то про капчу и сказал no spam=)

  26. У Вас иллюстрации к статье пропали (((

  27. вопрос по тексту по порядку разрешения днс имен:

    «1.Пользователь хочет получить доступ по имени www.inadmin.ru и отправляет запрос на свой DNS сервер.

    2.DNS сервер видит, что пришел запрос и у него в кэше нет значения.

    3.Так как сервер не знает где находится этот WWW, то нужно обратиться к корневому DNS серверу (их на самом деле несколько десятков), к примеру 198.41.0.4, и спрашивает, где находится www.inadmin.ru.

    ...»

    собственно, пункт 2 — если на днс-сервере в хостс есть значение для данного ресурса, значит оно ему подгружается в кэш автоматически, значит он должен по идее разрешить это имя в ип-адрес основываясь на кэше и хостс?

    протестил на вирт машине — имя с клиента не разрешается. почему и где ошибка?

  28. Ваш комментарий

  29. Попал случайно. Почитал статью. Пошел по ссылкам и путям и нашел там действительно то, что описано в статье — кучи непонятных записей и слов.

    Как все интересно и замечательно.

    Хоть ничего и не понял (кроме «Эвоно как оно все интересно закручено!»), автору респект.

    Рад, что есть люди, которые в этом разбираются.

  30. Спасибо за отличную статью!

    Большая просьба пофиксите картинки, пожалуйста, а то новичкам этом деле без них будет неудобно разбираться.

  31. Пофиксите картинки, пожалуйста.

Опубликовать

Я не робот.