Главная » Мережеві технології » DNS » Як зробити dns сервер. Как зробити dns сервер

Як зробити dns сервер. Как зробити dns сервер

Як зробити dns сервер. Как зробити dns сервер

Мережеві сервіси Windows 2012 - DNS

Kabal375 3 березня 2014 о 14:19 31374

Свого часу відкрив для себе просту істину: хочеш запам'ятати щось - веди конспект (навіть при читанні книги), а хочеш закріпити і систематизувати - донеси до людей (напиши статтю). Тому, після двох років роботи в системній інтеграції (сфері, яку я, перебуваючи на посаді системним адміністратором, вважав просто рогом достатку для спраглих прокачування фахівців), коли я зрозумів, що знання поступово витісняються навичками редагування документації та конфігурації за мануали і інструкцій, для підтримки форми я почав писати статті про базові речі. Наприклад ось - про DNS. Робив тоді я це більше для себе, але подумав - раптом кому стане в нагоді.

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

4. DNS в Windows Server 2008 і 2012

5. DNS і Active directory

6. Джерела інформації

(Анкерів немає, тому зміст без посилань)

1. Основні відомості

DNS - це база даних, яка містить, в основному, інформацію про зіставлення імен мережевих об'єктів їх IP-адресами. «В основному» - тому що там і ще деяка інформація зберігається. А точніше, ресурсні записи (Resource Records - RR) наступних типів:

А - то саме зіставлення символьного імені домена його IP адресою.

АААА - то ж що А, але для адрес IPv6.

CNAME - Canonical NAME - псевдонім. Якщо треба щоб сервер з нелегким для читання ім'ям, типу nsk-dc2-0704-ibm, на якому крутиться корпоративний портал, відгукувався також на ім'я portal, можна створити для нього ще один запис типу А, з ім'ям portal і таким же IP-адресою. Але тоді, в разі зміни IP адреси (всяке буває), потрібно буде пересоздавать всі подібні записи заново. А якщо зробити CNAME з ім'ям portal, який вказує на nsk-dc2-0704-ibm, то нічого змінювати не треба.

MX - Mail eXchanger - покажчик на поштовий обмінник. Як і CNAME, являє собою символьний покажчик на вже наявну запис типу A, але крім імені містить також пріоритет. MX-записів може бути кілька для одного поштового домену, але в першу чергу пошта відправлятиметься на той сервер, для якого вказано менше значення в поле пріоритету. У разі його відсутності - на наступний сервер і т. Д.

NS - Name Server - містить ім'я DNS-сервера, відповідального за даний домен. Природно для кожного запису типу NS повинен бути відповідний запис типу А.

SOA - Start of Authority - вказує на якому з NS-серверів зберігається еталонна інформація про даний домені, контактну інформацію особи, відповідальної за зону, таймінги зберігання інформації в кеші.

SRV - покажчик на сервер, держатель якого-небудь сервісу (використовується для сервісів AD і, наприклад, для Jabber). Крім імені сервера містить такі поля як Priority (пріоритет) - аналогічний такому ж у MX, Weight (вага) - використовується для балансування навантаження між серверами з однаковим пріоритетом - клієнти вибирають сервер випадковим чином з ймовірністю на основі ваги і Port Number - номер порту, на якому сервіс «слухає» запити.

Всі перераховані вище типи записів зустрічаються в зоні прямого перегляду (forward lookup zone) DNS. Є ще зона зворотного пошуку (reverse lookup zone) - там зберігаються записи типу PTR - PoinTeR - запис протилежна типу A. Зберігає зіставлення IP-адреси його символьному імені. Потрібна для обробки зворотних запитів - вказати назву хоста по його IP-адресою. Не потрібно для функціонування DNS, але потрібна для різних діагностичних утиліт, а також для деяких видів антиспам-захисту в поштових сервісах.

Крім того, самі зони, що зберігають в собі інформацію про домен, бувають двох типів (класично):

Основна (primary) - являє собою текстовий файл, що містить інформацію про хостах і сервісах домену. Файл можна редагувати.

Додаткова (secondary) - теж текстовий файл, але, на відміну від основної, редагування не підлягає. Стягується автоматично з сервера, що зберігає основну зону. Збільшує доступність і надійність.

Для реєстрації домену в інтернет, треба щоб інформацію про нього зберігали, мінімум, два DNS-сервера.

У Windows 2000 з'явився такий тип зони як Інтегрована в AD - зона зберігається не в текстовому файлі, а в базі даних AD, що дозволяє їй реплицироваться на інші контролери доменів разом з AD, використовуючи її механізми реплікації. Основним плюсом даного варіанту є можливість реалізації безпечної динамічної реєстрації в DNS. Тобто записи про себе можуть створити тільки комп'ютери - члени домену.

У Windows 2003 з'явилася також Stub-зона - зона-заглушка . Вона зберігає інформацію тільки про DNS-серверах, які є повноважними для даного домену. Тобто, NS-записи. Що схоже за змістом на умовну пересилання ( Conditional forwarding ), яка з'явилася в цій же версії Windows Server, але список серверів, на який пересилаються запити, оновлюється автоматично.

Ітеративний і рекурсивний запити.

Зрозуміло, що окремо взятий DNS-сервер не знає про всі доменах в інтернеті. Тому, при отриманні запиту на невідомий йому адресу, наприклад metro. yandex. ru, ініціюється наступна послідовність ітерацій:

DNS-сервер звертається до одного з кореневих серверів інтернету, які зберігають інформацію про повноважних власниках доменів першого рівня або зон (ru, org, com і т. Д.). Отриманий адресу повноважного сервера він повідомляє клієнту.

Клієнт звертається до власника зони ru з тим же запитом.

DNS-сервер зони RU шукає у себе в кеші відповідний запис і, якщо не знаходить, повертає клієнту адресу сервера, що є повноважним для домену другого рівня - в нашому випадку yandex. ru

Клієнт звертається до DNS yandex. ru з тим же запитом.

DNS яндекса повертає потрібну адресу.

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

Клієнт, як правило, звертається із запитом, що мають прапор «потрібно рекурсія».

2. Трохи про формат повідомлення DNS

Повідомлення складається з 12-байтного заголовка, за яким йдуть 4 поля змінної довжини.

Тема складається з наступних полів:

Формат DNS-повідомлення

Ідентифікація - в це поле клієнтом генерується якийсь ідентифікатор, який потім копіюється в відповідне поле відповіді сервера, щоб можна було зрозуміти на який запит прийшла відповідь.

Прапори - 16-бітове поле, поділене на 8 частин:

  • QR (тип повідомлення), 1-бітове поле: 0 позначає - запит, 1 позначає - відгук.
  • Opcode (код операції), 4-бітове поле. Звичайне значення 0 (стандартний запит). Інші значення - це 1 (інверсний запит) і 2 (запит статусу сервера).
  • AA - 1-бітовий прапор, який означає «авторитетну відповідь» (authoritative answer). Сервер DNS має повноваження для цього домену в розділі питань.
  • TC - 1-бітове поле, яке означає «обрізано» (truncated). У разі UDP це означає, що повний розмір відгуку перевищив 512 байт, проте були повернуті тільки перші 512 байт відгуку.
  • RD - 1-бітове поле, яке означає «потрібно рекурсія» (recursion desired). Біт може бути встановлений в запиті і потім повернутий у відгуку. Цей прапор вимагає від DNS сервера обробити цей запит самому (т. Е. Сервер повинен сам визначити необхідний IP адреса, а не повертати адресу іншого DNS сервера), що називається рекурсивним запитом (recursive query). Якщо цей біт не встановлений і запитуваний сервер DNS не має авторитетного відповіді, запитуваний сервер поверне список інших серверів DNS, до яких необхідно звернутися, щоб отримати відповідь. Це називається повторюваним запитом (iterative query). Ми розглянемо приклади обох типів запитів в наступних прикладах.
  • RA - 1-бітове поле, яке означає «рекурсія можлива» (recursion available). Цей біт встановлюється в 1 у відгуку, якщо сервер підтримує рекурсію. Ми побачимо в наших прикладах, що більшість серверів DNS підтримують рекурсію, за винятком кількох кореневих серверів (Конєв сервера не в змозі обробляти рекурсивні запити через свою завантаженість).
  • 0 - Це 3-бітове поле має дорівнювати 0.
  • Rcode це 4-бітове поле коду повернення. Звичайні значення: 0 (немає помилок) і 3 (помилка імені). Помилка імені повертається тільки від повноважного сервера DNS і означає, що ім'я домену, вказаного в запиті, не існує.

Наступні чотири 16-бітних поля вказують на кількість пунктів в чотирьох полях змінної довжини, які завершують запис. У запиті кількість питань (number of questions) звичайно дорівнює 1, а

Інші три лічильника рівні 0. У відгуку кількість відповідей (number of answers) щонайменше дорівнює 1, а решта два лічильника можуть бути як нульовими, так і ненульовими.

Приклад (отриманий за допомогою WinDump при виконанні команди ping www. Ru):

IP KKasachev-nb. itcorp. it. ru.51036> ns1.it. ru.53: 36587+ A? www. ru. (24)

IP ns1.it. ru.53> KKasachev-nb. itcorp. it. ru.51036: 36587 1/2/5 A 194.87.0.50 (196)

Перший рядок - запит: ім'я мого ПК, 51036 - випадково обраний порт відправки, 53- заздалегідь відомий порт DNS-сервера, 36587 - ідентифікатор запиту, + - «потрібно рекурсія», А - запит записи типу А, знак питання буде означати, що це запит, а не відповідь. У дужках - довжина повідомлення в байтах.

Другий рядок - відповідь сервера: на вказаний вихідний порт із зазначеним ідентифікатором запиту. Відповідь містить одну RR (ресурсну запис DNS), що є відповіддю на запит, 2 записи повноважень і 5 якихось додаткових записів. Загальна довжина відповіді - 196 байт.

3. TCP і UDP

На слуху відомості про те, що DNS працює по протоколу UDP (порт 53). Це дійсно за замовчуванням так - запити і відповіді відправляються по UDP. Однак, вище згадується наявність в заголовку повідомлення прапора TC (Truncated). Він виставляється в 1, якщо розмір відгуку перевищив 512 байт - межа для UDP-відгуку - а значить був обрізаний і клієнтові прийшли тільки перші 512 байт. У цьому випадку клієнт повторює запит, але вже по TCP, який зважаючи на свою специфіку, може безпечно передати великі обсяги даних.

Також передача зон від основних серверів до додаткових здійснюється по TCP, оскільки в цьому випадку передається куди більше 512 байт.

4. DNS в Windows Server 2008 і 2012

У Windows 2008 з'явилися наступні можливості:

Фонове завантаження зон

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

DNS-сервер з ОС Windows Server 2008 тепер під час перезавантаження завантажує дані зони з доменних служб Active Directory в фоновому режимі, завдяки чому може при цьому обробляти запити даних з інших зон. При запуску DNS-сервера виконуються наступні дії:

  • Визначаються всі зони, які повинні бути завантажені;
  • З файлів або сховища доменних служб Active Directory завантажуються кореневі посилання;
  • Завантажуються всі зони з файлової підтримкою, тобто зони, що зберігаються в файлах, а не в доменних службах Active Directory;
  • Починається обробка запитів і віддалених викликів процедур (RPC);
  • Створюються один або кілька потоків для завантаження зон, що зберігаються в доменних службах Active Directory.

Оскільки завдання завантаження зон виконується окремими потоками, DNS-сервер може обробляти запити під час завантаження зони. Якщо DNS-клієнт запитує дані для вузла в зоні, який вже завантажений, DNS-сервер відправляє у відповідь дані (або, якщо це доречно, негативну відповідь). Якщо запит виконується для вузла, який ще не завантажений в пам'ять, DNS-сервер зчитує дані вузла з доменних служб Active Directory і оновлює відповідним чином список записів вузла.

Підтримка IPv6-адрес

Протокол Інтернету версії 6 (IPv6) визначає адреси, довжина яких становить 128 біт, на відміну від адрес IP версії 4 (IPv4), довжина яких становить 32 біта.

DNS-сервери з ОС Windows Server 2008 тепер повністю підтримують як IPv4-адреси, так і IPv6-адреси. Засіб командного рядка dnscmd також приймає адреси в обох форматах. Список серверів пересилки може містити і IPv4-адреси, і IPv6-адреси. DHCP-клієнти також можуть реєструвати IPv6-адреси поряд з IPv4-адресами (або замість них). Нарешті, DNS-сервери тепер підтримують простір імен домену ip6.arpa для зворотного зіставлення.

Зміни DNS-клієнта

Дозвіл імен LLMNR

Комп'ютери клієнтів DNS можуть використовувати дозвіл імен LLMNR (Link-local Multicast Name Resolution), яке також називають многоадресной системою DNS або mDNS, для розпізнавання імен в сегменті локальної мережі, де недоступний DNS-сервер. Наприклад, при ізоляції підмережі від всіх DNS-серверів в мережі через збій в роботі маршрутизатора клієнти в цій підмережі, що підтримують дозвіл імен LLMNR, як і раніше можуть дозволяти імена за допомогою тимчасової схеми до відновлення з'єднання з мережею.

Крім дозволу імен в разі збою в роботі мережі функція LLMNR може також виявитися корисною при розгортанні мереж із, наприклад, в залах очікування аеропортів.

Зміни Windows 2012 в частині DNS торкнулися, переважно, технології DNSSEC (забезпечення безпеки DNS за рахунок додавання цифрових підписів до записів DNS), зокрема - забезпечення динамічних оновлень, які були недоступні, при включенні DNSSEC в Windows Server 2008.

5. DNS і Active directory

Active Directory дуже сильно спирається в своїй діяльності на DNS. З його допомогою контролери домену шукають один одного для реплікації. З його допомогою (і служби Netlogon) клієнти визначають контролери домену для авторизації.

Для забезпечення пошуку, в процесі підняття на сервері ролі контролера домену, його служба Netlogon реєструє в DNS відповідні A і SRV записи.

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

_ldap._tcp. DnsDomainName

_ldap._tcp. SiteName._sites. DnsDomainName

_ldap._tcp. dc._msdcs. DnsDomainName

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

_ldap._tcp. pdc._msdcs. DnsDomainName

_ldap._tcp. gc._msdcs. DnsForestName

_ldap._tcp. SiteName._sites. gc._msdcs. DnsForestName

_gc._tcp. DnsForestName

_gc._tcp. SiteName._sites. DnsForestName

_ldap._tcp. DomainGuid. domains._msdcs. DnsForestName

_kerberos._tcp. DnsDomainName.

_kerberos._udp. DnsDomainName

_kerberos._tcp. SiteName._sites. DnsDomainName

_kerberos._tcp. dc._msdcs. DnsDomainName

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

_kpasswd._tcp. DnsDomainName

_kpasswd._udp. DnsDomainName

Перша частина А SRV ідентифікує службу, на яку вказує запис SRV. Існують наступні служби:

_ldap - Active Directory є службою каталогу, сумісної з LDAP-протоколом, з контролерами домену, що функціонують як LDAP-сервери. Записи _ldap SRV ідентифікує LDAP сервери, наявні в мережі. Ці сервери можуть бути контролерами домену Windows Server 2000 + або іншими LDAP-серверами;

_kerberos - А SRV _kerberos ідентифікують всі ключові центри розподілу (KDC - Key Distribution Centers) в мережі. Вони можуть бути контролерами домена з Windows Server 2003 або іншими KDC-серверами;

_kpassword - ідентифікує сервери зміни паролів kerberos в мережі;

_gc - запис, що відноситься до функції глобального каталогу в Active Directory.

У піддомені _mcdcs реєструються тільки контролери домену Microsoft Windows Server. Вони роблять і основні записи і записи в даному піддомені. Ні-Microsoft-служби роблять тільки основні записи.

Записи, що містять ідентифікатор сайту SiteName, потрібні для того щоб клієнт міг знайти контролер домену для авторизації в своєму сайті, а не ліз авторізовиваться в інше місто через повільні канали.

DomainGuid - глобальний ідентифікатор домену. Запис, содержащщая його, потрібна на випадок перейменування домену.

Як відбувається процес пошуку DC

Під час входу користувача, клієнт ініціює DNS-локатор, за допомогою віддаленого виклику процедури (Remote Procedure Call - RPC) службою NetLogon. В якості вихідних даних в процедуру передаються ім'я комп'ютера, назва домену і сайту.

Служба посилає один або кілька запитів за допомогою API функції DsGetDcName ()

DNS сервер повертає запитаний список серверів, розсортоване відповідно до пріоритету та вазі. Потім клієнт посилає LDAP запит, використовуючи UDP-порт 389 по кожному з адрес записи в тому порядку, як вони були повернуті.

Всі доступні контролери доменів відповідають на цей запит, повідомляючи про свою працездатності.

Після виявлення контролера домену, клієнт встановлює з ним з'єднання з LDAP для отримання доступу до Active Directory. Як частина їх діалогу, контролер домену визначає до в якому сайті розміщується клієнт, на основі його IP адреси. І якщо з'ясовується, що клієнт звернувся не до найближчого DC, а, наприклад, переїхав недавно в інший сайт і за звичкою запросив DC зі старого (інформація про сайт кешируєтся на клієнті за результатами останнього успішного входу), контролер висилає йому назву його (клієнта) нового сайту. Якщо клієнт вже намагався знайти контролер в цьому сайті, але безуспішно, він продовжує використовувати знайдений. Якщо немає, то ініціюється новий DNS-запит із зазначенням нового сайту.

Служба Netlogon кешируєт інформацію про місцезнаходження контролера домену, щоб не ініціювати всю процедуру при кожній необхідності звернення до DC. Однак, якщо використовується «неоптимальний» DC (розташований в іншому сайті), клієнт очищає цей кеш через 15 хвилин і ініціює пошуки заново (в спробі знайти свій оптимальний контролер).

Якщо у ком'ютера відсутня в кеші інформація про його сайті, він буде звертатися до будь-якого контролера домену. Для того щоб припинити таку поведінку, на DNS можна налаштувати NetMask Ordering. Тоді DNS видасть список DC в такому порядку, щоб контролери, розташовані в тій же мережі, що і клієнт, були першими.

Приклад: Dnscmd / Config / LocalNetPriorityNetMask 0x0000003F вкаже маску підмережі 255.255.255.192 для пріоритетних DC. За замовчуванням використовується маска 255.255.255.0 (0x000000FF)