Кратко

  • RFC 2672 ввёл DNAME в 1999 году: для любого имени-потомка суффикс владельца заменяется целевым суффиксом. Одна инструкция охватила открытое множество псевдонимов.
  • Сам владелец DNAME не перенаправляется, а делегирование не создаётся. Вершине по-прежнему нужны SOA и NS; отдельная зона возникает благодаря NS RRset в родительской зоне на границе зон.
  • RFC 6672 закрепил эксплуатационные пределы: синтез CNAME для запроса, проверка через подписанный DNAME, сокрытие нижележащих данных, отказ от wildcard-DNAME, ограничение циклов и YXDOMAIN при слишком длинном результате.

Между одним псевдонимом и целой зоной

В RFC 1034 существовали два разных перехода. CNAME объявлял конкретное имя псевдонимом канонического имени. NS RRset на границе зон направлял резолвер к авторитетным серверам дочерней зоны.

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

При переходе с old.example на new.example CNAME для www не помогал mail, lab.mail и будущим именам. Новое делегирование старой зоны, напротив, меняло бы того, кто отвечает за неё, хотя требовалась только непрерывность старых путей.

DNAME занял промежуточное место: шире единичного псевдонима, но уже передачи зоны по своему смыслу.

Суффикс стал исполняемой инструкцией

RFC 2672 определил тип 39 в августе 1999 года. Если имя-потомок заканчивается именем владельца DNAME, этот суффикс заменяется целью. Совпадение проверяется по полным меткам DNS.

DNAME от old.example к new.example превращает www.lab.old.example в www.lab.new.example. Часть www.lab сохраняется. Исходная зона не копирует целевые данные и не получает права ими управлять.

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

Административное сжатие одновременно концентрировало последствия. Ошибка в одной строке могла изменить направление запросов для всего поддерева.

Владелец оставался в исходной точке

Действующий RFC 6672 подчёркивает главное исключение: DNAME применяется к именам ниже владельца, но не к самому владельцу.

www.old.example может перейти к новому суффиксу, тогда как old.example по-прежнему обслуживается на старой вершине. Там разрешены совместимые типы данных. Если это вершина зоны, записи SOA и NS остаются обязательными.

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

Исключение формулирует честное обещание: структурное соответствие потомков, а не полное тождество доменов и полномочий.

Частный CNAME появлялся в ответе

Применяя замену, сервер возвращает DNAME и синтезирует CNAME для точного имени запроса. Для www.lab.old.example ответ может содержать CNAME к www.lab.new.example, хотя такой строки никогда не было в файле зоны.

DNAME — опубликованное общее правило, а синтезированный CNAME — результат его исполнения в одной транзакции. Клиент, знакомый с CNAME, может продолжить поиск; рекурсивный кэширующий сервер также обязан уметь выполнять синтез.

Правило TTL изменилось после эксплуатации. Изначально синтезированный CNAME имел TTL 0. RFC 6672 использует TTL DNAME, но требует от резолверов принимать оба варианта ради старых реализаций.

Идея EDNS-сигнала о понимании DNAME так и не была специфицирована. Совместимость обеспечили обычные ответы DNS и явно описанное поведение, а не несуществующее согласование возможностей.

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

Зона не знает заранее, какие имена-потомки будут запрошены, и не может заранее подписать бесконечное число CNAME. Поэтому DNSSEC подписывает DNAME.

Валидатор проверяет подпись, самостоятельно выполняет замену и убеждается, что неподписанный CNAME является точным детерминированным результатом. Доказательство состоит из аутентичного правила и воспроизводимого вычисления.

Сервер не волен придумать произвольную цель: левые метки сохраняются, суффикс совпадает по границам меток, а целевая часть берётся из подписанной записи.

Однако правильный первый переход не удостоверяет всю цепочку. Дальше могут быть CNAME, другой DNAME, неподписанная зона или ошибка. RFC 6604 поясняет, что RCODE и биты состояния относятся к конечному результату цепочки. Подлинный указатель ещё не доказывает существование или надёжность конечного сервиса.

Указать путь — не значит делегировать власть

RFC 9499 называет поддомен владельца DNAME псевдонимом. Делегирование определено иначе: родительская зона размещает NS RRset для начала дочерней зоны на границе зон.

Referral с NS меняет серверы, которым резолвер приписывает полномочия над исходным именем. DNAME меняет само разыскиваемое имя. Новое имя затем проходит уже существующую систему делегирования цели.

Поэтому вне вершины DNAME не может делить владельца с NS, обозначающим делегирование. Если дочерняя зона использует DNAME на вершине, он находится ниже границы в её авторитетных данных рядом с SOA и NS.

Оператор источника управляет указателем. Операторы родителя и ребёнка поддерживают делегирование источника. Оператор цели управляет конечными данными. Успешный ответ не объединяет эти три полномочия.

Правило скрывало данные под собой

В той же зоне ниже владельца DNAME не должно быть ресурсных записей. Если сервер всё же загрузит их, они окажутся скрыты: поиск встретит перенаправление раньше и уйдёт к цели.

Добавление одной строки способно публично убрать множество имён, не удаляя их из содержимого зоны. Во время перехода кэш может одновременно хранить старые данные потомков и новый DNAME. RFC 6672 допускает временные стратегии, а согласованность возвращается после истечения старых TTL.

Внедрение начинается с инвентаризации всего поддерева. Откат тоже подчинён распределённому времени: удаление записи на авторитетном сервере не отменяет ещё действующие кэшированные копии.

У одного владельца может быть только один DNAME, и CNAME там одновременно запрещён. Широкая область действия не разрешает конкурирующие инструкции в одной точке.

Wildcard начал бы синтезировать само правило

Обычный DNAME — фиксированный авторитетный факт, из которого получаются конкретные CNAME. У wildcard-DNAME подстановка сначала создала бы владельца правила, а затем это временное правило создало бы перенаправление.

RFC 4592 счёл такую конструкцию недетерминированной и опасной для согласованности кэшей. RFC 6672 не рекомендует её и позволяет серверу предупредить, отклонить обновление или зону.

Результат, выведенный из фиксированного авторитетного факта, можно проверить. Если же выводится сам факт, дающий право перенаправлять, происхождение и область полномочий размываются.

DNS должен принимать открытое множество вопросов. Из этого не следует, что при ответе он должен изобретать открытое множество правил управления.

Циклы и длина ограничивали цену удобства

DNAME могут образовывать циклы между собой и с CNAME. Замена способна вернуть имя в область того же правила. Серверы и резолверы должны ограничивать ресурсы, хотя некоторые длинные цепочки допустимы.

Если замена создаёт имя длиннее предела DNS, авторитетный сервер возвращает YXDOMAIN и включает DNAME с подписью, если она есть. Это не NXDOMAIN: исходное имя не просто отсутствует — вычисленный результат невозможно представить.

Целевые имена в NS, MX, PTR и SRV должны быть каноническими хостами. Поиск их адресов не должен зависеть от CNAME или DNAME. Базовые имена, обеспечивающие поиск полномочий и сервисов, не прячутся за дополнительной цепочкой сокращений.

Администратор источника отвечает за отсутствие циклов и чрезмерного роста, сервер — за точную ошибку, резолвер — за предел работы. Удобство настройки не даёт права перекладывать неограниченную стоимость на других.

Доступность не доказывает институциональную преемственность

DNAME сохраняет синтаксическое соответствие и путь запроса во время перехода. Сам по себе он не сохраняет собственность, договор, ключи, сертификаты, доступность или принятие имени приложением.

Надёжная миграция отдельно фиксирует, кто может изменить правило источника, кто управляет целевыми данными и кто отвечает за принятие старого и нового имени сервисом. Чем незаметнее работает DNS, тем опаснее выводить эти отношения из одного успешного ответа.

DNAME мог переместить поиск по дереву имён. Перенести полномочия, организующие это дерево, он не мог. Это ограничение и сделало перенаправление всего поддерева проверяемым.

Источники и границы доказательств

Исходная архитектура CNAME, зон и делегирования — RFC 1034: https://www.rfc-editor.org/rfc/rfc1034.html

Первая спецификация DNAME — RFC 2672: https://www.rfc-editor.org/rfc/rfc2672.html

Проблема wildcard-DNAME — RFC 4592: https://www.rfc-editor.org/rfc/rfc4592.html

Конечное состояние цепочек перенаправления — RFC 6604: https://www.rfc-editor.org/rfc/rfc6604.html

Текущие правила замены, синтеза, DNSSEC и ошибок — RFC 6672: https://www.rfc-editor.org/rfc/rfc6672.html

Современные определения псевдонима и делегирования — RFC 9499: https://www.rfc-editor.org/rfc/rfc9499.html

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