Настройка DNS сервера для домена определяет, куда направляется трафик сайта, как работают поддомены, корпоративная почта и подключенные внешние сервисы.
Выполняем настройки DNS для сайтов, почты, VPS/VDS, CDN, CRM и других сервисов: проверяем существующую DNS-зону, настраиваем необходимые записи, управляем TTL и контролируем результат после изменений.
DNS - это не только A-запись домена. Ошибка в одной записи может сделать недоступным сайт, отдельный поддомен, почту или внешний сервис, поэтому сначала фиксируем текущее состояние, а затем изменяем только необходимые элементы.
Какие настройки DNS выполняем
Состав DNS-зоны зависит от того, какие сервисы используются доменом.
A и AAAA
Настраиваем направление домена или поддомена на IPv4 или IPv6 адрес сервера.
Проверяем, что запись ведет именно на нужную инфраструктуру и не конфликтует с другими настройками домена.
CNAME
Используем CNAME, когда поддомен должен указывать на другое доменное имя или внешний сервис.
Это может потребоваться для CDN, SaaS-платформ, внешних приложений, аналитики, CRM и других сервисов.
NS
NS-записи определяют, какие DNS серверы обслуживают доменную зону.
При смене DNS-провайдера сначала переносим необходимые записи, проверяем новую конфигурацию и только затем меняем делегирование домена.
MX
MX определяет, на какие почтовые серверы должна доставляться почта домена.
При настройке или изменении MX учитываем существующую почтовую инфраструктуру, чтобы изменение сайта или хостинга не нарушило прием писем.
TXT
TXT-записи используются для различных служебных настроек и подтверждения владения доменом.
Через них могут подключаться:
- SPF.
- DKIM.
- DMARC.
- Подтверждение домена в почтовых сервисах.
- Подтверждение домена в аналитике.
- Подключение внешних платформ.
- Другие сервисные верификации.
Настройка DNS для сайта и поддоменов
Для сайта определяем, какие адреса должны обслуживать основной домен и его поддомены.
Проверяем:
- Основной домен.
- www.
- Технические поддомены.
- API.
- CRM.
- CDN.
- Статические ресурсы.
- Другие сервисные адреса.
Например, сайт может работать на одном сервере, API - на другом, а статический контент - через отдельный сервис.
DNS должен направлять каждый адрес в правильную точку инфраструктуры.
DNS не выполняет HTTP-редиректы
DNS определяет, куда направляется доменное имя, но не управляет HTTP-кодами и переходами между URL.
Например, перенаправление с одного домена на другой, с HTTP на HTTPS или с www на основной адрес выполняется на уровне веб-сервера, reverse proxy или приложения.
Поэтому при диагностике сначала разделяем: проблема находится в DNS или уже после DNS-разрешения на стороне сервера.
Настройка DNS для корпоративной почты
DNS-зона домена часто одновременно обслуживает сайт и корпоративную почту.
Из-за этого изменение записей без предварительной проверки может оставить сайт работающим, но нарушить получение или отправку писем.
MX
Проверяем, какие почтовые серверы принимают сообщения для домена и правильно ли задан их приоритет.
SPF
Настраиваем SPF с учетом сервисов, которые имеют право отправлять почту от имени домена.
DKIM
Добавляем необходимые DNS-записи, которые используются почтовым сервисом для проверки DKIM-подписи.
DMARC
Настраиваем DMARC-запись в соответствии с используемой почтовой инфраструктурой.
При работе с почтовыми записями не удаляем существующие настройки, пока не понятно, для какого сервиса они используются.
DNS для внешних сервисов
DNS используется не только сайтом и почтой.
TXT и CNAME могут требоваться для подтверждения домена и подключения:
- CRM.
- Сервисов аналитики.
- Почтовых платформ.
- CDN.
- Хранилищ.
- API.
- Форм.
- Систем трекинга.
- Других внешних сервисов.
Перед удалением неизвестной записи определяем, используется ли она действующей системой.
С чего начинается настройка DNS сервера
До внесения изменений собираем текущую конфигурацию домена.
Фиксируем:
- Текущие NS.
- A и AAAA.
- CNAME.
- MX.
- TXT.
- SPF.
- DKIM.
- DMARC.
- TTL.
- Используемые поддомены.
- Связанные внешние сервисы.
Такая инвентаризация нужна, чтобы изменение одной задачи не затронуло другую часть инфраструктуры.
Проверяем, где фактически управляется DNS
Домен может быть зарегистрирован у одной компании, размещен на хостинге другой, а DNS-зона обслуживаться отдельным DNS-провайдером.
Поэтому доступ к панели регистратора не всегда означает, что DNS-записи изменяются именно там.
Перед настройкой определяем:
- Какие NS делегированы для домена.
- Где находится рабочая DNS-зона.
- Какая конфигурация сейчас используется.
- К каким сервисам относятся существующие записи.
TTL и распространение изменений DNS
Изменение DNS-записи не означает, что все пользователи сразу получат новое значение.
Результаты DNS-запросов кэшируются, а срок хранения зависит в том числе от TTL.
Поэтому после изменения часть пользователей некоторое время может получать старое значение, а часть - уже новое.
При плановых переключениях TTL можно снизить заранее, дождаться обновления старых кэшей, выполнить изменение и после стабилизации вернуть рабочее значение TTL.
Настройка DNS при смене хостинга
При переносе сайта DNS используется для финального переключения трафика на новую площадку.
До изменения записей проверяем:
- Готов ли новый сервер.
- Работает ли сайт на новом окружении.
- Какие записи действительно требуется изменить.
- Не затронут ли изменения почту.
- Какой TTL установлен сейчас.
После этого меняем необходимые A, AAAA или CNAME и контролируем DNS-разрешение.
Полный перенос файлов, базы данных, серверного окружения, cron, очередей и интеграций относится к отдельной услуге смены хостинга и переноса сайта.
Смена DNS-провайдера
При переносе DNS на другого провайдера недостаточно просто изменить NS.
Сначала переносим действующую конфигурацию зоны:
- Сайт.
- Поддомены.
- Почту.
- Верификации.
- Внешние сервисы.
После проверки новой зоны выполняем смену NS и контролируем работу сайта, почты и связанных сервисов.
Настройка поддомена для сервиса
Частая задача - подключить отдельный адрес для нового сервиса.
Например:
api.example.ru
crm.example.ru
mail.example.ru
cdn.example.ru
static.example.ruВ зависимости от сервиса создаем A, AAAA или CNAME и затем проверяем, что имя разрешается в требуемый адрес.
Если сервис работает по HTTPS, отдельно проверяем, что его сервер корректно обслуживает подключенный домен.
Диагностика проблем DNS
Настройка DNS может понадобиться не только при подключении нового сервиса, но и когда существующая конфигурация работает нестабильно.
Сайт открывается не у всех
Проверяем TTL, кэши, NS и значения записей у разных DNS-серверов.
Домен ведет на старый сервер
Проверяем, какая запись используется, где находится рабочая DNS-зона и не сохраняется ли старое значение в DNS-кэше.
Один поддомен не работает
Проверяем A, AAAA, CNAME, имя поддомена и целевой адрес.
После изменения сайта перестала работать почта
Сверяем MX, SPF, DKIM, DMARC и остальные записи, существовавшие до изменения.
После смены NS часть сервисов пропала
Сравниваем старую и новую DNS-зону и проверяем, какие записи не были перенесены.
Как вносим изменения в DNS
- Определяем текущий DNS-провайдер и рабочие NS.
- Сохраняем существующие записи.
- Определяем, какие записи связаны с сайтом, почтой и сервисами.
- Формируем требуемое конечное состояние.
- При необходимости заранее изменяем TTL.
- Вносим только необходимые изменения.
- Проверяем DNS-разрешение.
- Проверяем сайт, почту и связанные сервисы.
- После стабилизации фиксируем итоговую конфигурацию.
Что проверяем после настройки
Сам факт сохранения записи в панели управления еще не означает, что задача выполнена.
После изменения проверяем:
- Основной домен.
- Нужные поддомены.
- A и AAAA.
- CNAME.
- NS.
- MX.
- TXT.
- SPF.
- DKIM.
- DMARC.
- Необходимые верификации.
- Открытие сайта.
- Работу почты.
- Подключенные внешние сервисы.
Критерии приемки настройки DNS
Работу считаем завершенной, когда можно подтвердить не только наличие записей, но и корректную работу связанной инфраструктуры.
- Домен разрешается в нужный адрес.
- Нужные поддомены работают.
- Нет случайно оставленных конфликтующих значений.
- Почтовые MX сохранены и работают.
- SPF, DKIM и DMARC находятся в требуемом состоянии.
- Необходимые TXT и CNAME верификации сохранены.
- Сайт доступен после изменения.
- Связанные сервисы не потеряли доменную конфигурацию.
- Понятно, какие записи относятся к каким системам.
Что относится к DNS, а что нет
DNS отвечает за сопоставление доменных имен с нужными сервисами, но не заменяет настройку самого сервера.
Если требуется установить и настроить Linux, Nginx или Apache, PHP или Node.js, базу данных, cache и другое серверное окружение, используется настройка VPS/VDS сервера и хостинга.
Если требуется перенести работающий проект между хостингами, включая файлы, базу данных и серверное окружение, используется смена хостинга и перенос сайта.
DNS также не выполняет HTTP-редиректы и сам по себе не настраивает приложение, веб-сервер или почтовый сервер.
Что нужно для начала
Обычно достаточно:
- Домена, который требуется настроить.
- Доступа к регистратору или DNS-провайдеру.
- Информации о том, где размещен сайт.
- Информации о том, где работает почта.
- Данных от подключаемого сервиса, если требуется новая запись.
- Описания того, что должно измениться.
Если текущая схема неизвестна, сначала определяем, какие DNS серверы обслуживают домен, и фиксируем существующую конфигурацию.
Результат настройки DNS - не просто набор записей в панели, а предсказуемая конфигурация домена, в которой сайт, поддомены, почта и внешние сервисы направляются туда, куда должны, а изменения можно выполнять без случайного нарушения других систем.
Часто задаваемые вопросы (FAQ)
Нужно ли переносить домен к другому регистратору, чтобы изменить DNS?
Нет. Регистратор домена и сервис, который обслуживает DNS-зону, могут быть разными компаниями. Если текущая схема подходит, домен можно оставить у существующего регистратора и изменить только необходимые DNS-настройки.
Можно оставить сайт у одного провайдера, а корпоративную почту использовать у другого?
Да. DNS позволяет отдельно направлять сайт, почту и другие сервисы. Главное - сохранить корректные записи для каждого из них и при изменении сайта случайно не удалить настройки, от которых зависит почта.
У нас несколько доменов. Можно направить их на один и тот же сайт?
На уровне DNS несколько доменных имён можно направить на одну инфраструктуру. Но то, что должен увидеть пользователь после открытия каждого домена, уже зависит от настройки web-сервера или приложения. Например, автоматический переход с одного домена на другой выполняется не средствами DNS.
Можно подключить новый поддомен, не трогая основной сайт?
Да. Отдельный поддомен может вести на другой сервер или внешний сервис, при этом основной домен продолжит работать по прежней схеме. Перед изменением всё равно проверяется существующая зона, чтобы новая запись не конфликтовала с уже используемыми адресами.
Нужно ли передавать вам пароль от аккаунта, где зарегистрирован домен?
Для внесения изменений нужен доступ к тому сервису, где фактически управляется DNS-зона. Это не всегда панель регистратора домена. Сначала можно определить, где находятся рабочие DNS-настройки, и уже после этого понять, какой именно доступ потребуется.
Можно сначала подготовить DNS для нового сервиса, а включить его позже?
Да, если схема подключения это позволяет. Изменения можно подготовить заранее и выполнить финальное переключение в согласованный момент. Для изменений, связанных с переходом на другой адрес, дополнительно имеет смысл заранее учитывать TTL, чтобы переключение прошло более предсказуемо.
Мы подключаем новый сервис, и он прислал нам какую-то DNS-запись. Этого достаточно, чтобы начать?
Обычно полезно прислать саму инструкцию или значения, которые выдал сервис, а также указать домен или поддомен, который нужно подключить. Перед добавлением записи проверяется существующая зона и определяется, не конфликтует ли новое значение с уже используемой конфигурацией.
Если сайт ещё не готов, можно заранее настроить для него домен?
Можно подготовить DNS-записи заранее, но конечная проверка возможна только тогда, когда целевой сервер или сервис уже готов принимать запросы для этого домена. Поэтому момент изменения DNS лучше согласовать с готовностью самой инфраструктуры.
Можно ли потом передать управление DNS другому специалисту?
Да. DNS-зона не должна быть привязана к конкретному исполнителю. После настройки важно, чтобы было понятно, где она обслуживается и какие записи относятся к сайту, почте, поддоменам и внешним сервисам. Это упрощает дальнейшее сопровождение и будущие изменения.
Я вообще не разбираюсь в DNS и не знаю, какие записи у нас сейчас используются. Это проблема?
Нет. Для начала достаточно сообщить домен и предоставить доступ к сервисам, связанным с его управлением, если он понадобится. Текущую схему можно сначала определить: проверить рабочие DNS-серверы, существующие записи и связанные сервисы, а уже затем решать, что именно требуется менять.
