Кратко

  • CNAME превращает owner name в псевдоним, ведущий ровно к одной цели. Чтобы псевдоним и цель не давали противоречивых ответов, owner не может одновременно хранить обычные A, MX, TXT, NS и другие данные.
  • Resolver кеширует CNAME и начинает поиск заново у цели. Исходная зона контролирует обход, authority цели — конечные данные; это не delegation и не доказательство идентичности.

Одно имя не могло выполнять две несовместимые работы

Пусть portal.example опубликован как CNAME для service.example.net. На запрос адреса исходный сервер возвращает псевдоним, а resolver ищет A или AAAA у цели. Если исходная зона одновременно опубликует собственный A для portal.example, какому адресу должен поверить кеш: прямому ответу старого имени или результату после перехода?

RFC 1034, выпущенный в ноябре 1987 года, не оставил конфликт на усмотрение реализаций. Owner CNAME — это alias, а имя в RDATA — canonical target. Если в узле есть CNAME, других обычных данных там быть не должно.

Это не вопрос аккуратности zone file. Правило не даёт данным канонического имени и псевдонима разойтись. Оно также позволяет resolver использовать кешированный CNAME без повторной проверки у исходной authority, нет ли у того же owner другого типа, противоречащего обходу.

Исключительность создала узкую власть: CNAME не определяет адрес или сервис. Он определяет, где продолжить вопрос.

Ответ менял следующий вопрос

CNAME не просто возвращает иное написание. Если QTYPE не CNAME, алгоритм RFC 1034 помещает запись в Answer, меняет рабочий QNAME на цель и начинает поиск сначала. Запрос типа CNAME — исключение: он изучает сам переход.

RFC 9499 различает original QNAME в вопросе, effective QNAME на этапах цепочки и final QNAME в конце. Поэтому ответ может повторять исходный вопрос, но RRset, который действительно отвечает, принадлежит другому имени.

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

Обход не был делегированием

Alias и delegation заставляют resolver двигаться дальше, но передают разные вещи. NS RRset на zone cut называет серверы с authority над нижестоящей зоной. CNAME остаётся данными исходной authority о своём имени. Он начинает новый поиск, но не отдаёт исходную зону оператору цели.

Источник создаёт, меняет или удаляет portal.example и задаёт alias TTL. Authority для service.example.net управляет A, AAAA и прочими конечными RRsets с собственными TTL. Указание на цель не даёт права менять её; цель не получает права редактировать alias.

RFC 6604 позднее уточнил статусы в цепочках CNAME и DNAME. Ответ может быть authoritative для первого alias и содержать referral или failure с более позднего этапа. Власть над первым утверждением не гарантирует весь путь.

Одна цель на alias — не одно имя на машину

Слово «канонический» породило слишком широкий вывод: будто у каждого host или interface может быть только одно официальное имя. RFC 2181 отверг эту трактовку. DNS не задаёт машине единственную именную идентичность.

Правило уже: у одного CNAME owner одна canonical target. Разговорное название самого owner «CNAME» также скрывает направление. Owner является alias, а значение записи — каноническим именем внутри этой связи.

Несколько доменных имён могут вести к одному сервису. Имя, не являющееся alias, может содержать разные обычные RRsets. Запрещено лишь одновременно говорить «спросите в другом месте» и представляться самостоятельным пунктом назначения.

Почему apex не мог воспользоваться коротким путём

Zone apex обязан содержать SOA и NS. Поскольку CNAME owner не может сосуществовать с такими обычными данными, apex не может быть обычным CNAME. RFC 1912 показал опасность на историческом примере BIND: CNAME рядом с NS на apex мог заставить сервер игнорировать другие ресурсы, делая невидимыми имена ниже зоны.

Точное поведение относилось к версиям того времени; противоречие относится к модели данных. Провайдер может синтезировать адреса на apex или предлагать flattening. Это может быть полезно, но не является обычным CNAME RR на проводе. Смешение терминов стирает нужные при расследовании границы authority и cache.

NS и MX не могли прятать следующий адрес за alias

RFC 2181 запрещает alias как target NS или exchange MX. Ответы NS и MX могут приложить адреса в Additional, чтобы исключить предсказуемые запросы. Эта обработка не проходит CNAME и не добавляет затем адрес canonical target.

Alias в такой позиции создаёт дополнительные запросы и нагрузку; в сложных случаях delegation отсутствие адреса может сорвать resolution. Администратору следует один раз разрешить alias и прямо указать имя, которому принадлежат address RRsets.

Это не общий запрет ссылок между именами. Ограничение защищает позиции, где предсказуемое обнаружение адреса входит в рабочий путь.

DNSSEC добавил доказательство, а не второе назначение

Фраза «никаких других данных» получила необходимое исключение с развитием DNSSEC. RFC 2181 допускал записи безопасности своего времени; RFC 4034 требует RRSIG и NSEC у CNAME owner в подписанной зоне.

Они не конкурируют с целью. RRSIG аутентифицирует CNAME RRset, NSEC участвует в authenticated denial и доказательстве типов. Эти записи подтверждают состояние узла alias, не возвращая ему собственный адрес, почтовый маршрут или данные приложения.

RFC 4033 ограничивает и вывод о безопасности. DNSSEC даёт аутентификацию происхождения данных, целостность и аутентифицированное отрицание. Он не удостоверяет здоровье сервиса, компанию, договор или юридическое владение исходным именем.

Цепочки разрешались, петли — нет

Alias может указывать на другой alias. RFC 1034 советует избегать многих уровней из-за неэффективности, но не объявляет конечную цепочку ошибкой. Resolver должен обнаруживать loops и цели, которых не существует.

Операционный объект — граф. У каждого ребра свой owner, authority, TTL и, возможно, DNSSEC state; у terminal RRset другая жизнь. Два кеша могут показывать разные фазы одной миграции, потому что старые рёбра истекают не одновременно.

В этом ценность развязки. Источник переносит знакомое имя без копирования конечных данных; цель меняет адреса без правки всех ссылающихся зон. Цена — независимые изменения, пока кеши хранят прежние утверждения до конца TTL.

Минимальная координация требовала несмешанной истины

CNAME решил задачу распределённого сопровождения намеренно тонким механизмом. Не потребовались мировой registry эквивалентных имён и центральный арбитр «настоящего» адреса alias. Достаточно одного однозначного ребра, которое любой resolver может сохранить и пройти.

Исключительность — институциональный центр конструкции. Исходное имя бывает обходом или целью, но не обоими сразу. Выбрав обход, оно сохраняет реальную и узкую authority: публикует одну цель, сохраняет evidence цепочки и оставляет конечные данные их собственной authority.

Источники и границы

Исходная модель и алгоритм взяты из RFC 1034 и RFC 1035, эксплуатационные ошибки и уточнения — из RFC 1912 и RFC 2181, исключения DNSSEC — из RFC 4033 и RFC 4034, статусы цепочек и терминология — из RFC 6604 и RFC 9499. Они не доказывают нынешнее распространение, особенности flattening у провайдеров, современные пределы цепочек, частоту брошенных alias, владение приложением или текущую доступность.