1. Основи роботи DNS серверів
2. DNS сервера на основі платформи MS Windows в доменній структурі.

Сподіваюся ніхто не буде заперечувати того факту, що DNS (Domain Name System - система доменних імен) є ключовою фігурою. Від працездатності якої залежить дуже-дуже багато.

Давайте почнемо з простого, а саме для чого потрібні DNS сервера. Перш за все це розподілена структура, яка виконує роль дозволу імен в мережі. Основою DNS є ієрархічна структура, в якій кожен сервер відповідає за свою зону або домен. При цьому є можливість делегувати подальшу частину DNS імені іншого сервера, тим самим забезпечуючи актуальність всіх даних в цілому.

Основи роботи DNS серверів

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

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

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

При великому прагненні можна вивчити наступні RFC тисячі тридцять-чотири 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 зон, кожна може використовуватися для своїх потреб:

Primary

Active Directory реплицирующихся в інтегровані DNS зони в Active Directory -Чи точкою поновлення для зони

-Доступ на читання і запис

File Переміщується на Secondary DNS сервера Secondary забезпечує обмежену відмовостійкість забезпечує обмежену відмовостійкість -Доступ тільки на читання

-Увелівает доступність DNS зони

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. Ну ось і все, зону ми створили. Тепер можна подивитися її властивості

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
оригінал статті