Основні DNS-записи: A, CNAME, MX, TXT — що це і як налаштувати

DNS (Domain Name System) працює як телефонна книга інтернету: перетворює зрозумілу людині назву домену, наприклад example.com, на технічну адресу, яку розуміють сервери — IP-адресу для сайту, поштовий сервер для листів, чи текстовий запис для підтвердження прав власності. Кожне таке правило перетворення зберігається у вигляді окремого DNS-запису. У цій статті — детально про чотири найважливіші типи записів, з якими рано чи пізно стикається кожен власник сайту: A, CNAME, MX і TXT, а також покроковий процес їх налаштування.

Що таке DNS-запис і де його редагувати

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

Кожен запис складається з кількох обов’язкових полів: тип запису (A, CNAME, MX тощо), ім’я (хост, для якого діє запис — наприклад @ для основного домену чи www для піддомену), значення (куди саме вказує запис) і TTL (як довго запис кешується перед перевіркою на актуальність).

A-запис: прив’язка домену до IP-адреси

A-запис (Address record) — найважливіший і найпростіший тип запису: він прив’язує ім’я домену безпосередньо до IPv4-адреси сервера, на якому фізично розміщений сайт. Коли хтось вводить у браузері example.com, саме A-запис підказує браузеру, на яку числову адресу (наприклад, 185.xxx.xxx.xxx) відправляти запит.

Типовий сайт має щонайменше два A-записи: один для основного домену (хост @) і один для www-версії (хост www), обидва вказують на ту саму IP-адресу хостингу. Якщоww-запис налаштований як CNAME на основний домен замість окремого A-запису, це теж працює — про це в наступному розділі.

Коли редагується A-запис: при переїзді на новий хостинг (нова IP-адреса сервера), при налаштуванні власного піддомену на окремий сервер (наприклад, app.example.com на інший сервер, ніж основний сайт), або якщо потрібно тимчасово перенаправити домен на сторінку технічного обслуговування на іншому сервері.

CNAME-запис: псевдонім для піддоменів

CNAME (Canonical Name) — запис-псевдонім, який вказує не на IP-адресу напряму, а на інше доменне ім’я. Наприклад, запис blog.example.com CNAME example.com означає: «якщо хтось звертається до blog.example.com, шукай відповідь там, де знаходиться example.com». Це зручно, бо якщо IP-адреса основного сайту зміниться, не потрібно вручну оновлювати кожен піддомен окремо — достатньо оновити один A-запис, а всі CNAME-піддомени автоматично підуть за ним.

CNAME найчастіше використовується для налаштування піддоменів сторонніх сервісів: наприклад, під’єднання поштового сервісу Google Workspace через mail.example.com, підключення платформи для лендінгів, чи налаштування піддомену для CDN-провайдера. Важливе технічне обмеження: CNAME не можна встановити для кореневого домену (хоста @) одночасно з іншими записами того самого хоста — на кореневому домені завжди повинен бути A-запис (або спеціальний ALIAS/ANAME-запис, який пропонують деякі DNS-провайдери як обхідний шлях для цього обмеження).

MX-запис: маршрутизація електронної пошти

MX (Mail Exchange) — запис, який вказує, який саме сервер відповідає за прийом електронної пошти для домену. Без коректного MX-запису листи на адреси кшталт info@example.com просто не будуть доставлені, навіть якщо сайт на example.com працює бездоганно — сайт і пошта керуються повністю окремими записами.

MX-запис має додаткове поле — пріоритет (значення від 0 і вище, чим менше число, тим вищий пріоритет). Це дозволяє налаштувати кілька поштових серверів як резервні: якщо основний сервер із найнижчим значенням пріоритету недоступний, пошта автоматично спробує доставитись через сервер з наступним за пріоритетом значенням.

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

TXT-запис: верифікація, SPF, DKIM, DMARC

TXT-запис — універсальний тип, що дозволяє прив’язати до домену довільний текстовий рядок. Спочатку призначався просто для нотаток адміністратора, але з часом став основним інструментом для двох критично важливих задач.

Верифікація власності домену

Багато сервісів — Google Search Console, Google Workspace, платформи email-маркетингу, SSL-центри сертифікації при DV-верифікації — просять додати спеціальний TXT-запис з унікальним кодом, щоб підтвердити, що саме ви керуєте доменом. Сервіс перевіряє наявність цього запису і після підтвердження надає доступ до відповідних функцій.

SPF (Sender Policy Framework)

TXT-запис, що перелічує, які саме сервери мають право надсилати пошту від імені вашого домену. Без коректного SPF-запису листи, надіслані з вашого домену, з високою ймовірністю потраплять у папку «Спам» отримувача або будуть відхилені зовсім — поштові сервіси на кшталт Gmail дедалі жорсткіше перевіряють цей запис як захист від підробки відправника (email spoofing).

DKIM (DomainKeys Identified Mail)

Ще один TXT-запис, який містить публічний криптографічний ключ. Він дозволяє отримувачу перевірити цифровий підпис листа і підтвердити, що лист дійсно надійшов з вашого домену й не був змінений під час пересилання. DKIM зазвичай генерується автоматично поштовим провайдером (наприклад, Google Workspace чи власним поштовим сервером хостингу) — власнику домену потрібно лише скопіювати виданий запис у DNS-зону.

DMARC (Domain-based Message Authentication)

Третій TXT-запис, який каже поштовим серверам отримувачів, що робити з листами, які не пройшли перевірку SPF чи DKIM — відхилити, помістити в спам чи пропустити з позначкою. DMARC також дозволяє отримувати звіти про спроби підробки листів від вашого домену, що корисно для виявлення фішингових кампаній, які маскуються під ваш бренд.

Інші типи записів: AAAA, NS, SRV

Окрім чотирьох основних типів, у DNS-зоні можуть зустрічатись і рідше використовувані записи, про які варто знати хоча б поверхово.

AAAA-запис — аналог A-запису, але для IPv6-адрес замість IPv4. Потрібен, якщо хостинг підтримує сучасний протокол IPv6 і ви хочете, щоб сайт був доступний і через нього.

NS-запис (Nameserver) — вказує, які саме сервери відповідають за DNS-зону всього домену. Саме зміна NS-записів (nameservers) на рівні реєстратора — це те, що передає керування DNS від одного провайдера до іншого, наприклад при підключенні Cloudflare.

SRV-запис (Service) — вузькоспеціалізований запис, що вказує на конкретний сервер і порт для окремих служб, наприклад VoIP-телефонії чи деяких протоколів миттєвих повідомлень. Для типового сайту на WordPress цей запис зазвичай не потрібен.

TTL: як швидко застосовуються зміни

TTL (Time To Live) — значення в секундах, яке визначає, як довго інші DNS-сервери у світі кешуватимуть отриману відповідь, перш ніж запитати актуальні дані знову. Типове значення — 3600 секунд (1 година) або 14400 секунд (4 години), хоча можна встановити й значно менше чи більше.

Практичний висновок: якщо плануєте важливу зміну — перенесення сайту на новий хостинг, зміну поштового провайдера — варто заздалегідь, за добу-дві, тимчасово зменшити TTL до 300 секунд (5 хвилин) для відповідних записів. Це дозволить новим значенням поширитись значно швидше в момент самої зміни, оскільки старі DNS-сервери оновлять кеш майже одразу, а не чекатимуть повний період старого, довшого TTL.

Порівняльна таблиця всіх типів записів

Типові сценарії налаштування

Типові помилки при редагуванні DNS

Робота з DNS-записами не терпить поспіху — навіть маленька помилка може зробити сайт чи пошту недоступними на години, поки не буде виправлена й повторно поширена.

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

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

Помилки в синтаксисі SPF-запису. SPF має строгий синтаксис, і навіть зайвий пробіл чи неправильний порядок механізмів (include, ip4, ~all) може призвести до того, що запис буде проігноровано поштовими серверами отримувачів або, навпаки, легітимна пошта почне потрапляти у спам.

Не враховане значення TTL перед важливою зміною. Якщо TTL встановлено на 24 години, а зміну потрібно застосувати негайно (наприклад, термінове перенесення сайту), доведеться чекати повний період TTL, доки всі DNS-сервери світу оновлять кешовану інформацію.

Одночасна робота з кількома панелями керування DNS. Якщо домен підключений і до Cloudflare, і до панелі хостингу, легко заплутатись, де саме редагувати записи — зміни в неактивній панелі просто не матимуть жодного ефекту, поки саме ця панель не вказана в NS-записах домену.

Покрокова інструкція налаштування DNS

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