Ви купили домен, оплатили хостинг, дизайнер здав макет — а сайт усе одно не відкривається за вашою адресою. Або відкривається у вас, але не відкривається у клієнта з іншого міста. Майже завжди корінь цієї плутанини один і той самий: DNS. Це та невидима частина інфраструктури, про яку ніхто не думає, поки вона працює, і на яку всі скаржаться, коли щось іде не так.
Розберемо по-людськи: що таке DNS, як він перетворює вашу адресу на реальний сайт, які записи вам доведеться редагувати самостійно і чому зміни іноді «доходять» до всіх лише за добу. Без академічних формулювань — так, як ми пояснюємо це клієнтам Netloria, коли підключаємо їм новий домен.
Комп’ютери не знають, що таке «netloria.com». Вони спілкуються числами — IP-адресами на кшталт 192.0.2.10. Людина ж не запам’ятає такий набір цифр для кожного сайту, яким користується. DNS (Domain Name System) — це система, яка тримає відповідність між зрозумілим людині ім’ям і зрозумілою машині адресою.
Аналогія зі старою телефонною книгою тут майже ідеальна. Ви знаєте ім’я людини, але щоб їй подзвонити, потрібен номер. Ви шукаєте ім’я — отримуєте номер. DNS робить те саме: браузер знає ім’я сайту, а DNS повертає йому «номер» — IP-адресу сервера, де цей сайт лежить.
Різниця в масштабі. Телефонна книга — це одна товста книжка. DNS — це розподілена система з мільйонів серверів по всьому світу, які постійно перепитують одне одного, і все це відбувається за частки секунди щоразу, коли ви відкриваєте будь-яку сторінку.
Коли ви вводите адресу і тиснете Enter, за лаштунками розгортається невеличкий ланцюжок запитів. Виглядає він так.
Спершу браузер звертається до рекурсивного резолвера — це зазвичай сервер вашого провайдера або публічний резолвер (той самий 8.8.8.8 від Google чи 1.1.1.1). Резолвер — це посередник, який бере на себе всю чорнову роботу пошуку. Якщо він нещодавно вже шукав цей сайт, то віддасть відповідь одразу з кешу. Якщо ні — піде питати далі.
Далі резолвер іде до кореневих серверів. Їх у світі всього 13 — позначених літерами від A до M, і вони не знають адресу конкретного сайту, зате знають, хто відповідає за зону .com, .ua чи .org. Корінь фактично каже: «За .com питай ось цей сервер».
Резолвер іде до сервера TLD (домену верхнього рівня — .com, .ua тощо). Той теж не знає IP вашого сайту, але знає, які саме nameserver-и обслуговують ваш конкретний домен. І аж тепер резолвер звертається до авторитетного nameserver-а вашого домену — того, де реально лежать усі записи. Він і повертає фінальну IP-адресу.
Впізнаєте відчуття, коли сайт «думає» перші пів секунди, а потім летить? Частина цієї паузи — саме описаний ланцюжок. Хороша новина в тому, що результат кешується на кожному кроці, тож наступного разу відповідь прилетить майже миттєво.
Усередині панелі керування доменом чи хостингом ви побачите список записів. Виглядає він страшно, але насправді типовому власнику сайту треба розуміти лише кілька типів. Ось вони.
| Тип запису | За що відповідає | Коли ви його чіпаєте |
|---|---|---|
| A | Прив’язує домен до IPv4-адреси сервера | Переносите сайт на новий хостинг |
| AAAA | Те саме, але для новішої IPv6-адреси | Рідко, якщо хостинг вимагає IPv6 |
| CNAME | Робить один домен псевдонімом іншого (напр. www → основний домен) | Налаштовуєте піддомен або підключаєте зовнішній сервіс |
| MX | Каже, який сервер приймає пошту для домену | Підключаєте корпоративну пошту (Google Workspace тощо) |
| TXT | Довільний текст: підтвердження прав, налаштування захисту пошти | Верифікуєте домен, налаштовуєте SPF/DKIM |
| NS | Вказує, які nameserver-и керують доменом | Переносите керування DNS до іншого провайдера |
90% реальних ситуацій зводяться до двох записів. A-запис — коли треба показати домену новий сервер. MX і TXT — коли налаштовуєте пошту на власному домені. Решту в житті звичайного бізнес-сайту ви можете не чіпати роками.
Тут ховається найпоширеніша плутанина, і саме вона з’їдає найбільше нервів. Є два різних рівні, на яких можна «керувати DNS», і люди їх постійно змішують.
Перший рівень — nameserver-и. Їх ви прописуєте там, де купили домен, тобто в реєстратора. Nameserver-и відповідають на питання «а хто взагалі головний по цьому домену, хто зберігає його записи». Поки в реєстратора стоять nameserver-и одного провайдера, всі A, MX, TXT ви редагуєте саме там. Зміните nameserver-и на інші — і реєстратор більше не дивиться на старі записи, він відсилає всіх до нового «господаря» зони.
Другий рівень — самі записи (A, MX, CNAME…). Вони лежать у того, чиї nameserver-и зараз активні. Це може бути ваш реєстратор, хостинг-провайдер або окремий DNS-сервіс.
Класична пастка виглядає так. Клієнт купив домен в одного провайдера, хостинг — у другого (а це, до речі, нормальна практика — домен і хостинг беруть окремо), заходить у панель хостингу, старанно міняє там A-запис на правильний IP — і нічого не відбувається. Бо nameserver-и в реєстратора все ще вказують на самого реєстратора, а не на хостинг. Правки внесені не туди, куди дивиться інтернет. Спершу треба вирішити, хто керує зоною, а вже потім редагувати записи в правильному місці.
Ми в Netloria на старті кожного проєкту фіксуємо це першим пунктом: де куплений домен, де стоятиме сайт, і на чиїх nameserver-ах живе DNS. Одна ця відповідь знімає більшість майбутніх «сайт не відкривається».
Ви змінили A-запис, оновили сторінку — старий сайт. Через годину у вас уже новий, а колега з іншого міста досі бачить старий. Це не баг. Це propagation — поширення змін по світу.
Причина в кешуванні. Резолвери по всьому світу зберігають отриману відповідь у пам’яті на певний час, щоб не смикати авторитетний сервер щоразу. Скільки саме зберігати — визначає параметр TTL (Time to Live), заданий у секундах прямо в записі. Поки TTL не сплив, резолвер віддає стару, закешовану відповідь і навіть не питає про оновлення.
Стандартне значення TTL для звичайного A-запису — 86 400 секунд, тобто цілу добу. Тому теоретично зміни можуть «доходити» до всіх дуже довго. На практиці, за даними того ж джерела, поширення зазвичай укладається в кілька годин, але в окремих випадках розтягується до 72 годин.
Є прийом для планового переїзду. За добу-дві до зміни знижуєте TTL проблемного запису до 30–300 секунд — і тоді резолвери оновлюють кеш майже одразу, а не раз на добу. Після переїзду TTL повертаєте назад, щоб зайве не навантажувати сервери. Це стандартна процедура при перенесенні сайту на новий хостинг, і вона перетворює нервовий переїзд «наосліп» на кероване, майже непомітне для відвідувачів перемикання.
На практиці послідовність, якою ми переносимо клієнтські сайти, виглядає приблизно так: спершу за день-два знижуємо TTL старих записів, потім піднімаємо повну копію сайту на новому сервері й перевіряємо її окремо, ще до перемикання; аж коли нова версія працює бездоганно, міняємо A-запис на новий IP — і оскільки TTL уже низький, більшість відвідувачів переходять на новий сервер за лічені хвилини, а не годинами бачать то стару, то нову версію. Старий сервер лишаємо ввімкненим ще на добу як страховку, поки поширення не завершиться повністю. Звучить занудно, але саме ця занудність економить клієнту зниклі замовлення в день переїзду.
За роки підключення доменів клієнтам збирається впізнаваний список граблів. Ось найтиповіші — не абстрактні, а ті, на які ми реально натрапляємо.
Помітили закономірність? Майже жодна з цих проблем не про «складну технологію». Усі вони про уважність і про розуміння, який важіль що вмикає.
DNS відповідає не лише за те, щоб сайт відкривався. Через TXT-записи налаштовується захист вашої пошти від підробок — SPF, DKIM і DMARC. Простими словами: ці записи кажуть поштовим серверам світу, які сервери мають право надсилати листи від імені вашого домену. Без них ваші листи частіше падають у спам, а зловмиснику легше вдати, ніби він пише від вашого імені.
Це та ж логіка довіри, що й у SSL-сертифіката, тільки для електронної пошти. І це ще один аргумент не залишати DNS напризволяще: неправильні або відсутні записи б’ють не тільки по доступності сайту, а й по репутації домену загалом.
Щоб DNS не був чорною скринькою, тримайте в голові кілька опорних точок.
DNS не потрібно любити чи вивчати до рівня системного адміністратора. Достатньо розуміти, що це шар, який перекладає імена на адреси, що зміни в ньому не миттєві, і що редагувати їх треба в тому місці, яке зараз реально керує доменом. Решту зробить той, хто налаштовує вам інфраструктуру.
У Netloria ми беремо цю частину на себе повністю: реєструємо чи переносимо домен, підключаємо хостинг, прописуємо правильні записи, налаштовуємо пошту й безпеку — так, щоб ви жодного разу не побачили слова «propagation» у своєму житті. Якщо вам потрібен сайт, який просто працює з першого дня, без танців із бубном навколо nameserver-ів — замовте розробку корпоративного сайту в Netloria, і всю технічну кухню ми візьмемо на себе.
