DNS-записи CNAME: как работают и для чего нужны

Название CNAME расшифровывается как Canonical Name, то есть каноническое имя. Запись сообщает DNS-системе, что запрошенное имя является альтернативным именем другого хоста. Например, поддомен shop можно связать с именем, которое обслуживает внешняя платформа. При обращении пользователя DNS-сервер сначала находит CNAME, затем запрашивает записи целевого имени и возвращает итоговый адрес.

В отличие от записи A, CNAME не содержит IPv4-адрес. В отличие от AAAA, она не содержит IPv6-адрес. Она также не перенаправляет посетителя в браузере и не изменяет содержимое адресной строки. CNAME работает только на уровне DNS: устройство получает сведения о целевом имени ещё до установки соединения с сервером.

Цепочка разрешения может состоять из нескольких переходов, но делать её длинной не рекомендуется. Каждый дополнительный запрос способен немного увеличить время первого обращения и усложняет диагностику. Практичнее направлять псевдоним сразу на конечное имя, которое предоставляет владелец инфраструктуры или сервиса.

Наиболее распространённый сценарий — подключение отдельного поддомена к внешнему сервису. Так можно назначить независимые имена для витрины магазина, системы поддержки, страницы мероприятий, файлового хранилища или платформы рассылок. Сервис поддерживает собственную инфраструктуру и при необходимости меняет IP-адреса у себя, а владельцу домена не требуется вручную обновлять запись A.

• Подключение поддомена к конструктору сайтов или облачной платформе.
• Настройка имени для корпоративного приложения или панели клиентов.
• Подтверждение владения доменом при интеграции со сторонним сервисом.
• Создание удобного псевдонима для технического хоста.
• Подключение CDN, системы аналитики, почтового или маркетингового инструмента.

Если необходимо направить имя непосредственно на фиксированный IP-адрес собственного сервера, обычно выбирают A или AAAA. Если требуется отправлять почту на почтовый сервер, используют MX. Для текстовых политик, подтверждений и параметров применяют TXT. Выбор типа записи зависит от задачи, а не от того, какой вариант кажется универсальнее.

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

Целевым значением должен быть доменный хост, а не IP-адрес. Если внешний сервис выдал имя назначения, его нужно перенести без подмены на адрес сервера. Конечная точка нередко содержит завершающую точку в профессиональных DNS-редакторах; в пользовательских панелях она чаще всего не требуется. Следует ориентироваться на правила конкретной панели управления.

Главное ограничение: для одного и того же имени CNAME не может существовать вместе с A, AAAA, MX, TXT и другими обычными DNS-записями. Это связано с тем, что CNAME полностью заменяет набор данных данного имени ссылкой на другое имя. Если в зоне уже есть конфликтующая запись, её необходимо удалить, перенести на другой поддомен или выбрать иной способ настройки.

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

TTL определяет, как долго DNS-резолверы могут хранить ответ в кэше. Невысокое значение удобно перед изменениями: после корректировки записи новые данные начнут запрашиваться быстрее. Более высокое значение уменьшает количество повторных запросов, но при ошибке или переносе сервиса старые сведения могут дольше сохраняться у пользователей.

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

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

Самая частая ошибка — попытка указать в CNAME числовой IP-адрес. Такая запись не выполнит нужную функцию, поскольку CNAME должен ссылаться на имя. Другая распространённая проблема — одновременное создание CNAME и TXT-записи для одинакового поддомена. Например, сервис может запрашивать подтверждение TXT на одном имени и CNAME для подключения на другом; эти имена нельзя путать.

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

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