DNS-записи домена: как устроены и для чего нужны
DNS-записи домена связывают понятное человеку имя сайта с техническими сервисами: сервером, почтой, поддоменами и системами подтверждения прав. Именно они определяют, куда откроется сайт после ввода адреса, на какой сервер будут приходить письма и какие службы имеют право отправлять сообщения от имени домена.
Ошибки в зоне DNS могут привести к недоступности сайта, сбоям почты, проблемам с подтверждением домена и ухудшению доставляемости писем. Поэтому при изменении записей важно понимать назначение каждого типа, корректно указывать значения и учитывать время распространения обновлений.
Что такое DNS-зона и как работают записи
DNS можно представить как распределённую адресную книгу интернета. Когда пользователь вводит доменное имя, его устройство запрашивает у DNS-серверов сведения о том, с каким ресурсом связано это имя. Ответ формируется на основе записей, размещённых в DNS-зоне домена.
Зоной управляют у регистратора домена, хостинг-провайдера или в отдельном DNS-сервисе. В настройках домена указываются NS-серверы, отвечающие за хранение актуальной зоны. Если сменить NS-серверы, управление всеми записями перейдёт к другому провайдеру, поэтому перед переключением нужно перенести существующую конфигурацию.
Каждая запись включает имя, тип, значение и TTL. Имя задаёт домен или поддомен, тип определяет назначение, значение содержит адрес либо иной параметр. TTL показывает, как долго промежуточные DNS-серверы могут хранить ответ в кеше. Малый TTL ускоряет внедрение изменений, но увеличивает число запросов; большой снижает нагрузку, однако старые данные могут дольше оставаться доступными.
Для корневого домена в панели управления часто используют символ @ или пустое поле имени. Например, запись для @ действует на основной домен, а запись с именем www — только на поддомен www. Полное имя обычно заканчивается точкой, но многие панели добавляют доменную часть автоматически.
Основные типы DNS-записей
Для работы сайта и электронной почты применяются несколько базовых типов записей. Их нельзя считать взаимозаменяемыми: каждая решает определённую задачу.
- A — связывает домен или поддомен с IPv4-адресом сервера. Обычно используется для основного сайта, панели управления и отдельных сервисов.
- AAAA — аналог A-записи для IPv6-адреса. Её добавляют, если сервер и сеть поддерживают IPv6.
- CNAME — создаёт псевдоним, который указывает на другое доменное имя. Часто применяется для www, технических поддоменов и подключения внешних сервисов.
- MX — определяет серверы, принимающие почту для домена. У MX-записей есть приоритет: меньшее число означает более предпочтительный сервер.
- TXT — хранит текстовые параметры. Через него подтверждают владение доменом, настраивают SPF, DKIM и DMARC для почты.
- NS — указывает авторитетные DNS-серверы зоны. Некорректная смена NS может сделать недоступными сайт и почту.
- SRV — задаёт параметры подключения к определённой службе: порт, приоритет, вес и имя сервера. Используется некоторыми мессенджерами, телефонией и корпоративными системами.
- CAA — ограничивает центры сертификации, которым разрешено выпускать сертификаты для домена.
Запись CNAME обычно не размещают в корне домена, поскольку там уже необходимы другие записи. В отдельных DNS-сервисах существуют специальные варианты для корневого имени, но их поведение зависит от платформы. При стандартной настройке основной домен направляют A- или AAAA-записью, а www делают CNAME на основной домен либо отдельной записью.
Настройка сайта, поддоменов и переадресации
Чтобы открыть сайт по основному домену, в зоне создают A-запись с именем @ и IPv4-адресом веб-сервера. Если используется IPv6, дополнительно создают AAAA-запись. Для адреса www можно установить CNAME на основной домен. После этого сервер должен быть настроен на приём запросов для обоих имён, а сертификат безопасности должен включать нужные варианты домена.
Поддомены настраиваются отдельными записями. Например, для panel, api, shop или blog указывают собственный адрес через A или AAAA, либо направляют их на целевой сервис через CNAME. Если один IP обслуживает несколько поддоменов, веб-сервер различает их по имени в запросе и отдаёт соответствующий сайт.
DNS не выполняет полноценную переадресацию страниц. Он лишь сообщает, куда обращаться. Если нужно перенаправить посетителя с одного адреса на другой, например с www на основной вариант домена, это настраивают на веб-сервере, в панели хостинга или через специализированный сервис. Правильная переадресация возвращает код ответа 301 или 302 и сохраняет путь страницы, если это предусмотрено правилами.
Перед заменой адреса сервера полезно уменьшить TTL до умеренного значения, дождаться обновления кеша и только затем изменить A-запись. После стабилизации работы TTL можно увеличить. Такой порядок уменьшает вероятность того, что часть посетителей будет попадать на старый сервер.
DNS-записи для корпоративной почты
Почтовая конфигурация начинается с MX-записей. В них указываются доменные имена почтовых серверов, предоставленные почтовым сервисом, а не IP-адреса. Если сервис использует несколько MX-записей, необходимо добавить их все и сохранить заданные приоритеты. Старые MX-записи, относящиеся к прежнему провайдеру, обычно удаляют, иначе часть сообщений может направляться неверно.
Для защиты исходящей почты настраивают SPF, DKIM и DMARC. SPF публикуется в TXT-записи и перечисляет серверы, которым разрешено отправлять письма от имени домена. Для одного домена должна существовать одна SPF-запись: при добавлении нового сервиса её не дублируют, а объединяют параметры в существующем значении.
DKIM подтверждает подлинность письма цифровой подписью. Почтовый сервис выдаёт имя селектора и длинное значение TXT-записи. Важно вставить ключ полностью, без лишних кавычек, пробелов и переносов, если панель не добавляет их автоматически. DMARC задаёт политику обработки сообщений, не прошедших проверки SPF и DKIM, а также адрес для отчётов. Начинать рекомендуется с режима мониторинга, анализировать отчёты и только потом усиливать политику.
При переходе на нового почтового провайдера записи лучше менять по его инструкции и не удалять старую конфигурацию до завершения миграции ящиков. Также необходимо проверить, что почтовые серверы могут разрешать имена, указанные в MX, и что SPF учитывает все разрешённые источники отправки: сайт, CRM, рассылки и рабочую почту.
Проверка DNS и типичные ошибки
После сохранения изменений нужно проверить не только наличие записи в панели, но и фактический ответ авторитетных DNS-серверов. Для этого используют системные утилиты диагностики или инструменты проверки DNS. Сравнивают имя, тип, значение, приоритет и TTL. Если данные различаются в разных сетях, вероятнее всего, обновление ещё распространяется или сохраняется старый кеш.
Распространённая ошибка — указать IP-адрес в CNAME или MX-записи. CNAME должен ссылаться на доменное имя, а MX всегда ведёт на имя почтового сервера. Другая проблема — случайное дублирование имени: если панель автоматически добавляет домен, ввод полного имени может превратиться в некорректный адрес. Нужно учитывать правила конкретного интерфейса.
Нельзя одновременно создавать CNAME и другие записи для одного и того же имени. Также следует внимательно переносить TXT-значения: лишний символ, неверное экранирование или неполный ключ DKIM нарушают проверку. При настройке CAA нужно убедиться, что выбранный центр сертификации разрешён, иначе выпуск или автоматическое продление сертификата может завершиться ошибкой.
Время обновления DNS зависит от TTL, настроек кеширования у провайдеров и приложений. Изменение может стать заметным быстро, но рассчитывать стоит на период до окончания прежнего TTL. Если сайт не открывается после этого срока, проверяют NS-серверы, корректность зоны, IP-адрес сервера, настройки веб-сервера и наличие действующего сертификата.