Настройка DNS для домена: полное руководство по A, CNAME, MX и управлению зоной

DNS-записи определяют, куда направлять посетителей сайта и электронные письма для вашего домена. Без корректно настроенной зоны сайт не откроется в браузере, а почта не дойдёт до адресатов. Это руководство даёт готовые конфигурации A, CNAME, MX, TXT и NS-записей, которые вы примените сразу после прочтения.

Вы узнаете синтаксис каждой записи, научитесь добавлять их в панели хостинга и у облачных провайдеров, а также проверите результат утилитами dig и nslookup. Все примеры проверены на практике и актуальны на июль 2026 года.

Что такое DNS-записи и зачем они нужны

Система доменных имён (DNS) работает как телефонная книга интернета: преобразует понятные человеку имена (example.com) в IP-адреса, с которыми работают серверы и маршрутизаторы. Когда пользователь вводит адрес в браузере, его компьютер отправляет запрос к DNS-резолверу, тот проходит цепочку от корневых серверов до авторитетного DNS-сервера домена и возвращает IP.

Ресурсные записи (Resource Records) - это строки в файле зоны, которые сообщают резолверам, какой IP у веб-сервера, куда слать почту и какие серверы считаются авторитетными для домена. Шесть основных типов, которые вы будете настраивать:

• A - связывает домен с IPv4-адресом.
• AAAA - то же для IPv6.
• CNAME - создаёт псевдоним, указывающий на другой домен.
• MX - задаёт почтовый сервер и его приоритет.
• TXT - хранит произвольный текст для верификации и почтовых политик.
• NS - определяет авторитетные DNS-серверы зоны.

Ошибка в одной записи способна положить сайт или остановить приём писем. Дальше разберём синтаксис каждого типа с примерами, которые вы скопируете и адаптируете под свой проект.

Типы DNS-записей: синтаксис и примеры использования

A и AAAA: связываем домен с IP-адресом

Запись A (Address) сопоставляет доменное имя с 32-битным IPv4-адресом. Это базовая запись для любого веб-сайта. Синтаксис в файле зоны:

example.com.  IN  A  192.0.2.1
www.example.com.  IN  A  192.0.2.1

Точка в конце имени обязательна в файлах зон BIND - она обозначает FQDN (полностью определённое доменное имя). В веб-интерфейсах панелей управления точку ставить не нужно, система добавляет её автоматически.

Для поддоменов создаётся отдельная A-запись с именем поддомена. Например, запись для api.example.com с именем api и значением 198.51.100.10 направит трафик на отдельный сервер API.

Запись AAAA выполняет ту же функцию для 128-битных IPv6-адресов. Синтаксис аналогичен:

example.com.  IN  AAAA  2001:db8::1

Если ваш сервер поддерживает оба протокола, добавьте обе записи. Клиенты с IPv6 будут использовать AAAA, остальные - A. Отсутствие AAAA при доступном IPv6-подключении клиента вызовет задержку, пока браузер не переключится на IPv4.

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

CNAME (Canonical Name) указывает, что один домен является псевдонимом другого. Типовой сценарий - поддомен www, который ссылается на основной домен:

www.example.com.  IN  CNAME  example.com.

Резолвер, получив запрос для www.example.com, видит CNAME и делает повторный запрос для example.com, чтобы получить итоговый A-запись. Это добавляет одну итерацию разрешения, но упрощает администрирование: при смене IP сервера достаточно обновить одну A-запись для example.com.

Критичное ограничение: CNAME нельзя использовать для корневого домена (apex). Запись вида example.com. IN CNAME other.com. нарушает стандарт RFC 1912, потому что у корневого домена уже есть обязательные NS и SOA-записи. Для обхода этого ограничения некоторые DNS-провайдеры предлагают проприетарные типы - ALIAS у DNSimple, ANAME у DNS Made Easy, CNAME-флаттенинг у Cloudflare. Они возвращают A-запись вместо CNAME на этапе резолвинга.

Второй частый сценарий для CNAME - подключение поддомена к внешнему сервису. Например, поддомен status.example.com можно направить на хостинг статус-страницы через CNAME на statuspage.io, не раскрывая IP-адреса чужой платформы.

MX: направляем почту на нужный сервер

MX-запись (Mail Exchanger) сообщает, какой сервер принимает почту для домена, и с каким приоритетом. Синтаксис:

example.com.  IN  MX  10  mail.example.com.
example.com.  IN  MX  20  backup-mail.example.com.

Число перед именем сервера - приоритет. Меньшее значение означает более высокий приоритет. Отправляющий почтовый сервер сначала пытается доставить письмо на хост с приоритетом 10. Если он недоступен, пробуется приоритет 20. Одинаковые приоритеты распределяют нагрузку round-robin.

Для Google Workspace потребуются записи:

example.com.  IN  MX  1  ASPMX.L.GOOGLE.COM.
example.com.  IN  MX  5  ALT1.ASPMX.L.GOOGLE.COM.
example.com.  IN  MX  5  ALT2.ASPMX.L.GOOGLE.COM.
example.com.  IN  MX  10  ALT3.ASPMX.L.GOOGLE.COM.
example.com.  IN  MX  10  ALT4.ASPMX.L.GOOGLE.COM.

Для Яндекс.Почты:

example.com.  IN  MX  10  mx.yandex.net.

Важно: значение MX-записи всегда должно указывать на доменное имя, а не на IP-адрес. Указание IP формально допустимо, но многие почтовые системы отклонят такую конфигурацию.

TXT: верификация и почтовые политики

TXT-записи хранят произвольные текстовые данные. Два основных применения - подтверждение владения доменом и настройка почтовых политик SPF, DKIM и DMARC.

Google Search Console требует добавить TXT-запись вида:

example.com.  IN  TXT  "google-site-verification=rXOxyZounnZasA8Z7oaD3c14JdjS9aKSWvsR1EbUSIQ"

SPF (Sender Policy Framework) определяет, какие серверы могут отправлять почту от имени домена:

example.com.  IN  TXT  "v=spf1 include:_spf.google.com ~all"

Директива ~all означает SOFTFAIL - письма от неавторизованных серверов принимаются, но помечаются как подозрительные. -all жёстко отклоняет такие письма.

DKIM-запись публикует открытый ключ для проверки цифровой подписи писем. Её структура специфична для почтового провайдера, имя записи включает селектор: google._domainkey.example.com.

DMARC-запись задаёт политику для писем, не прошедших SPF и DKIM:

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

NS: делегирование зоны на DNS-серверы

NS-записи определяют, какие серверы являются авторитетными для доменной зоны. Их две группы: на стороне родительской зоны (у регистратора) и внутри самой зоны. Оба набора должны совпадать.

Синтаксис в файле зоны:

example.com.  IN  NS  ns1.cloudflare.com.
example.com.  IN  NS  ns2.cloudflare.com.

Смена NS-серверов у регистратора передаёт управление зоной выбранному DNS-провайдеру. После этого все изменения вносятся в панели этого провайдера, а не регистратора. Процесс делегирования занимает от нескольких минут до 48 часов - время определяется TTL NS-записей родительской зоны.

SOA-запись (Start of Authority) создаётся автоматически и содержит служебную информацию: основной NS, email администратора, серийный номер, интервалы обновления и повторных попыток. Её не редактируют вручную без глубокого понимания последствий.

Пошаговая настройка DNS для веб-сайта

Рассмотрим сквозной сценарий: у вас домен example.com, сервер с IP 192.0.2.1 и задача сделать сайт доступным по адресам example.com и www.example.com. Настройку покажем для панели ISPmanager и для Cloudflare - два наиболее частых окружения у нашей аудитории.

Добавление A-записи для основного домена

В ISPmanager: откройте раздел «Домены» → «DNS-записи», выберите домен. Нажмите «Создать запись». В поле «Тип» выберите A. Имя оставьте пустым или введите символ @ - оба варианта означают корневой домен. В поле «Адрес» введите 192.0.2.1. TTL оставьте 3600 (1 час) или уменьшите до 300, если планируете скорую смену IP. Нажмите «Сохранить».

В Cloudflare: перейдите в раздел DNS выбранного домена, нажмите «Add record». Тип - A, Name - @, IPv4 address - 192.0.2.1, прокси-статус (оранжевое облако) оставьте включённым, если хотите использовать защиту от DDoS и сокрытие реального IP сервера. Нажмите «Save».

После сохранения запись начинает действовать в течение срока, заданного TTL. Существующие кэши резолверов продолжат отдавать старые значения до истечения их TTL.

Настройка CNAME для поддомена www

В ISPmanager: создайте новую запись, тип CNAME. Имя - www. Значение - example.com. (точка в конце в ISPmanager не требуется). Сохраните.

В Cloudflare: Add record → Type CNAME, Name - www, Target - example.com, прокси-статус по желанию. Сохраните.

Теперь при вводе www.example.com браузер получит CNAME, указывающий на example.com, резолвер сделает второй запрос, получит A-запись с IP 192.0.2.1 и откроет сайт. Альтернативный подход - создать для www отдельную A-запись с тем же IP. Это сэкономит один DNS-запрос, но потребует обновления двух записей при смене IP. Выбор между CNAME и дополнительной A-записью - вопрос административного удобства.

Настройка почтовых MX-записей

Для приёма почты на домене example.com через Яндекс.Почту требуется MX-запись и подтверждение владения доменом.

Создание MX-записи для Яндекс.Почты

В панели управления DNS создайте запись типа MX. Имя - @ (корневой домен). Значение - mx.yandex.net. Приоритет - 10. TTL - 3600.

После добавления MX-записи Яндекс потребует подтвердить владение доменом. В интерфейсе Яндекс.Коннекта или Почты для домена вы получите TXT-запись вида yandex-verification=XXXXX или ссылку на HTML-файл. Добавьте TXT-запись с именем @ и полученным значением. Подтверждение занимает от нескольких минут до часа.

Для полноценной настройки добавьте SPF-запись, разрешающую серверам Яндекса отправлять письма от вашего домена:

example.com.  IN  TXT  "v=spf1 include:_spf.yandex.net ~all"

Проверка нескольких MX-записей с разными приоритетами

Резервный почтовый сервер добавляется второй MX-записью с более высоким приоритетом. Например, если основной сервер mail.example.com (приоритет 10) станет недоступен, почта пойдёт на backup-mail.example.com (приоритет 20):

example.com.  IN  MX  10  mail.example.com.
example.com.  IN  MX  20  backup-mail.example.com.

Отправляющий MTA сортирует MX-записи по приоритету и пробует серверы последовательно. Резервный сервер должен быть настроен на приём и хранение почты до восстановления основного.

Делегирование DNS-зоны: передача управления NS-серверами

Делегирование требуется при переходе на облачный DNS-провайдер - Cloudflare, Яндекс.Облако, AWS Route 53. Зона продолжает принадлежать вам, но управляется через интерфейс провайдера, а не регистратора.

Пошаговый процесс на примере перехода на Cloudflare:

1. Зарегистрируйтесь в Cloudflare, добавьте домен. Cloudflare просканирует существующие записи и предложит импортировать их.
2. После импорта Cloudflare выдаст два или более NS-серверов, например ns1.cloudflare.com и ns2.cloudflare.com.
3. Зайдите в панель управления доменом у регистратора (например, R01, REG.RU, NIC.RU). Найдите раздел «DNS-серверы» или «Делегирование».
4. Замените текущие NS-серверы на выданные Cloudflare. Сохраните изменения.
5. Дождитесь распространения. Проверить статус можно командой dig example.com NS +short. Когда она вернёт новые NS, делегирование завершено.

На время перехода сохраните идентичные записи в обеих панелях - у регистратора и у нового провайдера. Это исключит простой, пока кэши резолверов обновляются.

Проверка корректности настройки DNS

После каждого изменения проверяйте зону утилитами командной строки и онлайн-сервисами. Это выявит опечатки и проблемы с кэшированием до того, как они повлияют на пользователей.

Проверка A-записи с помощью dig

Команда для проверки A-записи:

dig example.com A +short

Ожидаемый вывод - IP-адрес сервера: 192.0.2.1. Если ответ пустой, запись отсутствует или не синхронизировалась. Запросите конкретный NS-сервер, чтобы исключить кэш:

dig example.com A @ns1.cloudflare.com +short

Эта команда обращается напрямую к авторитетному серверу, минуя локальный кэш. Если авторитетный сервер возвращает правильный IP, а публичный резолвер нет - ждите истечения TTL старых данных.

Диагностика MX-записей

Проверка почтовых записей:

dig example.com MX +short

Вывод покажет приоритеты и имена серверов:

10 mx.yandex.net.
20 backup-mail.example.com.

Утилита nslookup даёт аналогичную информацию в диалоговом режиме:

nslookup -type=MX example.com

Онлайн-сервисы вроде dnschecker.org и mxtoolbox.com позволяют проверить записи с географически распределённых резолверов и выявить проблемы с распространением.

Типовые проблемы при настройке DNS и их решение

Долгое распространение изменений: как ускорить

Изменения DNS не применяются мгновенно. Скорость зависит от TTL предыдущей записи и времени кэширования на промежуточных резолверах. Стратегия минимизации задержки:

• За 24 часа до планируемых изменений уменьшите TTL критичных записей до 300 секунд (5 минут).
• После применения новых значений верните TTL к 3600 или выше.
• Очистите локальный кэш: ipconfig /flushdns на Windows, sudo systemd-resolve --flush-caches на Linux с systemd-resolved, sudo rndc flush на сервере BIND.

Детальные инструкции по очистке кэша на разных платформах собраны в руководстве по сценариям очистки DNS-кэша, а параметры TTL для балансировки нагрузки разобраны в статье по оптимизации кэширования.

Ошибка «couldn't resolve proxy name» и другие симптомы неверного DNS

Характерный симптом проблем с DNS - ошибка разрешения имени прокси-сервера в 1С: «couldn't resolve proxy name». Система не может преобразовать доменное имя прокси в IP-адрес. Диагностика:

1. Выполните nslookup proxy_name из командной строки сервера. Если имя не разрешается - проблема на уровне DNS.
2. Проверьте доступность прокси напрямую: ping proxy_name или telnet proxy_name port.
3. Временно переключите DNS-серверы на публичные: Google DNS (8.8.8.8 и 8.8.4.4) или Яндекс DNS (77.88.8.8). Если ошибка исчезает, проблема в локальном DNS-сервере или его настройках пересылки.

Другие частые ошибки:

• Неверный синтаксис: забытая точка в конце FQDN в файлах зон BIND. Запись без точки интерпретируется как относительное имя, к которому добавляется $ORIGIN. Результат - удвоение домена (example.com.example.com).
• Конфликт CNAME и других записей: согласно RFC 1912, имя с CNAME не может иметь других записей. Если для www.example.com задан CNAME, нельзя добавить TXT или MX для того же имени.
• Циклический CNAME: запись A → CNAME на B, B → CNAME на A. Резолвер зациклится и вернёт SERVFAIL.

Для комплексной защиты DNS-инфраструктуры после базовой настройки записей внедрите DNSSEC и шифрование запросов. Готовые конфигурации Unbound, Knot Resolver и BIND9 с автоматизацией через OpenDNSSEC даны в руководстве по DoT, DoH и DNSSEC.

Когда зона стабильна, переходите к автоматизации управления записями. Статья по Infrastructure as Code для DNS содержит конфигурации Terraform, Ansible и манифесты ExternalDNS для автоматического создания записей через CI/CD.

Для глубокой диагностики проблем с резолвингом используйте методы из руководства по мониторингу и анализу кэша DNS-серверов - там описаны команды rndc, unbound-control и PowerShell для дампа записей и выявления устаревших данных.