Як працює DNS: записи, propagation, діагностика та безпека

Чому сайт не працює якщо "все правильно налаштовано"

Клієнт переніс сайт на новий сервер. IP змінився, A-запис оновлений, сервер працює. Але половина користувачів бачить старий сайт, а друга половина — помилку. Підтримка провайдера каже "зачекайте 48 годин". Клієнт нервує, бо щогодини втрачає замовлення.

Причина — DNS. Точніше, нерозуміння як він працює. Якби клієнт знизив TTL за добу до переїзду — проблема б тривала 5 хвилин замість двох діб.

DNS (Domain Name System) — це те що перетворює hostiserver.com в IP-адресу сервера. Система яка працює мільярди разів на день і непомітна — поки щось не зламається. У цьому гайді розберемо як DNS працює під капотом, як не наступити на граблі при міграції, і які записи потрібно налаштувати щоб пошта не летіла в спам.

Як DNS-запит проходить від браузера до сервера

Коли ви набираєте адресу сайту, відбувається ланцюжок запитів. Весь процес займає 20-100 мс, але за цей час задіюються до 4 типів серверів.

Ось як це виглядає:

Браузер → Кеш ОС → Recursive Resolver → Root Server → TLD Server (.com) → Authoritative Server → IP-адреса!
                         (8.8.8.8)         ("хто .com?")   ("хто example.com?")   ("93.184.216.34")

Крок за кроком

1. Локальний кеш — браузер перевіряє чи він вже знає IP цього домену. Якщо ви відвідували сайт раніше і TTL ще не вичерпався — запит далі не йде. Це найшвидший варіант: 0 мс.

2. Recursive resolver — якщо в кеші немає, запит йде до рекурсивного DNS-сервера. Це може бути сервер вашого провайдера або публічний DNS (Google 8.8.8.8, Cloudflare 1.1.1.1). Цей сервер бере на себе всю подальшу роботу.

3. Root-сервери — resolver питає один з 13 кореневих серверів: "Де шукати домени .com?" Root-сервер не знає IP конкретного сайту, але знає хто відповідає за зону .com.

4. TLD-сервери — сервер зони .com каже: "За example.com відповідають ось такі name-сервери." І дає їхню адресу.

5. Авторитативний сервер — фінальна точка. Він містить фактичні DNS-записи домену і повертає IP-адресу — наприклад, 93.184.216.34.

6. Кешування — результат зберігається на кожному рівні (resolver, ОС, браузер) на час TTL. Наступний запит до цього ж домену обробиться за 1-5 мс.

4 типи DNS-серверів

DNS-записи: що, навіщо і як налаштувати

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

Основні типи записів

Коли які записи потрібні

Не всі записи потрібні одразу. Ось типові сценарії:

• Тільки сайт: A + AAAA (опціонально) + CNAME для www
• Сайт + пошта (Google Workspace / Microsoft 365): A + CNAME + MX + TXT (SPF) + TXT (DKIM) + TXT (DMARC)
• Сайт через CDN: CNAME на CDN-провайдера замість A-запису
• Обмеження SSL-сертифікатів: CAA запис (наприклад, дозволити тільки Let's Encrypt)

SPF, DKIM, DMARC — захист пошти

Три TXT-записи які критично важливі якщо ви відправляєте email з вашого домену:

• SPF — вказує які сервери мають право відправляти пошту від імені вашого домену. Без SPF листи часто потрапляють у спам.
• DKIM — додає цифровий підпис до кожного листа. Одержувач може перевірити що лист не підроблений.
• DMARC — політика що робити з листами які не пройшли SPF/DKIM перевірку (відхиляти, карантин, пропускати).

Як перевірити та діагностувати DNS

Коли щось не працює — домен не резолвиться, пошта не доходить, або сайт показує стару версію — перше що потрібно перевірити це DNS.

dig — основний інструмент

# A-запис домену
dig hostiserver.com A
# MX-записи (поштові сервери)
dig hostiserver.com MX
# TXT-записи (SPF, DKIM, верифікація)
dig hostiserver.com TXT
# Запит через конкретний DNS-сервер
dig @8.8.8.8 hostiserver.com A
# Скорочений вивід
dig +short hostiserver.com A

nslookup — альтернатива для Windows

# Базовий запит
nslookup hostiserver.com
# Через конкретний сервер
nslookup hostiserver.com 8.8.8.8
# MX-записи
nslookup -type=MX hostiserver.com

Очищення DNS-кешу

Якщо ви змінили DNS-записи, але бачите стару версію — проблема в кеші:

# Windows
ipconfig /flushdns
# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
# Linux (systemd-resolved)
sudo systemd-resolve --flush-caches

DNS Propagation: чому зміни не застосовуються одразу

Ви змінили A-запис, але сайт все ще показує старий IP. Клієнти в одній країні бачать новий сайт, а в іншій — старий. Це DNS propagation — процес поширення змін по всіх DNS-серверах світу.

Чому це займає час

Кожен DNS-сервер кешує відповіді на час TTL (Time to Live). Якщо TTL вашого A-запису був 86400 секунд (24 години) — деякі сервери будуть повертати стару IP ще до 24 годин після зміни.

Як прискорити propagation

• Знизьте TTL заздалегідь. За 24-48 годин до запланованих змін зменшіть TTL до 300 секунд (5 хвилин). Після зміни — підніміть назад.
• Очистіть локальний кеш. ipconfig /flushdns на вашому комп'ютері.
• Використовуйте швидкий DNS. Публічні DNS (Google 8.8.8.8, Cloudflare 1.1.1.1) оновлюються швидше ніж DNS провайдера.

DNS та безпека: DNSSEC, DNS over HTTPS

Стандартний DNS працює відкритим текстом — запити та відповіді не шифруються і не підписуються. Це створює вразливості.

DNS Spoofing (отруєння кешу)

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

DNSSEC

DNS Security Extensions додає цифровий підпис до DNS-відповідей. Recursive resolver може перевірити що відповідь не була підмінена по дорозі. DNSSEC не шифрує запити, але гарантує їхню автентичність.

DNS over HTTPS (DoH) та DNS over TLS (DoT)

Шифрують DNS-запити щоб провайдер або хтось у мережі не міг бачити які сайти ви відвідуєте. Підтримується у всіх сучасних браузерах та ОС:

• DoH — DNS через HTTPS (порт 443). Використовують Chrome, Firefox, Edge.
• DoT — DNS через TLS (порт 853). Використовує Android, Linux.

5 помилок з DNS які ми бачимо регулярно

1. Забули оновити NS-записи після переїзду. Перенесли сайт на новий хостинг, змінили A-запис, але NS-записи все ще вказують на старого провайдера. Результат: частина запитів йде на старий сервер.

2. Відсутній SPF/DKIM. Пошта з домену летить у спам або блокується. Особливо критично для eCommerce з транзакційними листами.

3. Високий TTL перед міграцією. TTL 86400 (24 години) означає що після зміни IP деякі користувачі будуть бачити старий сайт ще добу. Знижуйте TTL до 300 заздалегідь.

4. CNAME на кореневому домені. example.com не може мати CNAME (тільки A/AAAA). CNAME працює лише для піддоменів (www, blog, shop). Деякі DNS-провайдери обходять це через ALIAS/ANAME записи.

5. Не перевіряють DNS після змін. Змінили записи і чекають "поки запрацює". Використовуйте dig або онлайн-чекери щоб переконатись що зміни застосувались правильно.

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