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

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

28 июля 2026 12 мин. чтения
Содержание статьи

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

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

Когда использовать этот гайд

  • Сайт должен открываться по основному домену example.com и адресу www.example.com.
  • Нужно направить почту домена на Яндекс.Почту или Google Workspace с корректной MX-записью.
  • Требуется добавить TXT-запись для подтверждения домена или настроить SPF, DKIM и DMARC.
  • Нужно выполнить делегирование домена: заменить NS-серверы у регистратора и проверить, что зона отвечает с новых DNS-серверов.

Для типовой настройки подготовьте домен, IP-адрес веб-сервера, данные почтового провайдера и доступ к панели регистратора или DNS-провайдера.

Краткое содержание

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

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

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

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

Ошибка в одной записи способна положить сайт или остановить приём писем. Сначала определите, какой сервис должен отвечать за DNS-зону, затем внесите записи в одной панели и проверьте их через авторитетные NS-серверы.

Типы 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.

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.

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

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

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

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

Число перед именем сервера - приоритет. Меньшее значение означает более высокий приоритет. Отправляющий почтовый сервер сначала пытается доставить письмо на хост с приоритетом 10. Одинаковые приоритеты распределяют нагрузку 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-провайдеру. После этого все изменения вносятся в панели этого провайдера, а не регистратора.

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

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

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

ТипИмяЗначениеTTLПримечание
A@192.0.2.1300-3600IP веб-сервера
CNAMEwwwexample.com300-3600Псевдоним основного домена

Настройка DNS в ISPmanager

Откройте раздел «Домены» → «DNS-записи» и выберите нужный домен. Для добавления записи нажмите «Создать запись», выберите «Тип», заполните «Адрес» и нажмите «Сохранить».

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

Выберите тип A, оставьте имя пустым или введите символ @ - оба варианта означают корневой домен. В поле «Адрес» укажите 192.0.2.1. TTL оставьте 3600 или уменьшите до 300, если планируете скорую смену IP.

CNAME для www

Создайте запись типа CNAME с именем www и значением example.com.. В ISPmanager точка в конце значения обычно не требуется: панель добавляет её автоматически. Не создавайте одновременно CNAME и A-запись для www.

MX, TXT и NS

MX и TXT добавляйте в этой же DNS-зоне, если ISPmanager является авторитетным DNS-провайдером. Имя @ используйте для корневого домена. NS-серверы меняются у регистратора только в том случае, если вы передаёте управление зоной другому провайдеру.

Настройка DNS в Cloudflare

Откройте DNS выбранного домена и нажмите «Add record». Укажите тип записи, имя, значение и TTL, затем нажмите «Save».

A-запись для сайта

Выберите Type - A, Name - @, IPv4 address - 192.0.2.1. Прокси-статус (оранжевое облако) оставьте включённым, если хотите использовать защиту от DDoS и сокрытие реального IP сервера. Для сервисов, которым нужен прямой DNS-ответ, используйте режим DNS only.

CNAME для www

Выберите Type - CNAME, Name - www, Target - example.com. Прокси-статус можно оставить включённым для веб-трафика.

MX и TXT в Cloudflare

Для MX-записей используйте DNS only: прокси-режим Cloudflare не применяется к почтовым серверам. Добавьте MX с именем @, адресом почтового сервера и приоритетом, полученным от провайдера. TXT-записи для подтверждения домена, SPF, DKIM и DMARC добавляются через Add record → TXT.

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

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

ТипИмяЗначениеПриоритетПримечание
MX@mx.yandex.net.10Основной сервер Яндекс.Почты

В панели управления 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-записью с более высоким числовым приоритетом:

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. Зона продолжает принадлежать вам, но управляется через интерфейс провайдера, а не регистратора.

  1. Добавьте домен в Cloudflare и импортируйте существующие записи. До смены NS проверьте, что импортированы A, CNAME, MX и TXT.
  2. Запишите выданные Cloudflare NS-серверы, например ns1.cloudflare.com и ns2.cloudflare.com.
  3. В панели регистратора откройте раздел «DNS-серверы» или «Делегирование».
  4. Замените текущие NS-серверы на выданные Cloudflare и сохраните изменения.
  5. Проверьте делегирование командой dig example.com NS +short. В ответе должны быть новые NS-серверы.
  6. Проверьте, что авторитетный сервер отвечает нужными данными: dig example.com A @ns1.cloudflare.com +short.

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

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

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

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

dig example.com A +short

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

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

Если авторитетный сервер возвращает правильный IP, а обычный запрос показывает старое значение, дождитесь истечения TTL.

Проверка CNAME

dig www.example.com CNAME +short

Ожидаемый результат - example.com.. Если ответа нет, проверьте имя записи. Если одновременно настроены CNAME и A, удалите конфликтующую запись.

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

dig example.com MX +short
nslookup -type=MX example.com

Вывод должен содержать ожидаемые приоритеты и имена серверов, например 10 mx.yandex.net.. IP-адрес вместо имени, неверный приоритет или отсутствие MX указывают на ошибку почтовой настройки.

Проверка TXT и делегирования

dig example.com TXT +short
dig example.com NS +short

В ответе TXT должна присутствовать нужная строка верификации или SPF, а в ответе NS - серверы, указанные у регистратора. Если NS старые, делегирование ещё не завершено или изменения внесены не у того регистратора.

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

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

Скорость обновления зависит от TTL предыдущей записи и времени кэширования на промежуточных резолверах. За 24 часа до планируемых изменений уменьшите TTL критичных записей до 300 секунд, после проверки верните его к 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». Диагностика:

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

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

  • Забытый apex: A-запись создана для www, но отсутствует запись для корневого домена @.
  • Лишняя точка или её отсутствие: в файле BIND имя без точки интерпретируется как относительное и может превратиться в example.com.example.com. В панели точка обычно не требуется.
  • Конфликт CNAME и других записей: имя с CNAME не может иметь других записей.
  • Неверный приоритет MX: меньший номер имеет более высокий приоритет.
  • Прокси Cloudflare для почты: MX-адрес и почтовый хост должны работать в режиме DNS only, а не через оранжевое облако.
  • Циклический 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-записи после изменения?

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

Можно ли использовать CNAME для корневого домена?

Нет, согласно RFC 1912, CNAME для корневого домена (apex) недопустим, так как у него уже есть обязательные NS и SOA-записи. Используйте A-запись или поддерживаемые провайдером ALIAS, ANAME или CNAME-флаттенинг.

Что делать, если сайт не открывается после смены DNS?

Выполните dig example.com A +short, затем запросите авторитетный NS напрямую. Старый IP означает кэширование, пустой ответ - отсутствие записи, ошибку имени или проблему делегирования. Также проверьте, что A-запись создана для @, а CNAME для www не конфликтует с другой записью.

Как проверить, что MX-запись работает корректно?

Выполните dig example.com MX +short. Вывод должен содержать приоритеты и имена почтовых серверов, например 10 mx.yandex.net.. Проверьте, что почтовый хост не находится под прокси Cloudflare и что для домена настроены необходимые SPF/DKIM/DMARC-записи.

Поделиться:
Сохранить гайд? В закладки браузера