Шпаргалка по DNS

Наша взаимовыгодная связь https://banwar.org/

prchecker.info

З сервісом доменних імен вже всі знайомі давним давно. Це одна з найбільш «корисних» служб, призначення якої навіть для звичайного користувача більш ніж очевидно. Мало хто добре розбирається в тому, як DNS реально працює і що стоїть за «простим» дозволом імен з імені в ip-адреса (і не тільки). Повинен зізнатися, що я і сам розумію не всі нюанси, оскільки за специфікою своєї роботи кожен день з DNS не стикався (вписувати сервери DNS в мережеві настройки не вважається). Крім того, навіть якщо вдається в чомусь розібратися, всі дуже швидко забувається. Адже в корпоративній мережі DNS одна з тих служб, які налаштував і забув.

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

Для початку необхідно все розкласти по поличках:

«Згідно з керівними матеріалами (RFC-1034, RFC-1035) система доменних імен складається з трьох основних частин:

• Всього безлічі доменних імен (domain name space)
• Серверів доменних імен (domain name servers)
• Клієнти DNS (Resolver-и) »

Структура безлічі доменних імен вдає із себе деревоподібну ієрархію. Щоб не ускладнювати спочатку досить просту річ, я підібрав найбільш підходящу картинку з описом ієрархії доменних імен:

Класифікація доменних імен також не повинна викликати складнощів в розумінні, але на подив в інтернеті практично не знайти нормальні ілюстрації. Мені під руки попалася тільки одна:

Взагалі на цьому каналі величезна кількість уроків, які присвячені саме DNS. Однозначно раджу до перегляду. Хоч і опис типів dns-серверів є і на Вікіпедії, воно там плоске і тільки даремно зводить з пантелику.

Питань хто такі dns-клієнти виникати не повинно.

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

Є кілька типів авторитативні dns-серверів: primary master, master, slave. Чіткі відмінності є тільки між primary master і slave. Суть в тому, що в першому випадку сервер стоїть на чолі ієрархії, на ньому можна виробляти зміни опису зони і цей сервер ніколи не буде копіювати цю зону з інших серверів. Slave-сервери навпаки є лише вторинними і копіюють зону з primary master; їх головне завдання - балансування навантаження, резервування. Визначення типу серверів master для мене трохи важко. На багатьох джерелах ці сервери також називають основними:

«Опис зони master-сервера є первинним, тому що його створює вручну адміністратор зони. Відповідно, вносити зміни в опис зони може тільки адміністратор даного сервера. Всі інші сервери тільки копіюють інформацію з master-сервера. »

... але, з іншого боку, цьому суперечить визначення primary-master навіть з тих же джерел:

«Для того щоб виділити сервер, який не копіює зони ні з якого іншого сервера, вводять поняття Primary Master.»

Тобто по факту не на всіх master-серверах можна вносити зміни в опис зони, а тільки на одному єдиному master-сервері, який називається primary master. В такому випадку реально існує тільки два «статичних» типу сервера - primary master і slave. Роль master може бути у сервера лише якийсь певний короткий проміжок часу - коли один slave-сервер (нехай він буде названий Сервер 1) копіює інформацію з іншого slave-сервера (Сервер 2). В цьому випадку Сервер 2 має право називатися master-сервером для Сервер 1, але це справедливо тільки для конкретно взятого процесу копіювання зони. Коли ж Сервер 2 буде копіювати опис зони з єдиного primary master, він знову буде slave-сервером. Це підтверджує ілюстрація з nic.ru:

Ось таки роздуми. Звичайно всі ці визначення швидше заплутують, ніж допомагають розібратися. Треба просто мати на увазі, що є primary master і він стоїть вгорі ієрархії і є всі інші. Варто додати, що сервери всіх трьох типів будуть авторитативні, тобто відповідальними за зону.

На чолі всієї ієрархії доменних імен стоять сервери, які обслуговують кореневу зону, вони називаються кореневими серверами. Саме до них в першу чергу звертаються всі інші dns-сервери, якщо у них немає даних про будь-яке доменне ім'я. В ієрархії доменних імен на першому малюнку в статті вони знаходяться на рівні «. «.

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

Таким чином, простір імен роздроблене на зони (zones), кожна з яких керується своїм доменом. Зверніть увагу на відмінність між зоною (zone) і доменом (domain): домен groucho.edu зачіпає всі машини в університеті Groucho Marx, в той час як зона groucho.edu включає тільки хости, які працюють в безпосередньо комп'ютерному центрі, наприклад у відділі математики . Хост в відділі фізики належать іншій зоні, а саме physics.groucho.edu.

На мій погляд більш точно і зрозуміло сказано в статті на nic.ru, яка згадувалася в самому початку:

Домен - це все безліч машин, які відносяться до одного і того ж доменному імені. Наприклад, всі машини, які в своєму імені мають постфікси kiae.su відносяться до домену kiae.su. Зона - це «зона відповідальності» конкретного сервера доменних імен, тобто поняття домену ширше, ніж поняття зони. Якщо домен розбивається на домени, то у кожного з них може з'явитися свій сервер. При цьому зоною відповідальності сервера більш високого рівня буде тільки та частина опису домену, яка делегували інших серверів. Розбиття домена на піддомени і організація сервера для кожного з них називається делегування прав управління зоною відповідного серверу доменних імен, або просто делегуванням зони.

Запити до dns-серверів бувають двох типів - рекурсивний і нерекурсивний (ітеративний). Найбільш докладно принцип роботи описується на згаданому вище каналі Youtube. При рекурсивном запиті клієнт звертається до предпочитаемому dns-сервера і той, якщо не знає відповіді, починає по черзі опитувати відповідальних за зони сервери, починаючи з кореневих і далі опускаючись нижче по ієрархії. Вичерпне пояснення роботи рекурсивного запиту дається в статті на oszone.ru. Ітеративний запит менш поширений. У ньому клієнт сам по черзі опитує dns-сервери, починаючи з кореневих і т.д .. Зрозуміло якщо не знайде результати запиту в своєму кеші.

Наочно рекурсивний запит виглядає так:

а нерекурсивний:

На цьому огляд основних принципів роботи dns закінчений. Розгляд типів записів dns, а також механізмів роботи зворотного дозволу імен (ip-адреса по dns-імені) я в рамках цієї статті я зачіпати не планував, хоча звичайно ж це дуже цікаві теми.

Налаштування ролі dns на Windows Server являє собою досить просту задачу, як і багато інших - додав роль в диспетчері сервера, запустив візарду і все налаштував. Проте зустрічаються парадоксальні ситуації і іноді чуєш розповіді як деякі «адміни» додають одні і ті ж облікові записи користувачів по черзі на кожному контролері домену, не маючи поняття про реплікації. І адже найстрашніше, що у них це виходить! Тобто можна зробити висновок, що контролери домену хоч і підтримують один і той же домен, але фактично один про одного нічого не знають (інакше учетку з аналогічним ім'ям створити б не вийшло). А адже це може бути наслідком неправильно налаштованого ролі DNS, яка зазвичай завжди йде пліч-о-пліч з AD DS.

Цей розділ буде присвячений огляду найкращих практик з налаштування ролі DNS (інтегрованої в AD) на Windows Server 2012 R2, але більшість рад актуальні і для попередніх версій ОС. Проте не варто забувати про поліпшення, які додаються в кожній новій версії і 2012 R2 не виняток.

Я маю на увазі, що немає ніякого сенсу повторювати, що в кожному домені мінімум два контролера домену. Це необхідно для відмовостійкості. Власний ip-адреса сервера повинен бути обов'язково статичним.

Власне самі рекомендації:

1) «If multiple DCs are configured as DNS servers, they should be configured to use each other for resolution first and themselves second».

Суть в тому, що, щоб уникнути проблем з реплікацією, в списку первинних dns-серверів на кожному контролері домену першими повинні бути вказані партнери по реплікації, тобто інші контролери домену. Власну адресу окремо взятого сервера повинен бути вказаний найостаннішим в його списку dns-серверів. Для збільшення продуктивності останнім у списку використовуйте loopback-адреса 127.0.0.1 як власну адресу сервера (але не реальний мережеву адресу адаптера), хоч і це іноді може викликати невеликі проблеми.

2) На клієнтських системах повинні використовуватися тільки локальні dns-сервери, але ніяк не публічні.

В іншому випадку у вас можуть виникнути проблеми з дозволом внутрішніх імен, хоча вихід назовні буде доступний. Проте в корпоративної мережі у мене доступ назовні по dns портам дозволений тільки контролерам домену та серверів Exchange.

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

3) Якщо у вас домен AD, то використовуйте тільки інтегровану з AD роль DNS (AD-integrated). Додасться досить багато плюсів в плані безпеки, продуктивності та відмовостійкості.

Якщо говорити про відмовостійкість, то у вас не буде єдиної точки відмови у вигляді одного primary master-сервера для вашої зони dns (якщо цей сервер вийде з ладу і не буде відразу відновлений або замінений, запити клієнтів на зміну записів розглядатись не будуть. Не те що б це дуже велика проблема для статичного парку пк, але приємного мало). До того ж адміністраторам не доведеться возитися з двома різними схемами реплікації - dns і ad ds; у більш простих і зрозумілих схем надійність зростає в рази.

Продуктивність всієї інфраструктури збільшується, оскільки всі партнери по реплікації (контролери домену) мають однакову вагу і немає master- і slave- серверів. Тобто, якби запит надійшов до slave-сервера класичного dns, то він мав би звернутися до майстра для ініціювання процесу оновлення. При інтегрованої в ad dns кожен контролер домену може писати зміни в базу dns і вже далі не поспішаючи реплицировать їх на інші контролери. До того ж сам по собі механізм реплікації ad ds значно швидше.

Безпека збільшується завдяки захищеним динамічним оновленням. Про DNSSEC мова тут не йде, це загальна технологія, хоча і в Windows є її реалізація.

З кращих практик це напевно все. Є деякі роздуми щодо того, що краще використовувати - кореневі підказки або сервери пересилки, але це скоріше особиста справа адміна, ніж якась усталена практика. Пам'ятайте, що до кореневих серверів ваш dns-сервер виконує ітеративні запити, а до серверів пересилки - рекурсивні, будучи по відношенню до них клієнтом. Root hints сконфігуровані спочатку, тому що вони єдині для всієї мережі інтернет, а forwarder'и доведеться вказати вручну. Єдине, що можна відзначити - не вказуйте в серверах пересилання публічні сервери; нехай краще це будуть dns-ресурси вашого провайдера.

Є також рекомендації (обов'язково до прочитання) щодо автоматичної очищення записів dns. У цій статті я їх детально не розглядаю, оскільки автоматичне очищення записів за замовчуванням відключена. На ділі процес налаштування дуже простий, але має колосальні наслідки для інфраструктури в тому випадку, якщо ви не розумієте що конкретно робите і до чого це може привести.