Почему CNAME не может существовать с другими записями, имеющими такое же имя, как и CNAME?

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

Я не нашел хорошего примера, объясняющего проблему.

Вот пример из блога:

Записи CNAME не могут сосуществовать с другими записями, которые имеют тот же FQDN, что и запись CNAME, потому что они фактически перезаписывают все остальные записи с тем же FQDN.

Например, FQDN записи CNAME — example.com, и вы хотите создать запись A с FQDN example.com. Это не разрешено, поскольку FQDN записи A идентичен FQDN записи CNAME, делая запись A бесполезной.

Я не нахожу пример достаточно ясным, чтобы понять проблему.

Я пытаюсь понять, что означает объяснение.

Представьте, я настроил:

Что происходит в такой конфигурации?

ИЗМЕНЕНИЕ: Меня исправили ответами, что мой приведенный выше пример правильный/действительный.

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

Мое понимание заключается в том, что последняя конфигурация недействительна, потому что, согласно RFC, сначала используется CNAME, а запись A никогда не используется.

Прав ли я в отношении причины некорректности последней таблицы?

Или в общем, что происходит в случае последней конфигурации?

Ваш последний пример недействителен не потому, что “что-то используется в первую очередь”. Он недействителен, потому что нарушает логику CNAME.

Логика, о которой я говорю, заключается в том, что CNAME определяет имя как псевдоним другого имени, которое затем называется каноническим именем, “cname” является сокращением этого. Запись alias CNAME canonical-name буквально говорит: “псевдоним является другой формой канонического имени“. Это очень похоже на утверждение: “Боб – это другая форма Роберта”. Это абсурдно добавлять: “и также псевдоним является чем-то другим”, это не имело бы смысла, по крайней мере, в вычислениях. Это не укладывается в модель данных, поэтому RFC это явно запрещает.

Та же логика объясняет CNAME на вершине зоны: вершина должна определять как минимум две записи, SOA и NS, что уже противоречит требованию, что CNAME должен встречаться один. (Поначалу я думал проголосовать за закрытие этого вопроса как дубликата связанного, потому что этот ответ действительно отвечает на этот вопрос тоже; однако, кажется, это другой, более общий, вопрос, и было бы более логично сделать это в обратном направлении.)

Было обновление этого правила, когда был введен DNSSEC. Подписывающие записи должны появляться вместе с CNAME, чтобы подтвердить его действительность в подписанной зоне. Но никакие другие записи не могут. (RFC 2181 говорит “может”, но запись действительно не будет работать без подписи в подписанной зоне.)

То, что CNAME не может сосуществовать с другими типами записей, связано с этим:

НЕ сценарий, который вы описали. Причина его недействительности кажется несколько произвольной, но я считаю, что это требование RFC.

Ваш описанный сценарий вполне допустим – и широко используется. Например:

Ваш пример допустим.

Что недопустимо:

Цитата из первоисточника, RFC 1034:

Система доменов предоставляет такую функцию с использованием канонической записи
(CNAME) RR. CNAME RR определяет имя владельца как псевдоним и
указывает соответствующее каноническое имя в разделе RDATA
RR. Если CNAME RR присутствует в узле, никаких других данных не должно
быть; это обеспечивает, что данные для канонического имени и его
псевдонимов не могут быть различными. Это правило также гарантирует, что
кэшированный CNAME может использоваться без проверки у авторитетного
сервера на предмет других типов RR.