DNS-записи простыми словами: сайт, почта и поддомены

DNS-записи помогают найти службы по имени домена. Для сайта, почты и отдельных поддоменов используются разные записи, поэтому просьба «поменять DNS» слишком неточна. До изменения нужно выяснить, какая служба переносится, где находится рабочая зона и какие записи относятся к остальным подключениям. Иначе переезд сайта может случайно затронуть корпоративную почту или подтверждение внешнего сервиса.

Ниже — объяснение для владельца проекта и схема постановки задачи специалисту. Это не готовый набор значений для вашего домена. Адреса серверов, имена и параметры нужно получить из подтверждённой инструкции конкретной службы. Не копируйте чужую DNS-зону как шаблон: одинаковый тип записи не означает одинаковое назначение её содержимого.

Сначала прочитайте одну строку

В панели обычно есть имя, тип, значение и TTL. Имя показывает, к какой части домена относится запись; тип определяет смысл значения. TTL связан со сроком использования ответа в DNS-кеше. Интерфейсы провайдеров могут по-разному показывать полное имя, относительную часть и корень зоны. Поэтому одинаковая короткая подпись в двух кабинетах ещё не подтверждает одинаковый итоговый адрес.

Попросите специалиста показать полное имя, которое получится после сохранения. Это особенно полезно для поддоменов и служебных записей, полученных из инструкции внешней системы. Ошибка в поле имени и ошибка в значении являются разными случаями. Если сервис просит добавить определённую строку, сохраняйте её исходную инструкцию рядом с результатом, а не только снимок заполненной формы.

Чтение записи начинается с типа, а не с привычного содержимого. В одном случае значением будет IP-адрес, в другом — имя сервера, в третьем — текст. Нельзя заменить имя почтового узла адресом сайта только потому, что оба поля названы «значение». Назначение записи определяет, как интерпретировать её данные и что проверять после изменения.

Какие типы встретятся чаще всего

В таблице собраны распространённые роли записей. Базовые форматы описаны в RFC 1035, а запись для IPv6 — в RFC 3596. Это не полный справочник DNS. Для начала владельцу важно различать назначение строк и понимать, почему одной записью нельзя заменить всю конфигурацию домена.

Для MX числовое предпочтение не является номером порта или оценкой качества сервера. Если их несколько, интерпретация задаётся форматом записи: меньшее значение имеет более высокий приоритет. При этом не выбирайте произвольные числа и имена вместо инструкции почтовой системы. Задача владельца — сохранить смысл настройки и понять, какие строки нужно проверять вместе.

Один домен не означает один сервер для всего

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

В учебной ситуации компания переносит только веб-приложение. Для неё нужно установить конкретные имена сайта и связанные адресные записи. Почтовые MX и текстовые параметры других подключений рассматриваются отдельно. Это не универсальный рецепт «менять только A»: у выбранной архитектуры могут быть другие требования. Полезный результат разбора — точный список изменяемых строк и объяснение, какие службы они затронут.

Отдельно проверьте записи для IPv4 и IPv6, если они присутствуют. Обновление одного семейства адресов не является подтверждением правильности второго. Не удаляйте неизвестную строку ради совпадения с короткой инструкцией. Установите, используется ли она, кто отвечает за соответствующую службу и какое состояние должно быть после переезда.

Где находится рабочая зона

Домен может быть оплачен у одного регистратора, DNS обслуживаться другой системой, а приложение — третьим поставщиком. Найти знакомую форму редактирования в старом кабинете недостаточно. Нужно установить, какая зона реально участвует в разрешении нужного имени. Для этого специалист проверяет делегирование и ответы соответствующих серверов, а не только доступность панели.

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

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

CNAME не является перенаправлением страницы

Псевдоним в DNS относится к имени, а переход посетителя с одного адреса страницы на другой является задачей веб-сервера или приложения. Нельзя по наличию CNAME заключить, что браузер должен изменить URL или что поисковая система увидит нужный HTTP-редирект. В рабочей задаче отдельно опишите желаемое поведение адреса сайта после открытия.

Если служба просит CNAME, следуйте требованиям к конкретному имени и окружению. У провайдеров есть особенности и дополнительные механизмы, поэтому не переносите настройку корня домена по образцу поддомена без проверки. Для владельца достаточно сформулировать результат и попросить специалиста подтвердить допустимость конфигурации. Запись, которую удалось сохранить в форме, ещё не доказывает работу нужной службы.

Не удаляйте текстовые записи по внешнему виду

TXT может использоваться для разных задач: параметров почты и подтверждений подключений. Несколько строк не обязательно являются дублями, а непонятный текст не означает ненужную настройку. Для удаления найдите владельца и назначение записи. Сохраните исходное состояние и основание решения, чтобы команда могла объяснить изменение после следующего обновления.

В публичную зону помещают значения, предназначенные для такой публикации по инструкции сервиса. Это не место для произвольного хранения паролей и ключей приложения. При этом строку подтверждения не нужно автоматически считать секретом только из-за случайного набора символов: её назначение устанавливается инструкцией. Разделяйте публикуемое значение и закрытые реквизиты кабинета, из которого оно получено.

Как оформить изменение без догадок

В задаче укажите домен, службу, рабочую зону, исходные строки и ожидаемую замену. Добавьте источник новых значений и ответственного за проверку. Формулировка «направить на новый сервер» недостаточна, если непонятно, какие имена относятся к сайту, где почта и что нужно сохранить. Перед сохранением полезно ещё раз проверить состав изменения по строкам.

Подготовьте копию исходного состояния и условия возврата. Возврат также требует проверки результата и не означает мгновенного исчезновения уже сохранённых ответов у всех участников. Если после изменения часть посетителей видит старый сайт, используйте отдельный порядок разбора DNS и кеша. Здесь важно не обещать универсальное время обновления и не выдавать один успешный просмотр за полную проверку.

Проверьте службу, а не только новую строку

После изменения специалист сверяет DNS-ответы и фактическую работу задуманной службы. Для сайта это нужная страница и рабочий сценарий, для почты — отдельно предусмотренная проверка на контролируемых адресах. Правильный ответ DNS не подтверждает готовность приложения или корректность всей почтовой системы. Если результат расходится с планом, разбирайте следующий этап, не меняя остальные записи вслепую.

В итоге у владельца должен остаться небольшой реестр: какие службы работают на домене, где их зона и какие записи за что отвечают. Его обновляют при следующем подключении, а не восстанавливают по памяти во время аварии. Такая схема не заменяет специалиста по DNS, но позволяет поставить точную задачу и заметить, когда вместо переноса одной службы предлагают необъяснимую замену всей конфигурации.