Як налаштувати DNS для домену

Типи DNS-записів

DNS-зона домену — це набір записів ресурсів (resource records), кожен з яких відповідає за своє завдання. У кожного запису є тип, ім'я, значення і TTL (час життя в кеші резолверів). Ось основні типи, з якими найчастіше працюють при налаштуванні сайту та пошти:

A — прив'язує домен до IPv4-адреси сервера
AAAA — прив'язує домен до IPv6-адреси сервера
CNAME — псевдонім, який вказує на інше ім'я замість IP
MX — визначає поштовий сервер і пріоритет доставки
TXT — текстові дані: SPF, DKIM, підтвердження володіння доменом
NS — визначає, які сервери імен обслуговують зону
SRV — вказує сервіс, протокол, порт і хост, використовується, наприклад, для SIP і XMPP

Прив'язка домену до хостингу

Створіть A-запис у свого реєстратора:

@    A    [IP вашого хостингу]
www  A    [IP вашого хостингу]

Або вкажіть NS-сервери ZevsHost — тоді зоною керуватиме панель хостингу, а не панель реєстратора:

ns1.zevshost.net
ns2.zevshost.net

Різниця принципова: якщо делегування вказує на NS хостингу, всі записи редагуються в панелі ZevsHost. Якщо делегування залишилося на NS реєстратора, правки потрібно вносити саме там — зміни в панелі хостингу в цьому разі ні на що не вплинуть.

Налаштування MX для пошти

@    MX    10    mail.yourdomain.com
mail  A         [IP хостингу]

Число 10 — це пріоритет: чим воно менше, тим вищий пріоритет сервера. Якщо додати резервний сервер із пріоритетом 20, пошта піде на нього лише за недоступності основного. Ще одне обмеження стандарту: запис CNAME не можна створити на корені домену (@) — RFC 1034 вимагає, щоб на апексі зони існував запис SOA, а CNAME на тому самому імені з ним не уживається. Тому для голого домену завжди використовується A/AAAA, а не CNAME на зовнішній хост.

Часті помилки конфігурації DNS

Симптом	Причина	Рішення
dig повертає SERVFAIL для CNAME-імені	На тому самому імені, що й CNAME, створено ще один запис (A, TXT тощо) — RFC 1034 забороняє таке поєднання	Видалити всі інші записи на цьому імені, залишити тільки CNAME
dig повертає NXDOMAIN	Одруківка в імені запису або запис створено не в тій зоні	Перевірити точне написання імені та обрану зону в панелі
Браузер показує DNS_PROBE_FINISHED_NXDOMAIN	NS-делегування ще не поширилося або A-запис відсутній	Перевірити `dig NS` у реєстратора і зачекати TTL
Пошта повертає Host or domain name not found	MX-запис відсутній або вказує на неіснуюче ім'я	Створити MX і відповідний A-запис для вузла призначення

Тип запису	TTL у звичайній роботі	Коли знижувати
A / AAAA	3600–14400 секунд	до 300 секунд за 24–48 годин перед зміною IP
MX	3600–86400 секунд	перед зміною поштового провайдера
TXT (SPF, DKIM, верифікація)	3600 секунд	на час активного налагодження запису
NS (делегування зони)	86400 секунд і вище	практично ніколи — зміна NS і так потребує часу на рівні реєстру

Коли зміни в DNS не застосовуються

Домен делегований на сторонні NS (Cloudflare, інший хостинг) — записи в панелі ZevsHost ігноруються, редагувати потрібно там, де реально стоїть делегування
CNAME створено на імені, де вже є MX або TXT — конфлікт записів, зона не пройде валідацію при збереженні
Резолвер клієнта закешував старе значення — TTL ще не сплив, див. перевірку DNS propagation
Змінили NS і A-запис одночасно — складно зрозуміти, яка саме частина ще не оновилася

Окремий випадок — split-horizon DNS, коли всередині локальної мережі та ззовні один і той самий домен резолвиться по-різному через різні DNS-сервери. Якщо сайт відкривається з офісу, але не відкривається ззовні (або навпаки), насамперед перевіряють, який резолвер реально опитується на проблемній машині, а не саму зону на хостингу.

Перевірка результату

# Перевірка A-запису
dig yourdomain.com A +short

# Перевірка MX
dig yourdomain.com MX +short

# Перевірка через конкретний DNS-сервер, в обхід локального кешу
dig @8.8.8.8 yourdomain.com A +short

Якщо відповідь порожня, а домен точно делегований на ZevsHost, загальний принцип розв'язання імен розібраний у статті як працює DNS, включно з порядком опитування кореневих та авторитетних серверів.

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

Скільки чекати, якщо домен не відкривається одразу після зміни DNS-запису?

Записи домену кешуються резолверами на час, заданий значенням TTL, тому зміна не з'являється миттєво у всіх користувачів мережі. Одні провайдери оновлять кеш швидше, інші довше, доки не спливе старе значення TTL. Якщо відповідь не змінюється після помітного часу, варто перевірити сам запис через зовнішній резолвер, а не покладатися на локальний кеш браузера чи системи.

Чи потрібен окремий AAAA-запис, якщо хостинг працює лише через IPv4?

Окремий AAAA-запис потрібен лише тоді, коли сервер справді відповідає за IPv6-адресою. Якщо хостинг працює виключно через IPv4, додавати AAAA не обов'язково — її відсутність не впливає на доступність сайту для звичайних відвідувачів. Створення AAAA з випадковою чи застарілою адресою гірше за її відсутність: частина браузерів спробує саме IPv6 першою і отримає помилку з'єднання.

Чи можна налаштувати кілька MX-записів для резервного поштового сервера?

Так, стандарт пошти прямо передбачає кілька MX-записів з різними значеннями пріоритету. Основний сервер вказують з меншим числом пріоритету, а резервний — з більшим, і поштова система звертається до запасного сервера лише тоді, коли основний недоступний. Така схема підвищує надійність доставки листів без додаткового налаштування на боці відправника.

Як зрозуміти, через яку панель зараз керується DNS-зона домену — хостингу чи реєстратора?

Визначити це можна за NS-записами домену: якщо вони вказують на сервери імен хостингу, зона реально керується через панель хостингу, а правки в панелі реєстратора ні на що не впливають. Якщо ж NS залишилися від реєстратора, правильно навпаки — редагувати записи потрібно саме там, а не в панелі хостингу.