DNS-записи: як налаштувати A, AAAA, CNAME, MX і TXT без помилок

DNS працює непомітно, поки все налаштовано правильно. Але одна помилкова крапка, старий nameserver або видалений MX-запис може одночасно вимкнути сайт, корпоративну пошту й підтвердження сторонніх сервісів.

Щоб безпечно керувати доменом, не потрібно запам’ятовувати всі стандарти. Потрібно розрізняти три рівні: де делеговано домен, яка DNS-зона є авторитетною та які записи всередині зони відповідають за сайт, пошту й інші сервіси.

У цьому матеріалі розберемо головні типи записів, типові конфігурації та порядок змін без простою.

Що таке DNS простими словами

DNS — розподілена система, яка пов’язує зрозумілі людям доменні імена з технічними адресами та службами. Коли відвідувач вводить example.com, DNS-резолвер шукає авторитетну відповідь і повертає IP-адресу сервера або інший потрібний запис.

Спрощений маршрут:

1. браузер або система перевіряє локальний кеш;
2. рекурсивний резолвер провайдера чи публічного DNS шукає відповідь;
3. кореневі та TLD-сервери підказують, які nameserver авторитетні для домену;
4. авторитетний сервер повертає запис із DNS-зони;
5. відповідь кешується на час TTL.

Перевірити, що домен повертає зараз, можна через DNS Lookup BB STUDIO. Інструмент показує фактичні записи, але перед зміною все одно потрібно визначити, яка панель керує авторитетною зоною.

Домен, nameserver і DNS-зона — не одне й те саме

Реєстратор зберігає право керування доменом і дозволяє змінювати делегування. Nameserver відповідає за DNS-зону. DNS-зона містить записи A, MX, TXT та інші.

Наприклад, домен можна зареєструвати в одного провайдера, використовувати DNS Cloudflare, розмістити сайт на іншому хостингу, а пошту — у Google Workspace або Microsoft 365. Це нормальна конфігурація.

Найпоширеніша помилка — редагувати записи в панелі реєстратора, хоча домен делегований на інші NS. Зміни збережуться в інтерфейсі, але інтернет їх не побачить.

Перед роботою зафіксуйте:

• поточні NS домену;
• провайдера авторитетної DNS-зони;
• повний експорт або скриншот записів;
• IP нового й старого сервера;
• сервіси, що залежать від домену;
• доступ до реєстратора, DNS і хостингу.

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

A — домен на IPv4-адресу

A-запис спрямовує ім’я на IPv4-адресу.

Type: A
Name: @
Value: 192.0.2.10
TTL: 300

Символ @ у багатьох панелях означає корінь домену: example.com. Для піддомену в полі Name вказують, наприклад, shop або api.

Не копіюйте тестову адресу з прикладу. Використовуйте IP, який надав ваш хостинг або адміністратор. Якщо IP сервера змінюється без повідомлення, прямий A-запис потребуватиме ручного оновлення.

AAAA — домен на IPv6-адресу

AAAA виконує ту саму функцію для IPv6.

Type: AAAA
Name: @
Value: 2001:db8::10
TTL: 300

Не додавайте AAAA «для повноти», якщо сервер не приймає трафік через IPv6. Частина пристроїв може обирати IPv6 і отримувати помилку, хоча IPv4 працює.

CNAME — псевдонім іншого імені

CNAME вказує не на IP, а на інше доменне ім’я.

Type: CNAME
Name: www
Target: example.com
TTL: 300

Такий запис часто використовують для www, CDN, SaaS-платформ і технічних піддоменів. На тому самому імені CNAME не повинен конфліктувати з іншими типами записів.

Для кореня домену стандартний CNAME зазвичай не підходить, тому провайдери пропонують ALIAS, ANAME або CNAME flattening. Це реалізації конкретного DNS-сервісу, а не привід бездумно створювати CNAME на @.

MX — маршрутизація корпоративної пошти

MX-записи повідомляють, які сервери приймають пошту для домену. Вони містять ім’я поштового сервера та пріоритет.

Type: MX
Name: @
Priority: 10
Target: mail.example.net
TTL: 3600

Менше число означає вищий пріоритет. Якщо постачальник дає кілька MX, внесіть усі значення точно за інструкцією. MX має вказувати на hostname, а не безпосередньо на IP; також небажано спрямовувати MX на ім’я, яке є CNAME.

Заміна хостингу сайту не означає, що потрібно змінювати MX. Якщо пошта працює в окремому сервісі, її записи потрібно зберегти.

TXT — текстові політики й підтвердження

TXT використовують для:

• підтвердження права на домен;
• SPF-політики відправників;
• DKIM-публічного ключа;
• DMARC-політики;
• верифікації пошукових, рекламних і SaaS-сервісів.

Один домен може мати багато TXT на різних іменах. Але кілька окремих SPF-записів на корені створюють помилку: дозволені джерела потрібно об’єднати в одну SPF-політику.

Для підготовки синтаксису скористайтеся генератором SPF та генератором DMARC, а потім звірте значення з документацією вашого поштового сервісу.

NS — делегування зони

NS визначають авторитетні nameserver. На рівні реєстратора вони делегують увесь домен, а всередині зони можуть делегувати окремий піддомен.

Не змінюйте NS як звичайний спосіб «підключити сайт». Заміна NS переносить керування всією зоною. Якщо в новій зоні немає MX, TXT, CAA чи службових піддоменів, частина інфраструктури зникне.

CAA — хто може видавати SSL-сертифікати

CAA дозволяє вказати центри сертифікації, яким дозволено випускати сертифікати для домену. Запис підвищує контроль, але помилкова політика може заблокувати автоматичне продовження SSL.

Перед додаванням перевірте, хто фактично видає сертифікат вашого хостингу або CDN.

SRV — адреса й порт сервісу

SRV описує hostname, порт, пріоритет і вагу мережевого сервісу. Його застосовують для VoIP, чатів, корпоративних платформ та інших протоколів. Значення потрібно переносити точно за документацією постачальника.

Поля Name, Value, Priority і TTL

У DNS-записах не вказують шлях сторінки. Значення https://example.com/catalog/ не є коректною ціллю A або CNAME. DNS працює з іменами й адресами, а перенаправлення на конкретний URL виконує вебсервер або застосунок.

Як працює TTL і «поширення DNS»

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

Практичний порядок перед міграцією:

1. за 24–48 годин зменшити TTL потрібних записів, наприклад до 300 секунд;
2. дочекатися завершення попереднього високого TTL;
3. підготувати новий сервер і перевірити його без зміни DNS;
4. перемкнути записи;
5. зберігати старий сервер активним протягом перехідного періоду;
6. після стабілізації повернути звичайний TTL.

«Поширення» не є однією глобальною кнопкою. Авторитетний сервер може відповідати новим значенням одразу, а рекурсивні резолвери ще триматимуть старий кеш.

Типові конфігурації

Сайт на одному сервері

@      A       192.0.2.10
www    CNAME   example.com

Вебсервер повинен знати обидва hostname, а SSL — покривати example.com і www.example.com.

Сайт і пошта в різних сервісах

@      A       192.0.2.10
www    CNAME   example.com
@      MX 10   mail.provider.example
@      TXT     v=spf1 include:provider.example -all

Зміна A впливає на сайт, але не повинна видаляти MX і TXT. Саме тому повне очищення зони під час перенесення є небезпечним.

Піддомен для окремого сервісу

shop   CNAME   shops.platform.example

У платформі також потрібно додати shop.example.com, підтвердити домен і дочекатися випуску SSL. Самого DNS недостатньо.

Як підключити домен до хостингу

Надійна послідовність:

1. додайте домен у панель нового хостингу;
2. завантажте сайт і базу даних;
3. налаштуйте змінні середовища, cron, поштову відправку та кеш;
4. перевірте сайт через тимчасову адресу або локальний hosts-файл;
5. отримайте точні A, AAAA чи CNAME від хостингу;
6. змініть лише потрібні записи;
7. випустіть або перевірте SSL;
8. протестуйте сайт, форми, оплату й пошту;
9. залиште старий сервер доступним на час переходу.

Якщо інфраструктура ще не обрана, порівняйте вимоги й формати хостингу для сайту. Під час розробки нового сайту список доменів, піддоменів і сторонніх інтеграцій краще закласти до запуску.

Як перенести DNS без простою

Перемикання nameserver потребує більше підготовки, ніж зміна одного A-запису.

До зміни NS

• створіть нову зону з усіма записами;
• порівняйте A, AAAA, CNAME, MX, TXT, CAA і SRV;
• перевірте службові піддомени;
• скопіюйте SPF, DKIM і DMARC;
• зменште TTL у старій зоні завчасно;
• переконайтеся, що DNSSEC не залишить старий DS-запис.

Під час зміни

• змініть NS у реєстратора;
• не вимикайте стару DNS-зону;
• перевіряйте відповіді через кілька незалежних резолверів;
• контролюйте сайт, пошту та сертифікати окремо.

Після зміни

• переконайтеся, що всі авторитетні сервери відповідають однаково;
• надішліть і прийміть тестові листи;
• перевірте форми, платежі, webhooks і API;
• лише після стабілізації видаляйте стару інфраструктуру.

DNS і корпоративна пошта

Для приймання листів потрібні MX. Для репутації та захисту від підміни зазвичай налаштовують SPF, DKIM і DMARC.

• SPF перелічує дозволені сервери відправлення;
• DKIM додає криптографічний підпис, а публічний ключ публікується в DNS;
• DMARC визначає політику перевірки й адресу звітів.

Не вигадуйте значення самостійно: беріть MX, DKIM selector та include-механізми з панелі поштового постачальника. Починайте DMARC із моніторингу, аналізуйте звіти й лише потім посилюйте політику, щоб не заблокувати легальні сервіси розсилки.

DNS, HTTPS та індексація

Після зміни IP вебсервер має повертати правильний сайт для всіх потрібних hostname. Якщо новий сервер показує заглушку, нескінченний редирект або неправильний сертифікат, проблема вже не обов’язково в DNS.

Перевірте:

• HTTP і HTTPS;
• корінь домену та www;
• усі мовні версії;
• canonical і sitemap;
• robots.txt;
• статуси 200, 301, 404 і 5xx;
• Search Console після міграції.

Як перевірити DNS після зміни

У браузерному інструменті

Перевірте A, AAAA, CNAME, MX, TXT, NS і CAA. Звертайте увагу не лише на наявність запису, а й на авторитетні NS та TTL.

Через командний рядок

nslookup example.com
nslookup -type=mx example.com
nslookup -type=txt example.com

Або через dig:

dig example.com A
dig www.example.com CNAME
dig example.com MX
dig example.com TXT
dig example.com NS

Для діагностики корисно запитати конкретний авторитетний nameserver і порівняти його відповідь із публічними резолверами. Локальний ipconfig /flushdns очищає кеш вашого Windows, але не очищає кеш провайдера або всього інтернету.

Типові помилки

1. Записи редагують не в авторитетній зоні.
2. Домен двічі дописується в полі Name.
3. У CNAME або MX вставляють повний URL із https://.
4. На одному імені конфліктують CNAME та інші записи.
5. AAAA веде на сервер без робочого IPv6.
6. Під час перенесення видаляють MX, SPF, DKIM або DMARC.
7. Створюють два окремі SPF-записи.
8. MX спрямовують на IP або CNAME.
9. NS змінюють без копії повної зони.
10. Високий TTL зменшують уже після перемикання.
11. Старий сервер вимикають одразу.
12. DNSSEC залишається пов’язаним зі старим провайдером.
13. Wildcard * використовують замість точних піддоменів без потреби.
14. Після DNS не перевіряють SSL, форми та пошту.

Безпека DNS

• увімкніть двофакторну автентифікацію в реєстратора та DNS-провайдера;
• використовуйте окремі облікові записи й мінімальні права;
• забороніть передачу домену без додаткового підтвердження;
• зберігайте резервну копію зони;
• ведіть журнал змін;
• видаляйте застарілі verification TXT;
• перевіряйте dangling CNAME, що ведуть на уже не контрольований сервіс;
• налаштовуйте DNSSEC лише з розумінням зв’язку між DNSKEY і DS;
• контролюйте строк реєстрації домену та контакти власника.

Dangling CNAME особливо небезпечний: якщо піддомен веде на видалений ресурс SaaS, стороння особа іноді може зареєструвати такий ресурс і перехопити піддомен.

Чекліст перед збереженням запису

• я знаю, де розміщена авторитетна зона;
• збережено резервну копію поточних записів;
• тип запису відповідає інструкції сервісу;
• Name не містить зайвого домену;
• Value не містить протоколу чи шляху без потреби;
• IP або hostname перевірено;
• TTL обрано з урахуванням міграції;
• MX і поштові TXT не видаляються;
• CNAME не конфліктує з іншими записами;
• AAAA додано лише для робочого IPv6;
• SSL зможе покрити новий hostname;
• визначено спосіб перевірки й відкату;
• старий сервер залишиться доступним у перехідний період.

Висновок

Безпечне налаштування DNS починається не з кнопки Add record, а з карти залежностей домену. A й AAAA ведуть на IP, CNAME створює псевдонім, MX відповідає за приймання пошти, TXT зберігає політики й підтвердження, а NS визначає, де взагалі знаходиться авторитетна зона.

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