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-only 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).