Основи роботи dns

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

При великому прагненні можна вивчити наступні 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 сервер просто пересилає дані від клієнта іншого сервера, що б він обробив даний запит і повернув кінцеві даних. (Інший сервер може працювати рекурсивно або точно так же інтерактивно)

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

  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 запит

Види записів DNS серверів

Наведемо лише основні, тому що їх велика кількість:

Порядок дозволу імен та поправки пов'язані з кешуванням

На даному малюнку показується всі пункти:

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

Примітка:
-Подивитися DNS кеш можна по команді c: \> ipconfig / displaydns

Windows IP Configuration

Record Name. api.wordpress.org

Примітка: Всі основні параметри і так зрозумілі, не стану уточнювати

Коли сервіс DNS-сервера запускається, то в оперативну пам'ять поміщаються дані з усіх зон. Так само пам'ятаємо, що в пам'яті буде зберігатися кеш DNS запитів. Корисно буде пам'ятати системні вимоги для DNS серверів:

  1. DNS сервер без зон займає близько 4 Мб оперативної пам'яті
  2. При додаванні зон, дані завантажуються в оперативну пам'ять
  3. Кожен запис займає близько 100 байт. Так якщо у вас 1000 записів це займе ще 100 кб
  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. наприклад www.corp.contoso.msft будуть перенаправлені на 10.10.0.10

Рівні безпеки Microsoft DNS серверів

Виділяють 3 рівні:

Планування простору імен

При правильному плануванні простору DNS імен, не буде проблем з дозволом цих імен. В даний час, кожна компанія має потребу в зв'язку із зовнішнім світом. Що це означає для нас?

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

Правильним рішенням буде розщепити структуру DNS на області дії (локальна мережа та інтернет). Є кілька типових рішень. Давайте їх розглянемо і вирішимо які ж вибрати. Одне простір імен. До переваг можна віднести один простір імен для локальної мережі та інтернет. При цьому різні DNS сервера відповідають за різні ресурсні записи. Якщо внутрішній DNS використовується для Active Directory і подібних ресурсів, то зовнішній DNS використовується для WWW сайтів, VPN точки входження і тд. Так само різні області бачення зон.

  • Одне простір імен. До переваг можна віднести один простір імен для локальної мережі та інтернет. При цьому різні DNS сервера відповідають за різні ресурсні записи. Якщо внутрішній DNS використовується для Active Directory і подібних ресурсів, то зовнішній DNS використовується для WWW сайтів, VPN точки входження і тд. Так само різні області бачення зон.
  • Піддомен. Випадок коли для внутрішній інфраструктури ми виділяємо від основного домену піддомен.
      1. Простіше в адміністрування
      2. Відразу зрозуміла топологія мережі
      3. Внутрішній простір імен залишається невидимим для зовнішніх запитів
  • Окремий простір імен. Досить схоже на другий випадок, ми теж поділяємо простір імен. Але в даному випадку, наприклад з волі релігійних світоглядів чи інших завдань - є необхідність не розділяти публічний домен. В такому випадку ми зробимо окремий домен для внутрішніх потреб, і окремий для зовнішніх. Хоч у мене на малюнку і домени другого рівня збігаються, але це не обов'язкова умова.

  • Є три види DNS зон, кожна може використовуватися для своїх потреб:

    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).

    Місця зберігання зон

    Делегування - процес передачі прав на частину доменного імені, наприклад, інший організації, філії, і тд.

    Коли потрібно делегувати?

    1. Коли потрібно передати управління частини доменного імені, що б здійснювати адміністрування без вашої участі
    2. Коли є велика база DNS, для забезпечення відмовостійкості можна рознести базу по різних серверах
    3. Коли необхідно додати новий піддомен для нового офісу, і передати права на його адміністрування.

    Вивчаємо можливості Windows DNS сервера

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

    1. Запустимо майстер створення нової DNS зони.

    Виберемо тип зони і місце її розташування

    • Primary, Secondary і Stub
    • Store the zone in Active Directory - нехай ми будемо зберігати нову зону в Active Directory
  • Задамо ім'я зони (без www або інших піддоменів)
  • Якщо ви експортували зону, тобто можливість просто її вставити з файлу (Use the existing file). При цьому файл повинен бути поміщений в% systemroot% \ system32 \ dns
  • Виберемо потрібні динамічні оновлення для зони. Оскільки Я створюю зону для свого веб сайту, то поновлення мені ні до чого. Я буду сам ручками додавати записи, тому що записів буде не більше десятка.
  • У вкладці Name Servers можна вказати, де ще буде зберігатися дані про цій зоні, тобто інші NS сервера.
  • У вкладці Zone Transfers можна визначити кому дозволено передавати зону. Найпростішим варіантом є варіант Only to servers listed on the Name Servers tab. Який вказує, що тільки на явно зазначені NS сервера можлива передача зони. Так само можна дозволити всім серверам або тільки обраним IP

    DNS і Active Directory

    Як вже багато хто знає, Active Directory дуже сильно спирається на інфраструктуру DNS. Вона є основоного робочою конячкою. Отже давайте подивимося, які записи присутні і необхідні для роботи AD.

    Під час підняття ролі сервера до 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 записів за такою формою:

    Так як Active Directory використовує TCP протокол, клієнти находять LDAP сервер в такому вигляді:

    • SRV записи реєструються службою Net Logon

    Дозволяє клієнту знайти сервер з запущеним LDAP сервісом в домені DnsDomainName. Наприклад: _ldap._tcp.inadmin.ru

    _ldap._tcp. SiteName. _sites. DnsDomainName.

    Дозволяє клієнту знайти сервер з запущеним LDAP сервісом в домені DnsDomainName в сайті SiteName. SiteName відносне ім'я, яке зберігається в контейнері Configuration в Active Directory. Наприклад: _ldap._tcp.Moscow._Sites.inadmin.ru

    Дозволяє клієнту знайти контролер домену в домені DnsDomainName. Все DС реєструють цю SRV запис.

    _ldap._tcp. SiteName. _sites.dc._msdcs. DnsDomainName.

    Дозволяє клієнту знайти контролер домену в домені DnsDomainName в сайті SiteName. Все DС реєструють цю SRV запис.

    Дозволяє клієнту знайти PDC в домені DnsDomainName.Только PDC сервер реєструє дану SRV запис.

    Дозволяє клієнту знайти 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 KDC в даному домені DnsDomainName. Все DC реєструють цю SRV запис.

    Теж саме, що і _kerberos._tcp. DnsDomainName тільки через UDP

    _kerberos._tcp. SiteName. _sites. DnsDomainName.

    Дозволяє клієнтам знайти Kerberos KDC в даному домені DnsDomainName в сайті SiteName. Все DC реєструють цю SRV запис.

    Дозволяє клієнтам знайти DC на якому запущена роль Kerberos KDC в даному домені DnsDomainName. Все DC з роллю KDC реєструють цю SRV запис.

    _kerberos.tcp. SiteName. _sites.dc._msdcs. DnsDomainName.

    Дозволяє клієнтам знайти DC на якому запущена роль Kerberos KDC в даному домені DnsDomainName в сайті SiteName. Все DC з роллю KDC реєструють цю SRV запис.

    Дозволяє знайти Kerberos Password Change для поточного домену. Все DC c роллю kerberos KDC реєструю дану SRV запис

    Теж саме, що і _kpassword._tcp. DnsDomainName тільки через UDP

    Схожі статті