DNS-записи: інструкція для тих, хто досі плутає A, CNAME, MX і TXT

Уявіть, що ви щойно купили домен, підключили хостинг, налаштували SSL - а сайт не відкривається. Пошта не приходить. Підтвердження домену в Google Search Console повисло в повітрі. Ви дивитесь на панель DNS-записів і бачите рядки літер, цифр та крапок, які нагадують щось середнє між кодом запуску ракети та рецептом від бабусі, написаним латиницею. Знайомо? Ви не самотні. За моїми спостереженнями, близько 70% власників сайтів ніколи свідомо не редагували DNS-записи - і щоразу, коли доводиться, починається легка паніка. Давайте розберемо цю тему так, щоб після прочитання ви відчували себе впевнено перед будь-якою DNS-панеллю.

Що таке DNS-записи і навіщо вони взагалі потрібні

DNS (Domain Name System) - це, по суті, телефонна книга інтернету. Коли хтось вводить у браузер vashsite.com.ua, комп'ютер не розуміє людських слів. Йому потрібна IP-адреса - числовий код на кшталт 185.230.63.107. DNS-записи - це інструкції, які кажуть: "Коли хтось шукає цей домен, направ його сюди".

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

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

Розбираємо кожен тип запису без академічної нудьги

Замість того щоб цитувати RFC-документи, давайте розглянемо кожен тип через призму реальних задач, які він вирішує.

Тепер давайте по кожному детальніше.

A-запис - це хребет вашого домену. Без нього нічого не працює. Ви кажете: "Домен vashsite.com.ua живе за адресою 185.230.63.107". Крапка. Якщо ви змінили хостинг - перше, що треба оновити, це A-запис.

CNAME - хитра штука. Він не вказує на IP-адресу, а каже: "Подивись на інший домен і зроби те саме". Наприклад, ви хочете, щоб www.vashsite.com.ua вів туди ж, куди й vashsite.com.ua. Замість дублювання A-запису ви створюєте CNAME: www -> vashsite.com.ua. Елегантно і практично.

MX-запис - це диспетчер вашої пошти. Без нього лист на info@vashsite.com.ua просто загубиться в цифровому вакуумі. Зверніть увагу на пріоритет (число від 1 до 100): чим менше число, тим вищий пріоритет. Якщо основний сервер впаде, пошта піде на резервний.

TXT-запис - швейцарський ніж DNS. Сюди пишуть все: SPF-правила для захисту пошти від спуфінгу, DKIM-підписи, верифікаційні коди Google, Facebook, різних сервісів. Якщо вам колись казали "додайте цей рядок у DNS" - мова, швидше за все, про TXT.

П'ять помилок, які роблять навіть досвідчені адміністратори

За 15 років я бачив сотні зламаних DNS-конфігурацій. Ось хіт-парад найпопулярніших проблем.

1. CNAME на кореневому домені. Технічно, кореневий домен (vashsite.com.ua без www) не повинен мати CNAME-запис. Це порушує стандарт RFC 1912, і деякі DNS-резолвери просто проігнорують його. Використовуйте A-запис для кореня, CNAME - для піддоменів.
2. Забули крапку в кінці значення. У деяких DNS-панелях запис "mail.google.com" без крапки в кінці автоматично перетворюється на "mail.google.com.vashsite.com.ua". Абсурд? Так. Але ця помилка ламає пошту тисячам людей щороку.
3. Конфліктуючі записи. A-запис і CNAME на одному піддомені - це як два GPS-навігатори, що кричать різні маршрути одночасно. DNS-сервер не знає, кого слухати.
4. Застарілі MX-записи. Перейшли з корпоративної пошти на Google Workspace, а старі MX-записи залишились. Результат - частина листів йде в нікуди.
5. TTL на мінімумі "на завжди". Поставили TTL 86400 (24 години) і забули. А потім дивуєтесь, чому після зміни A-запису сайт годинами показує стару версію.

TTL - маленьке число з великими наслідками

TTL (Time To Live) - це час у секундах, протягом якого DNS-резолвери кешують ваш запис. Простіше: це те, як довго інтернет "пам'ятає" вашу стару адресу після зміни.

Ось практична порада, яку рідко дають у підручниках:

"Перед будь-якою міграцією знизьте TTL до 300 секунд (5 хвилин) мінімум за 24-48 годин до переїзду. Це дозволить змінам поширитись значно швидше. Після завершення міграції поверніть TTL на 3600-86400 секунд, щоб зменшити навантаження на DNS-сервери." - рекомендація Cloudflare у документації для розробників

У звичайному режимі TTL 3600 (1 година) - золота середина. Менше - DNS-сервери отримують зайве навантаження. Більше - зміни поширюються болісно повільно.

• TTL 300 - для підготовки до міграції або активних змін
• TTL 3600 - стандартний режим для більшості сайтів
• TTL 86400 - для записів, які ніколи не змінюються (наприклад, MX великих провайдерів)

Як перевірити DNS-записи і не зійти з розуму

Ви внесли зміни. Що далі? Сидіти і чекати? Ні. Є інструменти, які покажуть стан ваших DNS-записів у реальному часі з різних точок планети.

1. dig (Linux/Mac) або nslookup (Windows) - командний рядок. Швидко, точно, без зайвого. Команда dig vashsite.com.ua A покаже поточний A-запис.
2. whatsmydns.net - веб-сервіс, який перевіряє DNS з десятків серверів по всьому світу. Бачите зелені галочки скрізь - все гаразд. Червоні хрестики - зміни ще не дійшли.
3. MXToolbox.com - ідеальний для перевірки MX, SPF, DKIM і DMARC. Якщо ваша пошта потрапляє в спам - починайте саме звідси.
4. Google Admin Toolbox - Dig - зручний інтерфейс від Google для перевірки будь-яких DNS-записів без терміналу.

Золоте правило: завжди перевіряйте DNS після будь-якої зміни. Не "завтра", не "коли сайт зламається" - одразу. Витратьте 30 секунд на whatsmydns.net і заощадте години нервів.

SPF, DKIM і DMARC - трійця, яка рятує вашу пошту від сміттєвого бака

Це окрема і дуже болюча тема. Якщо ви відправляєте листи з корпоративної адреси на своєму домені і не налаштували ці три речі - ваші листи з високою ймовірністю потрапляють у спам. Або, ще гірше, хтось може надсилати листи "від вашого імені".

SPF (Sender Policy Framework) - TXT-запис, який каже: "Листи від мого домену мають право надсилати тільки ці сервери". Приклад для Google Workspace:

v=spf1 include:_spf.google.com ~all

DKIM (DomainKeys Identified Mail) - цифровий підпис, який підтверджує, що лист не підробка. Генерується вашим поштовим провайдером, додається як TXT-запис.

DMARC - політика, що каже отримувачу: "Якщо лист не пройшов перевірку SPF і DKIM - ось що з ним робити". Мінімальна конфігурація:

v=DMARC1; p=quarantine; rua=mailto:dmarc@vashsite.com.ua

• p=none - нічого не робити, тільки збирати звіти (для початку)
• p=quarantine - підозрілі листи в спам
• p=reject - відхиляти повністю (максимальний захист)

Без цієї трійці у 2025 році ваша доменна пошта - як відкритий будинок без замка. Gmail і Outlook стали надзвичайно суворими: з лютого 2024 року Google вимагає SPF і DKIM для всіх, хто надсилає більше 5000 листів на день. Навіть якщо ви надсилаєте 50 - краще налаштувати одразу.

Чи варто переносити DNS на Cloudflare або залишити у реєстратора

Питання, яке виникає майже у кожного. Коротка відповідь: залежить від ваших потреб. Довша - ось таблиця.

Для більшості сайтів Cloudflare - розумний вибір. Безкоштовний DNS із глобальною мережею, захистом та аналітикою. Але є нюанс: якщо Cloudflare раптом заблокує ваш акаунт (а це буває), ви тимчасово втратите контроль над DNS. Тому завжди тримайте доступ до панелі реєстратора і знайте, як повернути NS-записи назад.

DNS-записи - це не магія. Це логіка, записана простими правилами. Раз розібравшись, ви перестанете боятися панелі DNS і почнете бачити її тим, чим вона є: простим маршрутизатором, що направляє трафік, пошту і верифікацію у потрібне місце. Єдине питання, яке залишається: коли востаннє ви заглядали у свої DNS-записи? Можливо, саме зараз там лежить застарілий MX-запис, який тихо з'їдає половину ваших клієнтських листів.