Коли ми шукаємо інформацію в Інтернеті, то використовуємо зрозумілі нам імена сайтів на кшталт google.com чи realhost.pro. Але це ми "спілкуємося" назвами, а от комп’ютери для розуміння один одного використовують сухі й не надто запам’ятовувані IP-адреси типу 185.72.159.45.
Так от, аби нам не тримати в голові ці тисячі чисел, людство й придумало DNS — свого роду довідник або телефонну книгу інтернету. Ми вводимо звичну назву сайту, а DNS миттєво (іноді з перебоями, але про це пізніше) знаходить, за якою IP-адресою ховається потрібний ресурс.
DNS (Domain Name System) — це сервіс, що перетворює доменні імена на IP-адреси, зрозумілі для комп’ютерів. Він дає змогу людям використовувати звичні назви сайтів, а не морочити собі голову цифрами. DNS — це основа роботи всього Інтернету. Без нього браузер просто видасть: “404. Я не знаю, куди йти.”
Пропонуємо зараз розібратися:
- Де зберігаються DNS записи?
- Хто цим всім керує?
- Чому після зміни DNS запису часто все ще нічого не працює?
- І що означає оте таємниче “TTL”, яке раптом стає головною проблемою?
У цій статті ми розкладемо все це по поличках — просто, фахово, з прикладами, і (обіцяємо) без надмірного техно-бюрократизму. Хоча буде трохи задовго, але ви вже точно зрозумієте що ж то за DNS.
1. Як працює DNS: покроково
Уявімо: ви відкриваєте браузер і вводите example.com. Здається, що все просто — сайт відкривається, і ви переходите до своїх справ. Але за лаштунками розгортається невеличкий “квест” з кількох рівнів. Ось як це працює:
🔴 Крок 1. Браузер запитує: “А де той example.com?”
Насамперед браузер звертається до операційної системи: "Чи є в тебе IP-адреса для цього домену?" Якщо відповідь “так” (у кеші), на цьому все і закінчується — сайт відкривається.
🔴 Крок 2. Немає в кеші? Йдемо далі!
Тоді запит передається до рекурсивного DNS-сервера — зазвичай це сервер провайдера або Google DNS: 8.8.8.8, 8.8.4.4, Cloudflare DNS: 1.1.1.1, 1.0.0.1, OpenDNS: 208.67.222.222, 208.67.220.220
- Рекурсивний сервер DNS (або рекурсивний резолвер) — відповідає за пошук повної відповіді на DNS-запит користувача, навіть якщо йому самому ця відповідь невідома.
- Чому він "рекурсивний"? Бо не зупиняється на півдорозі. Він "рекурсує" (бігає за тебе по інстанціях) — тобто виконує всі кроки, поки не знайде остаточну відповідь. Тобі не потрібно знати, що саме і де він запитував — результатом для користувача є готова IP-адреса.
- Для чого це все?
- Щоб користувачі не чекали: рекурсивні сервери зазвичай кешують (запам’ятовують) відповіді, щоб наступного разу не повторювати той самий шлях.
- Щоб розвантажити мережу: завдяки кешу вони зменшують кількість звернень до "вищих" DNS-серверів.
- Щоб уніфікувати обробку DNS-запитів — один потужний сервер може обслуговувати багато користувачів (наприклад, у провайдера або Google DNS).
🔴 Крок 3. Рекурсивний сервер вирушає на пошуки.
Якщо DNS-резолвер сам не має відповіді щодо потрібного IP, він запускає ланцюжок досліджень:
- Запит до кореневих ( . ), тобто, root-серверів: "Хто має інформацію про домен верхнього рівня (.com)?”.
- Root відповідає: “звертайся до TLD-сервера .com”.
- TLD-сервер каже: “ось авторитетний DNS-сервер, що відповідає саме за example.com”.
- Резолвер іде туди — і отримує IP-адресу.
- IP повертається на ваш комп’ютер — сайт відкривається.
🕐 Усе це займає частки секунди, але запит реально літає по всьому світу!
🔴 Крок 4. IP знайдено → інформація кешується.
Отримана адреса повертається назад до браузера і зберігається в кеші на певний час (встановлений через TTL). Браузер тепер знає, куди стукати в разі повторного запиту користувача.
🔴 Крок 5. З'єднання встановлено.
Браузер нарешті йде за IP, встановлює TCP-з’єднання (і TLS, якщо HTTPS), і вуаля — сайт на екрані.
Коротко про "героїв" розшуку IP для сайту:
- Браузер/ОС ➡ Запитує, кешує
- Рекурсивний DNS ➡ Пошуковець: шукає відповідь
- Кореневий сервер ➡ Каже, куди йти далі
- TLD-сервер ➡ Знає, хто керує доменом
- Авторитетний DNS ➡ Дає остаточну відповідь: IP-адресу
2. Обов’язкові та не дуже: розбираємося з основними типами DNS-записів
DNS-записи — це, по суті, інструкції для DNS-серверів: вони кажуть, куди слати трафік, де шукати пошту, який сервер головний, і ще багато чого. Ось найбільш поширені типи:
🔑 Найнеобхідніші записи: без них — ніяк:
| Тип запису | Для чого він | Приклад |
|---|---|---|
| A (Address) | Вказує IPv4-адресу сервера | example.com → 192.0.2.1 |
| AAAA | Те саме, але для IPv6 | example.com → 2001:db8::1 |
| CNAME (Canonical Name) | Псевдонім для домену | www.example.com → example.com |
| MX (Mail Exchange) | Куди слати пошту для домену | example.com → mail.example.com (пріоритет: 10) |
| NS (Name Server) | Які сервери відповідають за домен | example.com → ns1.provider.net |
| SOA (Start of Authority) | Початкова інформація про зону | Контакт адміністратора, серійний номер, TTL тощо |
Без A/AAAA-запису сайт просто не відкриється. Без MX — листи не прийдуть. Без NS — DNS взагалі не працює. А без SOA — сервери не будуть знати, як часто оновлювати інформацію.
🛠️ Записи, які стають у пригоді при налаштуванні або оптимізації:
| Тип запису | Для чого | Коментар |
|---|---|---|
| TXT | Текстові дані — SPF, DKIM, Google verification | Можна мати кілька, особливо для email безпеки |
| SPF (через TXT) | Контроль над дозволеними email-серверами | Бореться зі спамом |
| DKIM (через TXT) | Криптографічний підпис пошти | Частина системи перевірки автентичності |
| DMARC (через TXT) | Політика реакції на неавтентичну пошту | Контролює, що робити зі спамом |
| CAA (Certification Authority Authorization) | Яким центрам сертифікації дозволено видавати SSL | Додатковий рівень захисту |
🧙♂️ Для просунутих, DevOps і VoIP-фанатів
| Тип запису | Призначення |
|---|---|
| SRV | Вказує сервіс і порт (наприклад, для VoIP, Microsoft services) |
| NAPTR | Динамічні сервіси, VoIP, SIP |
| PTR | Зворотний DNS (IP → домен) — часто потрібен для поштових серверів |
| HINFO | Інформація про хост — тип ОС і обладнання (майже не використовується) |
| LOC | Геолокація хоста — для інтерактивних карт |
| DNSKEY / DS / RRSIG | Частина DNSSEC (криптографічне підписування) |
💡 Короткий підсумок: мінімальний набір записів для коректної роботи сайту:
- A або AAAA — щоб браузер знав, куди йти.
- CNAME — якщо хочете, щоб
wwwпрацювало. - NS — щоб DNS працював узагалі.
- SOA — для синхронізації між DNS-серверами.
- MX — для пошти.
- TXT — для безпеки та сервісів.
3. DNS-зона: де живуть усі записи про ваш домен
DNS-записи не плавають у повітрі. Вони зберігаються у так званих DNS-зонах або зонних файлах (zone files) на авторитетних DNS-серверах. Це просто текстові файли (таблиці) зі структурованою інформацією про домен.
📂 Що таке DNS-зона
DNS-зона — це частина простору доменів, за яку відповідає конкретний сервер. Вона містить усі записи: A, CNAME, MX, TXT, NS, SOA та інші. Наприклад, зона example.com могла б виглядати так:
Це — приклад так званого zone file. Якщо ви працюєте з BIND, PowerDNS або схожими DNS-серверами — це саме те, з чим ви маєте справу.
💻 Але більшість користувачів бачить інтерфейси хостингів
Більшість провайдерів пропонують прості панелі для редагування DNS — без необхідності писати руками ці файли.
Записи вводяться в табличках:
- Тип → A
- Ім’я →
@абоwww - Значення → IP-адреса
- TTL → наприклад, 3600 (тобто 1 година)
4. Хто і де керує DNS-записами
У керуванні DNS задіяні кілька гравців:
1. Реєстратор домену
Той, у кого ви купили домен (example.com). Саме він визначає, які NS-записи вказані для домену, тобто на які сервери делеговано управління.
2. DNS-хостинг
Це місце, де реально зберігаються DNS-записи. Це може бути:
- Хостинг-провайдер (у вас на сервері)
- Спеціалізований DNS-сервіс (Cloudflare, AWS Route 53, Google Cloud DNS)
- Реєстратор домену (багато з них надають DNS як бонус).
3. Сисадмін або ви самі
Якщо ви маєте доступ до DNS-панелі — ви можете додавати, змінювати або видаляти записи. Але - відповідальність теж на вас 😅
🧬 Делегування
- Ви можете вказати інші NS-записи, щоби передати управління на іншу платформу (наприклад, з
ns1.registrar.ua→ns1.cloudflare.com). - Можна делегувати субдомени (наприклад,
shop.example.com) на інший DNS-сервер для мікросервісів, SaaS чи тестування.
5. TTL або чому DNS-зміни не працюють миттєво
⏱️ Що таке TTL
TTL (Time To Live) — це час, на який DNS-запис кешується:
- Ви ставите TTL = 3600 → кеш зберігатиметься 1 годину.
- За цей час сервери не перевіряють нову версію запису — навіть якщо ви його вже змінили.
- Вказується в секундах, тож TTL = 1 означає, що запис може зберігатися в кеші лише 1 секунду.
💢 Типова ситуація:
- Ви змінили A-запис на новий IP, інформація вірна.
- Але сайт ще 3 години відкривається по-старому.
- Ви перевіряєте, панікуєте, дзвоните хостеру…
- Насправді просто TTL ще не відпрацював свій час, тому зберігається стара версія.
🧠 Порада, що робити:
- Перед важливими змінами зменшіть TTL (наприклад, до 300 секунд).
- Зачекайте поки TTL старих записів "вигорить" та всі кеші оновляться.
- Тоді вносьте зміну, вона пошириться швидко.
📌 Рекомендований мінімум:
Якщо вам потрібне дуже швидке оновлення DNS (наприклад, під час міграції сайту), ставте TTL у діапазоні 30–300 секунд:
30— для короткочасних критичних змін300(5 хвилин) — для більшості технічних задач
6. Кеш DNS — ваш друг і ворог одночасно
Кеш — це добре. Але коли ви вносите зміни, кеш стає вашим ворогом.
📦 Де саме зберігається кеш DNS:
- Операційна система: Windows, macOS, Linux — тримають DNS-записи в пам’яті.
- Браузери: Chrome, Firefox мають власний DNS-кеш (незалежний від ОС).
- Рекурсивні DNS-сервери (провайдера або Google DNS) — кешують записи згідно TTL.
- CDN або проксі (Cloudflare, Sucuri, Akamai) — мають ще свої рівні кешування.
🤦♂️ Що це означає на практиці?
- Ви змінили A-запис, але ваш друг у Німеччині ще бачить стару версію сайту — бо його DNS-сервер ще не оновився.
- Ви перевіряєте через VPN — бачите інше.
- І так до нескінченності.
В такому разі допоможе очищення кешу.
7. Як очистити DNS-кеш (для всіх систем)
На комп’ютері:
📌 Windows:
🍏 macOS
Залежить від версії macOS, macOS 10.11 і новіші (включно з macOS Sonoma):
Після введення доведеться ввести пароль адміністратора. Команда запускає очищення кешу та перезапуск служби DNS.
🐧 Linux
Очищення кешу залежить від того, який резолвер використовується.
Якщо використовується systemd-resolved (часто в Ubuntu):
Якщо використовується nscd:
Якщо використовується dnsmasq:
🌐 Браузери (локальний кеш DNS)
Chrome
Введіть в адресний рядок:
І натисніть “Clear host cache”.
Firefox:
Закрийте і відкрийте браузер, або перезапустіть у безпечному режимі.
8. DNS-граблі: на що найчастіше наступають сисадміни
Типові помилки при роботі з DNS:
- TTL надто великий — поставили 86400 (24 години), а хочете перевірити зміни через 5 хвилин.
- CNAME для root-домену — він там не працює! Для example.com використовуйте A/AAAA.
- Забули зберегти або натиснути “Apply” — і думаєте, що “нічого не працює”.
- Змінили IP — але не оновили DNS-запис.
- Помилки в TXT-записах (особливо у SPF — одна зайва лапка може “вбити” всю пошту).
- DNSSEC включили — а ключі не налаштовані → сайт стає недоступним.
9. Важливі моменти при роботі з DNS: поради сисадміна
- 🧠 Планування TTL перед міграціями.
- 🔐 DNSSEC — для захисту від підміни записів (але тільки з правильним налаштуванням!).
- ⚡ Надійні DNS-сервери — Google (8.8.8.8), Cloudflare (1.1.1.1), OpenDNS.
- 🔍 Перевірка через онлайн-інструменти:
- dnschecker.org
dig,nslookup,hostв терміналі- mxtoolbox.com
10. Висновок: без DNS не буде нічого
DNS — це як логістика для сайтів: непомітна, поки все працює. І катастрофічна, коли щось пішло не так.
🎯 Пам’ятайте:
- Перевіряйте TTL перед змінами.
- Не забувайте про кеш.
- Користуйтеся перевіреними інструментами.
- І ставтесь до DNS з повагою — це ваш перший (і часто єдиний) спосіб потрапити до користувача.
А ще — завжди тримайте під рукою dig, dnschecker і нерви зі сталі. Бо як кажуть сисадміни: “Справжній DevOps спочатку чистить DNS-кеш, а потім вже перевіряє все інше."
