Що таке DNS і як він працює?

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

В основі своїй DNS — це глобально розподілена ієрархічна база даних. Це не єдиний сервер і не централізований реєстр — це дерево делегування, що охоплює сотні тисяч авторитативних серверів імен по всьому світу, скоординованих через невелику кількість кореневих серверів і регульованих стандартами, визначеними в RFC 1034 та RFC 1035.

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

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

• Маршрутизацію пошти через записи MX, що спрямовують електронну пошту на правильні поштові сервери
• Виявлення сервісів через записи SRV, що використовуються протоколами SIP, XMPP та внутрішньою мережею Kubernetes
• Підтвердження права власності на домен через записи TXT, що використовуються для SPF, DKIM, DMARC та Google Search Console
• Канонічне іменування через записи CNAME, що забезпечують інтеграцію з CDN та балансування навантаження
• Адресацію IPv6 через записи AAAA
• Зворотний пошук через записи PTR у зоні in-addr.arpa, що є критично важливим для репутації поштових серверів та аудиту безпеки
• Валідацію DNSSEC, яка додає криптографічні підписи до відповідей DNS для запобігання отруєнню кешу

Кожного разу, коли ви надсилаєте електронний лист, підключаєтесь до VPN або завантажуєте веб-додаток, DNS у фоновому режимі розв’язує кілька типів записів — нерідко десятки запитів на одне завантаження сторінки.

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

DNS організований у вигляді перевернутого дерева. Розуміння цієї структури є ключовим для розуміння того, як працює розв’язання імен.

.  (Root Zone)
├── com
│   ├── example.com  (Second-Level Domain)
│   │   └── www.example.com  (Subdomain / FQDN)
├── org
├── net
└── uk
    └── co.uk

• Коренева зона (.): Керується IANA. Існує 13 логічних адрес кореневих серверів (від A до M), якими керують такі організації, як Verisign, NASA та ICANN. На практиці вони обслуговуються сотнями фізичних машин через anycast-маршрутизацію.
• Домени верхнього рівня (TLD): Загальні TLD, як-от .com, .net, .org, та національні TLD, як-от .uk, .de, .md. Кожен TLD має власний набір авторитативних серверів імен.
• Домени другого рівня (SLD): Домен, який ви реєструєте, — example.com. Авторитативний DNS для цієї зони контролюється тим, хто зареєстрував домен.
• Субдомени: www, mail, api, staging — це записи всередині зони SLD, повністю підконтрольні власнику домену.

Покроково: як розв’язується DNS-запит

Повне рекурсивне розв’язання DNS передбачає до семи окремих мережевих обмінів. Ось точна послідовність:

Крок 1 — Перевірка кешу браузера

Коли ви вводите www.example.com у браузері, операційна система спочатку перевіряє локальний кеш DNS. У Linux це може керуватися systemd-resolved; у Windows — службою DNS Client. Якщо існує дійсний кешований запис і його TTL (Time to Live) не закінчився, розв’язання зупиняється тут.

Ви можете переглянути локальний кеш DNS у Linux за допомогою:

resolvectl statistics

Або очистити його за допомогою:

sudo resolvectl flush-caches

У Windows:

ipconfig /displaydns
ipconfig /flushdns

Крок 2 — Запит до рекурсивного резолвера

Якщо кешованої відповіді немає, ОС передає запит до налаштованого рекурсивного резолвера (також відомого як рекурсивний DNS-сервер або резолвер повного обслуговування). Зазвичай це:

• Резолвер вашого інтернет-провайдера (призначений через DHCP)
• Публічний резолвер: 8.8.8.8 (Google), 1.1.1.1 (Cloudflare), 9.9.9.9 (Quad9)
• Власний резолвер, наприклад Unbound або BIND, на вашій власній інфраструктурі VPS Hosting

Рекурсивний резолвер виконує основну роботу. Він обходить ієрархію DNS від вашого імені та кешує результати для швидшого обслуговування майбутніх запитів.

Крок 3 — Направлення до кореневого сервера

Рекурсивний резолвер надсилає запит до одного з 13 кластерів кореневих серверів. Кореневий сервер не знає IP-адреси www.example.com. Натомість він повертає направлення — список авторитативних серверів імен для зони TLD .com разом з їхніми IP-адресами (так звані glue-записи).

Крок 4 — Запит до сервера імен TLD

Резолвер надсилає запит до серверів імен TLD .com (якими керує Verisign). Ці сервери також не мають остаточної відповіді. Вони повертають ще одне направлення — авторитативні сервери імен конкретно для example.com (наприклад, ns1.example.com, ns2.example.com).

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

Резолвер надсилає запит до авторитативного сервера імен для example.com. Цей сервер містить фактичний файл зони та повертає остаточну відповідь — запис A з IPv4-адресою (або AAAA для IPv6).

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

Рекурсивний резолвер кешує відповідь відповідно до значення TTL запису (наприклад, 300 секунд = 5 хвилин, 86400 секунд = 24 години). Потім він повертає IP-адресу ОС клієнта, яка передає її браузеру.

Крок 7 — TCP/IP-з’єднання

Браузер використовує розв’язану IP-адресу для відкриття TCP-з’єднання (зазвичай на порту 443 для HTTPS). Завдання DNS на цьому завершено. Веб-сервер відповідає, і сторінка завантажується.

Весь цей процес — кроки з 2 по 6 — зазвичай завершується за 20–120 мілісекунд при теплому кеші резолвера та менш ніж за 500 мілісекунд при повністю холодному, некешованому розв’язанні, що проходить усі рівні ієрархії.

Типи DNS-записів: технічний довідник

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

Типи DNS-запитів: рекурсивні, ітеративні та нерекурсивні

Більшість кінцевих пристроїв користувачів надсилають рекурсивні запити до налаштованого резолвера. Сам резолвер використовує ітеративні запити під час обходу ієрархії.

TTL: найбільш неправильно зрозумілий параметр DNS

TTL (Time to Live) — це кількість секунд, протягом яких DNS-запис може кешуватися резолверами та клієнтами. Він встановлюється власником домену у файлі зони.

• Низький TTL (60–300 секунд): Швидше поширення змін. Необхідний перед запланованими міграціями, змінами IP або подіями відмовостійкості. Збільшує навантаження на авторитативні сервери.
• Високий TTL (3600–86400 секунд): Зменшує навантаження на резолвери та прискорює повторні запити. Зміни поширюються глобально довше.

Важливе операційне зауваження: Плануючи міграцію сервера або зміну IP, зменшіть TTL до 300 секунд щонайменше за 48 годин до змін. Це гарантує, що на момент оновлення запису A жоден резолвер не кешуватиме старе значення більше ніж 5 хвилин. Нехтування цим є однією з найпоширеніших причин тривалого простою під час міграцій.

Коли ви реєструєте домен через реєстрацію доменів і вказуєте його на новий сервер, вікно поширення безпосередньо визначається попереднім значенням TTL, а не якимось довільним правилом «24–48 годин», яке часто цитують неправильно.

Транспортні протоколи DNS: UDP, TCP, DoH та DoT

Традиційний DNS працює через UDP-порт 53 для запитів розміром до 512 байт. Відповіді, що перевищують цей розмір, ініціюють перехід на TCP-порт 53. Відповіді DNSSEC, передача зон (AXFR) та великі записи TXT зазвичай вимагають TCP.

Сучасні протоколи конфіденційності DNS суттєво змінили цей ландшафт:

DoH проти DoT — реальна операційна різниця: DoH тунелює DNS всередині HTTPS-трафіку на порту 443, роблячи його невідрізнюваним від звичайного веб-трафіку. Це корисно для конфіденційності, але значно ускладнює моніторинг і фільтрацію корпоративних мереж. DoT використовує виділений порт (853), який мережеві адміністратори можуть незалежно моніторити, блокувати або перевіряти. Для власної інфраструктури на виділеному сервері запуск локального резолвера DoT або DoH забезпечує як конфіденційність, так і повний контроль над політикою розв’язання.

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

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

DNSSEC не шифрує DNS-трафік — він лише підписує його. Ланцюжок підписів працює наступним чином:

1. Власник зони генерує ключ підпису зони (ZSK) та ключ підпису ключів (KSK)
2. Кожен набір DNS-записів підписується ZSK, створюючи записи RRSIG
3. KSK підписує набір записів DNSKEY
4. Запис DS (Delegation Signer) публікується в батьківській зоні (наприклад, .com), створюючи ланцюжок довіри аж до кореня

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

Типові збої DNS та способи їх діагностики

NXDOMAIN — неіснуючий домен

Авторитативний сервер підтвердив, що домен не існує. Поширені причини: помилка в імені домену, закінчення терміну реєстрації домену, видалений DNS-запис.

dig www.example.com
# Look for: status: NXDOMAIN

SERVFAIL — збій сервера

Резолвер не зміг виконати запит. Поширені причини: збій валідації DNSSEC, недоступний авторитативний сервер, неправильно налаштований файл зони.

dig +dnssec example.com
# Look for: status: SERVFAIL

Щоб обійти валідацію DNSSEC та ізолювати проблему:

dig +cd example.com
# +cd = checking disabled; bypasses DNSSEC validation

Застарілий кеш / затримка поширення

Після оновлення DNS-запису старі значення зберігаються в кешах резолверів до закінчення TTL. Щоб запитати авторитативний сервер безпосередньо та обійти кеш резолвера:

dig @ns1.example.com www.example.com

Перевірка глобального поширення DNS

Використовуйте dig з конкретними публічними резолверами для перевірки стану поширення:

dig @8.8.8.8 www.example.com A
dig @1.1.1.1 www.example.com A
dig @9.9.9.9 www.example.com A

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

Коли ви розгортаєте веб-сайт або додаток на VPS з cPanel, керування DNS зазвичай здійснюється через DNS-кластер WHM або редактор зон cPanel. Розуміння структури файлу зони дозволяє вносити зміни, які GUI не надає.

Мінімальний файл зони для example.com виглядає так:

$TTL 3600
@   IN  SOA  ns1.example.com. admin.example.com. (
            2024010101  ; Serial
            3600        ; Refresh
            900         ; Retry
            604800      ; Expire
            300 )       ; Minimum TTL

@       IN  NS      ns1.example.com.
@       IN  NS      ns2.example.com.
@       IN  A       203.0.113.10
www     IN  A       203.0.113.10
mail    IN  A       203.0.113.20
@       IN  MX  10  mail.example.com.
@       IN  TXT     "v=spf1 ip4:203.0.113.20 ~all"

Для коректної роботи хостингу електронної пошти запис MX повинен вказувати на ім’я хоста (не безпосередньо на IP-адресу), а саме це ім’я хоста має розв’язуватися через запис A. Поширена помилка конфігурації — вказувати MX безпосередньо на IP — це порушує RFC 2821 і спричиняє збої доставки на суворих поштових серверах.

Продуктивність DNS: що насправді впливає на швидкість розв’язання

• Близькість резолвера: Резолвер, географічно близький до клієнта (або в тій самій мережі), суттєво зменшує час туди-назад.
• Частота влучань у кеш: Домени з високим трафіком і розумними TTL майже завжди обслуговуються з кешу. Розв’язання з холодним кешем у 5–20 разів повільніше.
• Anycast-маршрутизація: Кореневі сервери та основні публічні резолвери використовують anycast, автоматично направляючи запити до найближчого фізичного вузла.
• Кількість DNS-запитів на сторінку: Одна веб-сторінка може ініціювати 20–50 DNS-запитів (ресурси CDN, аналітика, шрифти, рекламні мережі). Браузери паралелізують їх, але кожне унікальне ім’я хоста потребує власного пошуку.
• Попереднє завантаження DNS: Сучасні браузери підтримують <link rel="dns-prefetch" href="//cdn.example.com"> для розв’язання імен хостів третіх сторін до того, як вони знадобляться, зменшуючи сприйняту затримку.

DNS проти альтернативних механізмів розв’язання

Файл /etc/hosts перевіряється перед DNS практично в кожній операційній системі. Це робить його безцінним для локальної розробки — ви можете зіставити myapp.local з 127.0.0.1 без будь-яких змін у DNS-інфраструктурі.

Ключові висновки та контрольний список рішень

Використовуйте цей контрольний список під час налаштування або усунення несправностей DNS для будь-якого виробничого середовища:

• Перед будь-якою міграцією сервера: Зменшіть TTL до 300 секунд щонайменше за 48 годин наперед
• Для доставки електронної пошти: Перевірте, що записи MX, SPF (TXT), DKIM (TXT), DMARC (TXT) та PTR правильно налаштовані
• Для безпеки: Увімкніть DNSSEC для вашого домену та додайте записи CAA для обмеження видачі сертифікатів
• Для конфіденційності: Використовуйте DoT або DoH на клієнтських пристроях і серверах; уникайте надсилання відкритого DNS через ненадійні мережі
• Для продуктивності: Встановіть TTL 3600–86400 для стабільних записів; використовуйте 300 лише для записів, що часто змінюються
• Для діагностики: Завжди запитуйте авторитативний сервер безпосередньо за допомогою dig @ns1.yourdomain.com, щоб відрізнити затримку поширення від реальної помилки конфігурації
• Для керування зонами: Збільшуйте серійний номер SOA щоразу, коли змінюєте файл зони — резолвери використовують його для виявлення змін
• Для хостингу: Переконайтеся, що делегування серверів імен у реєстратора відповідає записам NS у вашому файлі зони — невідповідність є найпоширенішою причиною «DNS не працює» після передачі домену

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

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

Рекурсивний резолвер (наприклад, 8.8.8.8) — це посередник, який запитує ієрархію DNS від імені вашого пристрою та кешує результати. Авторитативний сервер імен містить фактичні записи зони для конкретного домену та надає остаточні відповіді. Ваш резолвер запитує багато авторитативних серверів; авторитативний сервер вашого домену відповідає лише за зони, які він обслуговує.

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

Затримка поширення спричинена кешуванням на основі TTL. Кожен резолвер, який раніше кешував ваш старий запис, продовжуватиме його обслуговувати до закінчення TTL. Якщо ваш TTL становив 86400 (24 години), резолвери можуть обслуговувати старий запис до 24 годин після вашого оновлення. Це не помилка — це передбачений механізм кешування, який робить DNS масштабованим.

Що таке витік DNS і чому це важливо?

Витік DNS виникає, коли ваш пристрій надсилає DNS-запити поза межами призначеного резолвера — зазвичай до резолвера вашого інтернет-провайдера — навіть при використанні VPN або інструменту конфіденційності. Це розкриває вашу активність у браузері вашому провайдеру. Ви можете перевірити наявність витоків на dnsleaktest.com та усунути їх, налаштувавши VPN-клієнт для примусової маршрутизації DNS через власний резолвер.

Чи може DNS використовуватися як вектор атаки?

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

Як знайти авторитативні сервери імен для будь-якого домену?

Використовуйте dig з типом запису NS та прапором +short для чистого виводу:

dig NS example.com +short

Щоб відстежити повний шлях делегування від кореня до авторитативного сервера, використовуйте:

dig +trace example.com

Це показує кожен перехід направлення — корінь → TLD → авторитативний — що є найнадійнішим способом діагностики помилок конфігурації делегування.