Цепочки CNAME: как пройти по псевдониму до IP-адреса

Запись CNAME делает одно DNS-имя псевдонимом другого, канонического имени хоста. Сам псевдоним не содержит адреса IPv4 или IPv6: резолвер идёт по цели и ищет запрошенные данные там. Цепочка возникает, когда псевдоним указывает на имя, которое само является псевдонимом, или когда настройка DNS у провайдера вводит несколько управляемых целей, прежде чем вернётся адрес. Это обычное дело для хостинг-платформ и CDN. Понимание цепочки объясняет, почему простой запрос может показать сначала имя хоста, а IP — только после дополнительных шагов разрешения.

Проходите по каждому звену осознанно

Допустим, www.example.com — это CNAME на customer.hosting.example, который, в свою очередь, является псевдонимом имени регионального сервиса. Резолвер продолжает идти по цепочке, пока не найдёт запрошенные адресные данные либо не наткнётся на ошибку или некорректную конфигурацию. Каждая цель псевдонима — отдельное DNS-имя, у которого может быть свой TTL и свой провайдер-владелец. При отладке записывайте каждое звено, а не только итоговый адрес. Если цель написана с ошибкой, отсутствует или ссылается обратно по кругу, разрешение может не сработать, хотя первая запись CNAME в панели управления выглядит оформленной правильно.

У CNAME есть ограничения. Имя, являющееся CNAME, как правило, не может одновременно содержать несвязанные данные с тем же именем владельца — за исключением записей, связанных с DNSSEC, и особых реализаций у провайдеров. Поэтому CNAME в корне зоны конфликтует с обязательными записями SOA и NS в стандартном DNS. Некоторые DNS-хостинги предлагают функции ALIAS, ANAME или flattening, чтобы получить аналогичное удобство в корне, но реализуют их по-разному и публично отдают синтезированные адресные записи. Не считайте, что функция в интерфейсе провайдера под названием «alias» обязательно является настоящим CNAME на уровне протокола.

Важны TTL и принадлежность провайдеру

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

• Зафиксируйте каждую цель CNAME от псевдонима до адреса.
• Проверьте A и AAAA на итоговой цели независимо.
• Избегайте циклических псевдонимов и конфликтующих записей у одного владельца.
• Выясните, является ли flattening в корне функцией провайдера или стандартной DNS-записью.
• Сравните TTL, если обновлённая цель видна не везде.

Использование цепочки при миграции

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

Об основном различии между адресными записями и записями-псевдонимами читайте в статье CNAME и A-запись. В справочнике по DNS-записям описаны другие распространённые типы, а инструмент поиска по домену покажет публичные DNS-данные для имени хоста. Видимый CNAME — это указатель, а не сам пункт назначения; надёжный способ понять, к какой конечной точке сейчас ведёт DNS, — проследить всю цепочку.

Как не получить хрупкие цепочки при смене провайдера

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