Одно имя как ссылка на другое
Запись CNAME (canonical name) говорит: это имя является лишь псевдонимом, настоящее имя вот такое, ищите адрес там. Допустим, shop.example.com указывает CNAME на магазин на стороне внешней платформы. Когда резолвер получает такой ответ, он продолжает поиск уже по каноническому имени и в итоге возвращает клиенту адрес. Пользователь видит в адресной строке своё имя, а трафик уходит туда, куда ведёт цепочка.
Это удобно, когда адрес сервера может меняться на стороне провайдера сервиса. Вам не нужно следить за IP: изменения делает владелец канонического имени, а ваша запись остаётся прежней.
Главное ограничение: имя с CNAME не может иметь других записей
По стандарту, если у имени есть CNAME, других записей на этом же имени быть не должно. Это следствие логики алиаса: имя целиком превращается в ссылку. Отсюда и знаменитая проблема корня зоны. Сам домен example.com обязан иметь записи SOA и NS, и потому CNAME на корне поставить нельзя: получится конфликт. Как правило, он проявляется в виде отказа панели управления или, что хуже, тихой поломки почты, ведь MX-записи тоже сидят в корне.
Некоторые DNS-провайдеры предлагают собственные альтернативные технологии, называемые «CNAME flattening» или «ALIAS», где алиас разворачивается на стороне сервера и клиенту отдаётся обычный адрес. Это не стандартный тип записи, а функция конкретного провайдера.
Цепочки и задержка
Технически CNAME может указывать на другой CNAME. Резолвер пройдёт по цепочке, но каждое звено добавляет запрос и время. Длинные цепочки замедляют первое разрешение имени, а слишком длинные или зацикленные приводят к ошибке. На практике держат одно-два звена. Циклы возникают, когда два имени по недосмотру ссылаются друг на друга, и такой конфиг стоит сразу править.
Время жизни ответа определяется TTL: и у самого CNAME, и у записи на конце цепочки. Итоговая свежесть данных определяется меньшим значением, см. страницу dns-ttl.
Где CNAME встречается на практике
Типичный пример: имя www указывает на корень домена или на площадку размещения сайта; отдельные поддомены для сервисов рассылки, помощи или страниц-заглушек ссылаются на адреса внешних платформ; CDN-провайдеры просят создать CNAME на их имя, чтобы направлять трафик через свою сеть. Поддомены разобраны на странице poddomen. Такой приём удобен, но означает, что часть вашего домена зависит от чужой инфраструктуры.
Советуем удалять CNAME, когда сервис больше не используется. Забытая ссылка на освобождённое имя может оказаться в руках чужого человека, а это риск захвата поддомена.
Проверка и типичные ошибки: CNAME
Запрос dig shop.example.com CNAME покажет, на что ссылается имя. Если dig без указания типа возвращает сразу цепочку и адрес, вы увидите весь путь. Частые ошибки: CNAME на корне, CNAME рядом с MX или TXT на том же имени, точка в конце канонического имени, которую забыли поставить в некоторых редакторах зоны, из-за чего значение достраивается доменом зоны. Если сайт не открывается после настройки, сравните ответ авторитетного сервера с тем, что видит резолвер.
Когда CNAME мешает и что выбрать вместо него
Проблемы возникают, когда алиас нужен там, где он недопустим. На корне домена вместо CNAME используют A и AAAA записи с адресами, либо функцию ALIAS у провайдера DNS. Если рядом с именем нужны MX или TXT, CNAME на этом имени тоже не подойдёт: тогда записи создают отдельно или выносят сервис на другой поддомен.
При работе с внешними платформами полезно помнить о зависимости: вы перепоручаете им выбор адресов, и вместе с ними меняется скорость и надёжность. Если платформа сообщила о смене имени, запись нужно обновить. Ещё один нюанс касается сертификатов: сервис, к которому ведёт алиас, должен уметь выдать сертификат на ваше имя, иначе браузер покажет предупреждение, хотя запись DNS настроена верно. Эти два уровня, DNS и TLS, проверяют независимо друг от друга.
Проверять записи полезно после каждого переезда: при смене платформы старый алиас легко забыть. Понятная схема зоны и короткий комментарий рядом с записью экономят время тем, кто будет работать с ней после вас.