Редактирование DNS-записей

Каждый тип записи решает свою задачу. Для открытия сайта обычно используется запись A: она связывает домен или поддомен с IPv4-адресом сервера. Если инфраструктура поддерживает IPv6, добавляют запись AAAA. При переносе сайта на новый сервер чаще всего меняют именно эти значения.

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

Для электронной почты используются MX-записи. Они определяют серверы, принимающие письма для домена, и содержат приоритет: чем меньше число, тем выше приоритет сервера. Записи TXT хранят текстовые параметры, включая подтверждение владения доменом, SPF, DKIM и DMARC. Они особенно важны для защиты почты от подделки отправителя и повышения доставляемости писем.

Записи NS указывают авторитетные серверы имён. Их изменение фактически передаёт управление DNS-зоной другому провайдеру. В отличие от правки A или TXT, замена NS требует особой осторожности: новая зона должна быть подготовлена заранее и содержать все необходимые записи.

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

Проверьте, какая запись отвечает за нужный ресурс. Корневой домен обычно обозначается символом @ или оставляется пустым, а имя поддомена вводится отдельно, например www, mail или api. Не путайте полное доменное имя с относительным именем в панели: некоторые интерфейсы автоматически дописывают основной домен.

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

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

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

При добавлении записи заполните имя, тип, значение и при необходимости приоритет. Для MX приоритет обязателен, а для CNAME важно указать целевое имя, а не IP-адрес. Для TXT вставляйте значение целиком. После сохранения убедитесь, что панель не изменила запись автоматически и не добавила лишний доменный суффикс.

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

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

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

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

Для почтовых записей период обновления особенно важен. Неполный набор MX, SPF, DKIM или DMARC может временно ухудшить доставку сообщений. Планируйте смену почтового провайдера заранее: сначала внесите новые записи, подтвердите работу почтовых ящиков и только после стабилизации удаляйте устаревшие параметры.

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

Одна из частых ошибок — изменение DNS в панели, которая не обслуживает домен. Если NS-серверы указывают на другого провайдера, записи нужно редактировать именно там. Также проблемы возникают при одновременном использовании нескольких конфликтующих A, AAAA или CNAME-записей для одного имени.

Нельзя размещать CNAME вместе с другими записями на одном и том же имени, если это не предусмотрено особенностями DNS-провайдера. Не следует заменять MX-записи одной записью без подтверждения от почтового сервиса: часто для отказоустойчивости требуется несколько серверов с разными приоритетами.

При работе с TXT важно не удалять действующие SPF, DKIM и верификационные записи ради добавления новой. Для SPF обычно формируют единую корректную политику, а не создают несколько независимых SPF-записей. При сомнениях лучше сопоставить новые требования со всеми текущими параметрами почтовой зоны.

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