Що таке DNS та ієрархія DNS? Повний технічний посібник

DNS (Domain Name System) — це ієрархічна розподілена система іменування, яка перетворює зрозумілі людині доменні імена — наприклад, `www.example.com` — на машиночитані IP-адреси, як-от `192.0.2.1`. Без DNS кожному користувачу інтернету довелося б запам’ятовувати числові адреси кожного веб-сайту, кінцевої точки API або поштового сервера. DNS — це протокол, який робить сучасний інтернет зручним для навігації у великих масштабах.

У своїй основі DNS функціонує як глобально розподілена база даних. Запити вирішуються через структуровану ланцюжок делегування — від кореневих серверів на вершині, через сервери доменів верхнього рівня (TLD), аж до авторитетних серверів імен, які зберігають фактичні записи для конкретного домену. Саме ця архітектура робить DNS одночасно швидким, стійким і розширюваним.

Чому DNS — це більше, ніж просто «телефонна книга»

Аналогія з «телефонною книгою» є корисною відправною точкою, але вона суттєво применшує те, що DNS насправді робить у виробничих середовищах. DNS лежить в основі:

• Розпізнавання імен — перетворення FQDN (повністю кваліфікованих доменних імен) на IPv4- та IPv6-адреси
• Маршрутизації електронної пошти — MX-записи спрямовують SMTP-трафік до правильної поштової інфраструктури
• Виявлення сервісів — SRV-записи дозволяють застосункам динамічно знаходити сервіси (широко використовується в SIP, XMPP та Kubernetes)
• Управління трафіком — Geo-DNS та записи зваженої маршрутизації забезпечують глобальне балансування навантаження та перемикання на резервний вузол на основі затримки
• Забезпечення безпеки — TXT-записи містять політики SPF, DKIM та DMARC; DNSSEC додає криптографічну перевірку
• Оркестрування CDN — вирівнювання CNAME та маршрутизація Anycast дозволяють CDN прозоро обслуговувати найближчий граничний вузол

Для тих, хто керує середовищем VPS Хостингу або Виділеного Сервера, розуміння DNS на цьому рівні є обов’язковим — неправильно налаштований DNS є однією з найпоширеніших першопричин збоїв застосунків, проблем з доставкою електронної пошти та помилок при видачі SSL-сертифікатів.

Процес розпізнавання DNS: покроково

Коли користувач вводить `www.example.com` у браузер, відбувається наступна послідовність дій. Розуміння кожного кроку є критично важливим для діагностики збоїв розпізнавання та оптимізації стратегій TTL.

Крок 1: Перевірка локального кешу

Операційна система спочатку перевіряє свій локальний кеш DNS (заповнений з попередніх запитів). У Linux це може включати `systemd-resolved` або `nscd`. У Windows цей кеш підтримує служба DNS Client. Якщо існує дійсний кешований запис у межах його TTL, розпізнавання зупиняється тут.

Крок 2: Від stub-резолвера до рекурсивного резолвера

Якщо в локальному кеші немає збігу, stub-резолвер ОС пересилає запит до рекурсивного DNS-резолвера — зазвичай це резолвер вашого провайдера або налаштований публічний резолвер, наприклад:

• Google Public DNS: `8.8.8.8` / `8.8.4.4`
• Cloudflare: `1.1.1.1` / `1.0.0.1`
• Quad9: `9.9.9.9`

Рекурсивний резолвер виконує основну роботу з обходу ієрархії DNS від імені клієнта.

Крок 3: Запит до кореневого сервера

Якщо рекурсивний резолвер не має кешованої відповіді, він надсилає запит до одного з 13 кластерів кореневих серверів (адресованих як `a.root-servers.net` до `m.root-servers.net`). Це не 13 окремих машин — це 13 груп Anycast-адрес, якими керують такі організації, як ICANN, Verisign, NASA та RIPE NCC, з понад 1 500 фізичними екземплярами, розподіленими по всьому світу.

Кореневий сервер не повертає IP-адресу. Він повертає перенаправлення — адресу авторитетного TLD-сервера для запитуваного суфікса (наприклад, `.com`).

Крок 4: Запит до TLD-сервера

Рекурсивний резолвер надсилає запит до відповідного сервера імен TLD. Для `.com` ним керує Verisign. TLD-сервер повертає ще одне перенаправлення — авторитетні сервери імен для конкретного домену другого рівня (наприклад, `ns1.example.com`).

Крок 5: Запит до авторитетного сервера імен

Рекурсивний резолвер надсилає запит до авторитетного сервера імен, який зберігає файл зони для `example.com`. Цей сервер повертає фактичний DNS-запис — наприклад, A-запис, що відображає `www.example.com` на `93.184.216.34`.

Крок 6: Кешування відповіді та доставка

Рекурсивний резолвер кешує відповідь відповідно до значення TTL (Time to Live) запису, а потім повертає IP-адресу stub-резолверу клієнта, який передає її браузеру. Після цього браузер відкриває TCP-з’єднання (або QUIC для HTTP/3) до цієї IP-адреси.

Важливий нюанс: значення TTL встановлюються власником домену на авторитетному сервері. TTL у 300 секунд означає, що запис може бути кешований протягом 5 хвилин перед повторним запитом. Під час міграції або реагування на інцидент завчасне зниження TTL (до 60–300 секунд) є стандартною операційною практикою для мінімізації затримок поширення.

Ієрархія DNS: архітектура та компоненти

Простір імен DNS структурований як перевернуте дерево. Кожен вузол у дереві є міткою, а повний шлях від листа до кореня утворює доменне ім’я. Крапка в кінці `www.example.com.` представляє корінь.

Рівень 1: Коренева зона

Коренева зона є вершиною ієрархії DNS, представленою порожньою міткою (`.`). Вона містить NS-записи, що вказують на TLD-сервери для кожного існуючого домену верхнього рівня. Файл кореневої зони підтримується IANA (Internet Assigned Numbers Authority) і наразі містить делегування для понад 1 500 TLD.

Кореневі сервери працюють за моделлю якоря довіри — ланцюжки перевірки DNSSEC в кінцевому підсумку завершуються на ключі підпису ключів (KSK) кореневої зони, яким керують через ретельно перевірений церемоніальний процес.

Рівень 2: Домени верхнього рівня (TLD)

TLD-сервери є авторитетними для всіх доменів, зареєстрованих під їхнім суфіксом. Існує кілька категорій:

Рівень 3: Домени другого рівня (SLD) та субдомени

Домен другого рівня — це мітка безпосередньо ліворуч від TLD — `example` у `example.com`. Це одиниця, яку реєстранти доменів купують і якою керують. Коли ви реєструєте домен через такий сервіс, як Реєстрація доменів, ви отримуєте право керувати делегуванням DNS для цього SLD.

Субдомени — це мітки, що додаються перед SLD (`www`, `mail`, `api`, `blog`). Вони налаштовуються повністю у файлі зони авторитетного сервера імен — додаткова реєстрація не потрібна. Глибина субдоменів теоретично необмежена, хоча існують практичні обмеження (загальна довжина FQDN не повинна перевищувати 253 символи; кожна мітка не повинна перевищувати 63 символи).

Рівень 4: Авторитетні сервери імен та файли зон

Авторитетні сервери імен є джерелом істини для DNS-записів домену. Вони відповідають на запити з встановленим прапором AA (Authoritative Answer). Файл зони — це текстова база даних, що містить усі ресурсні записи для домену.

Ключові типи DNS-записів, які повинен знати кожен адміністратор:

CAA-записи заслуговують на особливу увагу: це часто ігнорований засіб контролю безпеки, який запобігає несанкціонованій видачі SSL-сертифікатів для вашого домену центрами сертифікації. Якщо ваш CAA-запис не містить CA, яким ви користуєтесь, видача сертифіката завершиться невдачею.

Рекурсивні резолвери та авторитетні сервери: критична відмінність

Ці два компоненти є архітектурно різними і часто плутаються новачками.

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

DNSSEC: криптографічна цілісність для ланцюжка DNS

Стандартний DNS не має вбудованої автентифікації — відповіді можуть бути підроблені через атаки отруєння кешу (найвідомішою є атака Камінського). DNSSEC (DNS Security Extensions) вирішує цю проблему, додаючи цифрові підписи до DNS-записів.

Ланцюжок довіри DNSSEC працює наступним чином:

1. Кожна зона підписує свої записи за допомогою ключа підпису зони (ZSK)
2. Відкритий ключ ZSK публікується як запис DNSKEY
3. Батьківська зона підписує хеш DNSKEY дочірньої зони, створюючи запис DS (Delegation Signer)
4. Цей ланцюжок тягнеться від кореневої зони (кінцевого якоря довіри) до окремих записів

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

Операційне застереження: DNSSEC значно збільшує складність управління зоною. Ротація ключів, закінчення терміну дії підписів та синхронізація DS-записів з батьківською зоною є поширеними причинами збоїв. Завжди тестуйте конфігурацію DNSSEC за допомогою таких інструментів, як `dnsviz.net`, перш ніж вмикати її у виробничому середовищі.

DNS у хостингових середовищах: практичні міркування

Поширення та TTL

«Поширення DNS» — широко вживаний у неправильному значенні термін. Насправді відбувається закінчення терміну дії TTL у кешах. Коли ви змінюєте A-запис, резолвери, які кешували старе значення, продовжуватимуть його обслуговувати до закінчення TTL. У стандартному DNS немає активного механізму «проштовхування».

Щоб мінімізувати простій під час міграцій:

1. Знизьте TTL відповідних записів до 300 секунд щонайменше за 24–48 годин до змін (дозволяючи існуючим кешам закінчити термін дії)
2. Внесіть зміни до DNS
3. Після підтвердження стабільності нової конфігурації відновіть TTL до виробничого значення (3600–86400 секунд)

Split-Horizon DNS

У середовищах з публічними та приватними мережевими сегментами — що є поширеним на VPS Хостингу або Виділених Серверах — split-horizon DNS (також відомий як split-brain DNS) надає різні відповіді залежно від джерела запиту. Внутрішні клієнти розпізнають `db.example.com` як приватну адресу RFC 1918; зовнішні клієнти отримують публічну IP-адресу або адресу балансувальника навантаження. Це реалізується в BIND за допомогою директив `view` або в PowerDNS через Lua-скриптинг.

Зворотний DNS (PTR-записи)

Зворотний DNS відображає IP-адреси назад на імена хостів за допомогою зон `in-addr.arpa` (IPv4) або `ip6.arpa` (IPv6). PTR-записи є критично важливими для:

• Доставки електронної пошти — багато поштових серверів-одержувачів відхиляють або суттєво знижують рейтинг пошти з IP-адрес без відповідних PTR-записів
• Журналювання безпеки — збагачення журналів брандмауера та журналів доступу іменами хостів
• Відповідності вимогам — деякі нормативні рамки вимагають зворотного DNS для аудиторських слідів

Якщо ви налаштовуєте Поштовий Хостинг або самостійно керований поштовий сервер, переконайтеся, що ваш хостинг-провайдер налаштував PTR-запис для IP-адреси вашого сервера.

DNS та видача SSL-сертифікатів

Виклики DNS-01 ACME (що використовуються Let’s Encrypt та іншими CA) вимагають запису певного TXT-запису до зони вашого домену для підтвердження контролю над доменом. Цей метод є обов’язковим для видачі wildcard-сертифікатів. Автоматизоване управління сертифікатами (через `certbot` або `acme.sh`) вимагає API-доступу до вашого DNS-провайдера для програмного створення та видалення цих TXT-записів.

Поширені режими збоїв DNS та діагностика

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

NXDOMAIN — запитуване ім’я не існує в зоні. Поширені причини: помилка друку в імені запису, зона не завантажена або делегування вказує на неправильні сервери імен.

SERVFAIL — сервер не зміг виконати запит. Поширені причини: збій перевірки DNSSEC, недоступні авторитетні сервери або пошкоджений файл зони (синтаксична помилка в записах SOA або NS).

Застарілий кеш — резолвер обслуговує застарілий або неактуальний запис. Використовуйте `dig +nocache` або надсилайте запити безпосередньо до авторитетного сервера, щоб обійти кеші резолверів.

Некоректне делегування — NS-записи батьківської зони вказують на сервери імен, які насправді не є авторитетними для зони (не мають завантаженої зони). Це прихований режим збою, що спричиняє переривчасті помилки розпізнавання.

Основні діагностичні команди:

“`bash

Query a specific resolver for an A record

dig @8.8.8.8 www.example.com A

Trace the full resolution path from root

dig +trace www.example.com

Check authoritative answer directly

dig @ns1.example.com www.example.com A +norec

Verify reverse DNS

dig -x 93.184.216.34

Check DNSSEC chain

dig www.example.com A +dnssec

Inspect SOA record (useful for checking serial after zone update)

dig example.com SOA

“`

Оптимізація продуктивності DNS

• Розгортання Anycast — авторитетні сервери, розгорнуті через Anycast, відповідають з географічно найближчого вузла, зменшуючи затримку запитів
• Налаштування TTL — вищі TTL (3600–86400 с) зменшують навантаження на резолвер і покращують частоту влучань у кеш для стабільних записів; нижчі TTL (60–300 с) забезпечують швидше перемикання на резервний вузол для динамічної інфраструктури
• Негативне кешування — відповіді NXDOMAIN кешуються на тривалість, вказану в полі мінімального TTL SOA; надмірно довгі негативні TTL затримують відновлення після неправильної конфігурації
• EDNS Client Subnet (ECS) — дозволяє рекурсивним резолверам пересилати частину IP клієнта до авторитетних серверів, забезпечуючи більш точні рішення щодо гео-маршрутизації (за рахунок певної приватності)
• DNS over HTTPS (DoH) / DNS over TLS (DoT) — шифрує DNS-запити під час передачі, запобігаючи перехопленню та маніпуляціям на рівні провайдера; дедалі важливіше для розгортань, чутливих до приватності

Матриця рішень: вибір правильної конфігурації DNS

Технічні ключові висновки

• Розпізнавання DNS — це багатоетапний ланцюжок делегування: stub-резолвер > рекурсивний резолвер > корінь > TLD > авторитетний сервер
• 13 кластерів кореневих серверів (не окремих машин) використовують Anycast для обслуговування понад 1 500 фізичних екземплярів по всьому світу
• TTL контролює тривалість кешування — «поширення» — це просто очікування закінчення терміну дії кешів, а не активне проштовхування
• Авторитетні сервери зберігають файли зон; рекурсивні резолвери кешують і пересилають — ніколи не плутайте ці дві ролі
• DNSSEC додає криптографічну перевірку, але вносить операційну складність; ротація ключів та синхронізація DS є поширеними точками збоїв
• PTR-записи є обов’язковими для розгортань поштових серверів та журналювання безпеки
• CAA-записи обмежують, які центри сертифікації можуть видавати SSL-сертифікати для вашого домену
• Некоректні делегування та застарілі негативні кеші є одними з найнебезпечніших режимів збоїв DNS
• Завжди використовуйте `dig +trace` для діагностики проблем розпізнавання від кореня вниз, а не покладайтеся на вивід на рівні резолвера

Часті запитання

У чому різниця між рекурсивним резолвером та авторитетним DNS-сервером?

Рекурсивний резолвер надсилає запити до ієрархії DNS від імені клієнта та кешує відповіді. Авторитетний DNS-сервер зберігає фактичний файл зони для домену та повертає остаточні відповіді з встановленим прапором AA. Це архітектурно окремі ролі, хоча технічно один демон може виконувати обидві.

Чому поширення DNS займає так багато часу після зміни запису?

DNS не «поширюється» в активному сенсі. Резолвери кешують записи на тривалість TTL, встановленого для запису. Якщо ваш A-запис має TTL 86400 секунд (24 години), резолвери, що кешували старе значення, продовжуватимуть його обслуговувати до 24 годин. Щоб мінімізувати це, знизьте TTL до 300 секунд щонайменше за 24 години до внесення змін.

Що спричиняє відповідь SERVFAIL і як це виправити?

SERVFAIL найчастіше виникає через збій перевірки DNSSEC, недоступні авторитетні сервери імен або пошкоджений/неправильно сформований файл зони. Використовуйте `dig +dnssec` для перевірки проблем DNSSEC, переконайтеся, що ваші авторитетні сервери доступні та відповідають, і перевірте синтаксис файлу зони за допомогою `named-checkzone`.

Чи потрібен мені DNSSEC для мого домену?

DNSSEC настійно рекомендується для доменів, що обробляють конфіденційні транзакції, поштову інфраструктуру або фінансові послуги. Він запобігає атакам отруєння кешу. Однак він додає операційне навантаження — ротація ключів та управління DS-записами вимагають ретельної автоматизації. Для більшості виробничих доменів переваги безпеки переважають складність.

Які DNS-записи необхідні для функціонального поштового сервера?

Як мінімум: MX-запис, що вказує на ім’я хоста вашого поштового сервера, A-запис, що розпізнає це ім’я хоста, PTR-запис для IP-адреси сервера (налаштований вашим хостинг-провайдером), та TXT-записи для SPF, DKIM та DMARC. Відсутність будь-якого з них призведе до проблем з доставкою або прямого відхилення поштовими серверами-одержувачами.