DNS – це система, яка перекладає назву сайту (наприклад, google.com) у числову IP-адресу, потрібну мережі, щоб знайти сервер і відкрити сторінку.
Коли ви вводите домен у браузері, не відбувається магії. Відбувається запит: комп’ютер запитує, куди саме йому йти. І DNS відповідає – мов адресна довідка, тільки не на папері, а в мережі й розподілено по світу.
Уявіть ситуацію: ви пам’ятаєте ім’я знайомого, а номер телефону – ні. Телефонна книга рятує. Так само й тут: домен для людини, IP для мережевого обладнання. Саме тому DNS стоїть у першому ряду, коли браузер починає завантажувати сайт.
Щоб було зрозуміло, що відбувається під капотом, ось коротка логіка запиту від домену до IP-адреси:
- Браузер отримує домен і передає його системі вирішення імен (resolver) у вашій ОС.
- Система спершу дивиться локальні підказки: кеш і файл hosts.
- Якщо відповіді немає, запит іде до рекурсивного DNS-сервера (часто це сервер провайдера або публічний сервіс на кшталт Google Public DNS чи Cloudflare DNS).
- Рекурсор знаходить авторитетну відповідь через ієрархію DNS і повертає IP.
- Браузер підключається до IP-адреси і починає завантаження сайту.
DNS-сервери та ієрархія DNS
DNS не зберігається в одному місці – інакше Інтернет упав би від першої ж аварії. Система побудована як дерево: зверху корінь, нижче – домени верхнього рівня, ще нижче – конкретні домени. У цій схемі задіяні різні типи серверів, і кожен робить свою частину роботи.
- Рекурсивний DNS-сервер (рекурсор): це “посередник”, до якого звертається ваш пристрій. Він або віддає відповідь з кешу, або йде шукати її далі.
- Кореневі сервери (root): знають, де шукати інформацію про домени верхнього рівня. Вони не тримають IP для всіх сайтів, зате тримають “вказівники”.
- TLD-сервери: це сервери доменів верхнього рівня – .ua, .com, .org, .net та інші. Вони підказують, які сервери відповідають за конкретний домен у своїй зоні.
- Авторитетні сервери: фінальна інстанція. Саме тут лежать DNS-записи домену – ті самі дані, які й перетворюються на відповідь для браузера.
Чому ця “драбина” корисна? Тому що відповідальність розподілена. Наприклад, адміністратор домену компанії керує своїми записами на авторитетних серверах, а не просить когось “нагорі” переписати весь Інтернет. Такий підхід свого часу й став еволюцією від старої практики з єдиним файлом hosts, що погано масштабувався.
Є ще одна деталь, яку часто плутають: рекурсор не дорівнює авторитетному серверу. Перший шукає і кешує. Другий зберігає “правду” про домен у межах своєї зони.
Основні типи DNS-записів
DNS-запис – це рядок у зоні домену, який описує, куди вести трафік, як доставляти пошту, як перевіряти володіння доменом, які ключі безпеки використовувати. Для сайту й пошти зазвичай вистачає кількох типів, але перелік ширший.
- A – прив’язує домен до IPv4-адреси. Класика: example.com → 192.0.2.10.
- AAAA – те саме, але для IPv6. Корисно там, де IPv6 увімкнений повноцінно.
- CNAME – псевдонім. Наприклад, www.example.com може вказувати на example.com або на окремий хост у хмарі.
- MX – маршрути для електронної пошти: куди надсилати листи для домену.
- TXT – текстові дані: верифікація домену, SPF/DKIM/DMARC для пошти, службові позначки.
- NS – які сервери імен обслуговують зону домену (тобто куди делегований домен).
- SRV – службові записи для конкретних сервісів (наприклад, деякі VoIP/месенджер-сценарії).
Окрема тема – TTL (Time To Live). Це час життя відповіді в кеші. Короткий TTL дає швидші зміни (зручно при міграції), довший – менше запитів і стабільніша робота. Тут немає “краще назавжди”: для маркетингової сторінки та для критичного API логіка буде різною.
Поширена помилка при налаштуваннях: змішувати A/AAAA і CNAME на одному й тому самому імені хоста, де це заборонено політикою DNS (наприклад, для кореня зони). Тому перед змінами варто глянути, як саме керує записами ваш DNS-провайдер або панель керування хостингом.
DNS-кеш і файл hosts
Швидкість DNS часто тримається не на “надпотужних серверах”, а на пам’яті: відповіді кешуються на різних рівнях. Це економить час і зменшує кількість запитів у мережі.
DNS-кеш є:
- у вашій операційній системі;
- у браузері (залежно від реалізації);
- у рекурсивного DNS-сервера (провайдера або публічного сервісу);
- інколи в мережевому обладнанні (роутер, корпоративний резолвер).
З одного боку, кеш – це зручність: відкриваєте знайомий сайт, і відповідь приходить швидше. З іншого – саме кеш пояснює ситуацію, коли “в мене сайт уже працює, а в колеги ще ні” після зміни DNS-записів. Поки TTL не вичерпано, частина пристроїв житиме на старих даних.
Файл hosts – це локальна таблиця відповідностей імен та IP, яка має пріоритет над DNS. Вона корисна для тестів (наприклад, перевірити сайт на новому сервері до перемикання домену), а також для локальних середовищ розробки.
Але hosts легко перетворюється на джерело проблем: запис залишили “на хвилинку”, забули – і потім дивуються, чому сайт відкривається не там, де потрібно. Тому правило просте: зробили тест – прибрали запис або хоча б задокументували.
Як DNS пов’язаний з типовими помилками? Якщо бачите повідомлення на кшталт “DNS-сервер не відповідає” або сайт не знаходиться, причина часто одна з цих:
- збій або перевантаження рекурсивного сервера;
- невдалий кеш (старі записи після змін);
- помилка в DNS-записах (A/CNAME/MX, зайві пробіли, некоректний хост);
- блокування або перехоплення DNS-запитів у мережі.
Безпека та налаштування DNS
DNS історично задумувався як “просто довідник”, без шифрування. І це довго було нормою: запит і відповідь видно в мережі, а значить їх реально підмінити або підглянути. Звідси й сучасні підходи до захисту.
Дві технології, які часто згадують у контексті приватності:
- DoH (DNS over HTTPS) – DNS-запити йдуть через HTTPS. Для мережі це виглядає як звичайний вебтрафік.
- DoT (DNS over TLS) – DNS поверх TLS на окремому з’єднанні. Принцип той самий: шифрування, менше можливостей для підміни “на льоту”.
Варто розуміти нюанс: DoH/DoT шифрують шлях від вашого пристрою до DNS-провайдера, але не роблять вас невидимими в Інтернеті. Сайт, до якого ви підключаєтесь, усе одно бачить ваш IP, а провайдер DNS усе одно стає точкою довіри – обирайте його свідомо.
Коли має сенс змінити DNS-сервер? Наприклад, якщо:
- поточний резолвер повільний або нестабільний;
- потрібні фільтри (батьківський контроль, блокування фішингу);
- хочеться увімкнути DoH/DoT у браузері чи системі.
Для зміни DNS зазвичай достатньо відкрити налаштування мережі (Wi-Fi або Ethernet) і вказати адреси DNS вручну. У домашній мережі зручніше прописати DNS у роутері – тоді його успадкують усі пристрої.
Як діяти, якщо з’являється “DNS не відповідає” і сайт не відкривається:
- Перевірте, чи проблема лише з одним сайтом: відкрийте кілька різних доменів.
- Очистіть DNS-кеш у системі або перезапустіть мережеве підключення; інколи достатньо перезапуску роутера.
- Тимчасово змініть DNS на публічний сервіс (Google Public DNS, Cloudflare DNS) і перевірте результат.
- Якщо домен ваш: перевірте записи в панелі керування, особливо A/AAAA, NS і TTL; при міграціях дивіться, чи не лишилися старі значення.
- У корпоративній мережі уточніть політики: інколи DNS-фільтрація або проксі перекривають частину доменів.
DNS здається дрібницею, поки не доводиться переносити сайт, налаштовувати пошту або розбиратися, чому сервіс “то живий, то мовчить”. Розуміння базових речей – ієрархії серверів, типів записів, ролі кешу – знімає половину хаосу ще до того, як ви відкриєте консоль.