DNS (Domain Name System) перетворює доменні імена на IP-адреси. Коли ви вводите zevshost.net, браузер надсилає запит до DNS-сервера і отримує IP-адресу сервера.

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

Тип	Призначення	Приклад
A	Домен → IPv4	example.com → 1.2.3.4
AAAA	Домен → IPv6	example.com → 2001:db8::1
CNAME	Псевдонім домену	www → example.com
MX	Поштовий сервер	mail.example.com (priority 10)
TXT	Текстова інформація	SPF, DKIM, верифікація
NS	Сервери імен	ns1.zevshost.net

A-запис: підключити сайт

# Прив'язати домен до IP сервера
example.com.   IN A  5.135.49.174
www.example.com IN A  5.135.49.174

CNAME: псевдонім

# www → основний домен (зручно при зміні IP)
www   IN CNAME example.com.

# Субдомен для CDN
cdn   IN CNAME cdn.cloudflare.com.

⚠️ CNAME не можна використовувати для кореневого домену (@). Для apex-домену використовуйте A-запис або ALIAS.

MX-запис: налаштування пошти

# Google Workspace
@  IN MX 1  aspmx.l.google.com.
@  IN MX 5  alt1.aspmx.l.google.com.
@  IN MX 10 alt2.aspmx.l.google.com.

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

# SPF — дозволені відправники пошти
@  IN TXT "v=spf1 include:_spf.google.com ~all"

# Верифікація Google Search Console
@  IN TXT "google-site-verification=xxxxxx"

# DMARC
_dmarc  IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

Час поширення DNS (TTL)

TTL (Time To Live) — час кешування запису в секундах. Стандартні значення:

3600 (1 година) — стандарт
300 (5 хвилин) — перед міграцією
86400 (1 день) — для стабільних записів

💡 Перед міграцією сайту знизьте TTL до 300 за 24 години. Після успішного переїзду поверніть 3600.

Часті помилки під час роботи з DNS-записами

Помилка	Причина	Рішення
CNAME додано на кореневий домен (@), зона не зберігається	RFC 1034 забороняє CNAME на apex-домені, якщо там уже є інші записи (наприклад, NS, SOA)	Використати A-запис для кореня або, якщо провайдер підтримує, запис типу ALIAS/ANAME
Два A-записи з однаковим іменем і різними IP не працюють як очікувалося	Це не помилка — DNS віддає обидва IP за round-robin, розподіляючи навантаження випадково між клієнтами, а не як failover	Для відмовостійкості потрібен саме DNS failover з перевіркою доступності, а не просто другий A-запис
TXT-запис довший за 255 символів обрізається	Один рядок TXT-запису за стандартом DNS обмежений 255 байтами	Розбити довге значення на кілька рядків у лапках — більшість панелей склеюють їх автоматично
MX-запис вказує на CNAME, пошта не доставляється	RFC 2181 вимагає, щоб MX вказував на A/AAAA-запис, а не на CNAME	Переконатися, що ім'я в MX-записі резолвиться напряму в A-запис, без ланцюжка CNAME

SRV-записи та інші спеціальні типи

Окрім основних п'яти типів, DNS підтримує спеціалізовані записи для конкретних сервісів — наприклад, SRV для вказівки хоста та порту сервісу (використовується в XMPP, SIP, серверах Minecraft).

# Формат SRV-запису
_service._proto.name. TTL IN SRV priority weight port target.

# Приклад для XMPP-сервера
_xmpp-client._tcp.example.com. 3600 IN SRV 5 0 5222 xmpp.example.com.

Детальний розбір синтаксису та практичних прикладів — у статті про SRV-записи DNS.

Перевірка DNS-записів

# Перевірити всі записи одразу (не всі резолвери підтримують ANY)
dig example.com ANY

# Перевірити конкретний тип
dig example.com MX +short
dig example.com TXT +short

# Перевірити через авторитетний сервер напряму, а не через кеш
dig @ns1.zevshost.net example.com A

Прямий запит до авторитетного сервера (@ns1.zevshost.net) показує актуальне значення без кешу резолвера
Порожня відповідь у ANSWER SECTION означає відсутність запису цього типу, а не помилку сервера
Прапорець +short прибирає службові рядки і залишає лише значення записів

Коли одного A-запису недостатньо

Потрібне балансування навантаження між кількома серверами з перевіркою доступності — простий round-robin із кількох A-записів не прибирає впалий сервер з відповіді автоматично
Сайт має працювати за IPv6 — потрібен окремий AAAA-запис, лише IPv4 A-записів для цього недостатньо
Потрібен георозподіл трафіку до найближчого дата-центру — потрібен Anycast або GeoDNS поверх звичайних A-записів
Потрібна доставка пошти — MX-запис обов'язковий окремо від A, поштові сервери не використовують A-запис домену напряму для маршрутизації листів

PTR-запис: зворотне зіставлення IP у домен

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

# PTR налаштовується не в зоні домену, а в зоні провайдера, що володіє IP
5.135.49.174.in-addr.arpa. IN PTR mail.example.com.

Детальне налаштування PTR — у статті про зворотний DNS (PTR).