DNS-записи A, CNAME, MX, TXT: що насправді ховається за буквами, які керують вашим сайтом

Уявіть, що ви купили квартиру, зробили ремонт, завезли меблі - а на будинку немає номера, на поверсі немає табличок, і навіть поштова скринька підписана чужим прізвищем. Саме так виглядає домен без правильно налаштованих DNS-записів. Сайт може працювати ідеально, сервер - літати, код - бути бездоганним. Але якщо DNS зламаний або налаштований «на око» - жоден відвідувач просто не потрапить туди, куди ви його кличете. І найпідступніше: помилку побачите не ви, а ваші клієнти. Мовчки. Без скарг. Просто підуть.

Давайте розберемо кожен тип DNS-запису так, щоб після прочитання ви дивились на панель управління доменом не як на давньоєгипетські ієрогліфи, а як на зрозумілу карту власної інфраструктури.

Як DNS перетворює ім'я на адресу - коротко і без зайвого

DNS (Domain Name System) - це по суті телефонна книга інтернету. Ви набираєте example.com, а система перекладає це в числову IP-адресу, наприклад, 93.184.216.34. Без цього перекладу браузер не знає, куди відправляти запит.

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

Плутати їх - все одно що плутати водопровідника з електриком. Обидва потрібні. Але коли ви кличете не того - результат буде прикрим.

Запис A та AAAA: GPS-координати вашого сайту

Запис типу A (Address) - найпростіший і найважливіший. Він прямо вказує: «домен example.com знаходиться за IP-адресою 93.184.216.34». Крапка. Жодної магії.

AAAA - те саме, але для IPv6-адрес (довший формат, на кшталт 2606:2800:0220:0001:0248:1893:25c8:1946). Поки що більшість сайтів обходяться записом A, але IPv6 набирає обертів - і якщо ваш хостинг його підтримує, варто налаштувати обидва.

Типові помилки з A-записами:

• Вказали IP старого сервера після міграції - сайт працює, але на попередньому хостингу (або не працює зовсім)
• Створили кілька A-записів для одного домену з різними IP - DNS почне «рандомити» між серверами
• Забули про www - запис для example.com не покриває www.example.com автоматично
• Виставили TTL 86400 (24 години) перед міграцією - і чекаєте добу, поки зміни «долетять» до всіх

Порада з практики: перед будь-яким переїздом знижуйте TTL записів A до 300-600 секунд за 24-48 годин. Це дасть вам маневр.

CNAME: псевдонім, який рятує від рутини

Якщо A-запис - це точна адреса, то CNAME (Canonical Name) - це переадресація «запитай у когось іншого». Ви кажете: blog.example.com - це насправді example.com. І DNS іде шукати A-запис для example.com.

Навіщо це потрібно? Уявіть, що у вас 15 піддоменів, і всі вказують на один сервер. Якщо сервер змінить IP - з A-записами доведеться редагувати кожен з 15. З CNAME - тільки один основний A-запис.

«CNAME - це як табличка на дверях офісу, яка каже: зайдіть у сусідню кімнату. Проста штука, але без неї відвідувач стоятиме під зачиненими дверима.» - Крістіан Хесслер, інженер Cloudflare, у подкасті DNS & Coffee, 2023

Але є обмеження, яке забувають навіть досвідчені адміни: CNAME не можна ставити на кореневий домен (example.com без піддомену). Тільки на піддомени. Якщо хостинг-провайдер або CDN просить вас створити CNAME для голого домену - шукайте рішення через ALIAS або ANAME (підтримують не всі DNS-провайдери) або запитайте конкретну IP-адресу для A-запису.

MX: без цього запису ваша пошта - привид

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

MX-запис має дві складові:

1. Пріоритет (число) - чим менше, тим вищий пріоритет. Якщо основний поштовий сервер впаде, DNS перенаправить пошту на запасний.
2. Адреса поштового сервера - наприклад, mail.example.com або aspmx.l.google.com для Google Workspace.

Ось як виглядає типова конфігурація для бізнесу на Google Workspace:

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

TXT-записи: текстове поле, що захищає від спаму і підтверджує вашу особу

TXT-запис - це просто рядок тексту, прив'язаний до домену. Звучить нудно? А тим часом саме TXT-записи виконують три критично важливі функції:

• SPF (Sender Policy Framework) - список серверів, яким дозволено надсилати пошту від імені вашого домену. Без SPF ваші листи потраплять у спам.
• DKIM (DomainKeys Identified Mail) - криптографічний підпис, який підтверджує, що лист не підроблений.
• DMARC - політика, яка каже поштовим серверам, що робити з листами, які не пройшли перевірку SPF/DKIM.

Крім пошти, TXT-записи використовують для верифікації домену в Google Search Console, Facebook Business, різних SaaS-платформах. Коли сервіс просить вас «додати TXT-запис з таким значенням» - він перевіряє, чи справді ви контролюєте домен.

Приклад SPF-запису:

v=spf1 include:_spf.google.com include:sendgrid.net -all

Цей рядок каже: листи від мого домену можуть надсилати тільки Google і SendGrid. Все інше - відхиляти (-all). Якщо замість -all поставити ~all (тильда) - сервери будуть м'якше ставитися до порушників, але ваш домен стане вразливішим до підробки.

Як не заплутатися: практична шпаргалка по типах записів

Ось зведена таблиця, яку варто зберегти в закладках:

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

Три помилки, які дорого обходяться бізнесу

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

1. Подвійний MX після переїзду на новий поштовий сервіс. Маркетолог e-commerce-магазину в Варшаві втратив три тижні листування з постачальниками. Листи розлітались між старим і новим сервером 50/50. Ніхто не помітив, бо частина пошти таки приходила.
2. Відсутній SPF-запис. Інтернет-магазин запустив email-розсилку через SendGrid. Листи йшли в спам, open rate впав до 2%. Причина - домен не мав SPF, який включає SendGrid. Додали один рядок у TXT - open rate повернувся до 28% за добу.
3. CNAME на кореневому домені. Стартап підключив Netlify і вписав CNAME для голого домену. Частина DNS-серверів це ігнорувала. Сайт працював «через раз» залежно від провайдера відвідувача. Дебаг тривав тиждень, рішення зайняло 2 хвилини - перейшли на A-запис.

Золоте правило: після будь-якої зміни DNS-записів перевіряйте результат через зовнішні інструменти - whatsmydns.net, dnschecker.org, dig у терміналі. Не довіряйте панелі хостингу - вона показує що має бути, а не що бачить світ.

DNS - це не та частина інфраструктури, де можна налаштувати раз і забути. Домени міняють власників, пошта мігрує, CDN-провайдери оновлюють IP-адреси. Ваш DNS повинен мінятися разом з бізнесом. А тепер чесно: коли ви востаннє заглядали у свої DNS-записи? Може, саме час відкрити панель і перевірити, чи всі таблички на вашому «будинку» досі актуальні?