Почему запись CNAME не может быть использована в верхушке (он же root) домена?

Это канонический вопрос о CNAME в верхушках (или корнях) зон

Общеизвестно, что CNAMEзаписи на вершине домена являются запретной практикой.

Пример: example.com. IN CNAME ithurts.example.net.

В лучшем случае программное обеспечение сервера имен может отказаться загружать конфигурацию, а в худшем случае оно может принять эту конфигурацию и сделать недействительной конфигурацию для example.com.

Недавно я попросил компанию, предоставляющую услуги веб-хостинга, передать бизнес-подразделению инструкции, необходимые для CNAME вершины нашего домена для новой записи. Зная, что это будет самоубийственный конфиг при подаче в BIND, я посоветовал им, что мы не сможем подчиниться, и что это был общий совет. Компания, занимающаяся веб-хостингом, заняла позицию, что это не запрещается стандартным определением RFC и что их программное обеспечение поддерживает это. Если бы мы не могли CNAME apex, их совет состоял в том, чтобы вообще не иметь записи apex, и они не предоставили бы перенаправляющий веб-сервер. ...Какая?

Большинство из нас знает, что RFC1912 настаивает на этом A CNAME record is not allowed to coexist with any other data., но давайте будем честны с самим собой, что RFC является исключительно информационным. Из словоблудия, запрещающего эту практику, я знаю больше всего : RFC1034 :

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

К сожалению, я был в отрасли достаточно долго, чтобы знать, что «не должен» - это не то же самое, что «не должен», и этого достаточно, чтобы большинство разработчиков программного обеспечения повесились. Зная, что что-либо, кроме краткой ссылки на громкий данк, было бы пустой тратой моего времени, я в итоге позволил компании ругаться за рекомендацию конфигураций, которые могут нарушить работу часто используемого программного обеспечения без должного раскрытия.

Это подводит нас к вопросам и ответам. На этот раз я бы хотел, чтобы мы действительно разбирались в безумстве топовых CNAME, а не обошли стороной проблему, как мы обычно делаем, когда кто-то публикует сообщения на эту тему. RFC1912 запрещен, как и любой другой применимый здесь информационный RFC, о котором я не думал. Давайте закроем этого ребенка.

CNAMEПервоначально записи были созданы для того, чтобы несколько имен, которые предоставляют один и тот же ресурс, были связаны с одним «каноническим именем» для ресурса. С появлением виртуального хостинга, основанного на именах, вместо этого стало обычным делом использовать их в качестве общей формы псевдонимов IP-адресов. К сожалению, большинство людей, пришедших с веб-хостинга, ожидают, что CNAMEзаписи указывают на эквивалентность в DNS , что никогда не было целью. Вершина содержит типы записей, которые явно не используются при идентификации канонического хост-ресурса ( NS, SOA), который не может быть псевдонимом без нарушения стандарта на фундаментальном уровне. (особенно в отношении зон сокращений )

К сожалению, оригинальный стандарт DNS был написан до того, как руководящие органы стандартов осознали, что для определения согласованного поведения необходимо явное словесное выражение ( RFC 2119 ). Необходимо было создать RFC 2181, чтобы прояснить несколько угловых случаев из-за расплывчатых формулировок, и обновленное словосочетание проясняет, что CNAME нельзя использовать для достижения псевдонимов вершины без нарушения стандарта.

6.1. Зональная власть

Полномочные серверы для зоны перечисляются в записях NS для источника зоны, которые вместе с записью Start of Authority (SOA) являются обязательными записями в каждой зоне. Такой сервер является полномочным для всех записей ресурсов в зоне, которые не находятся в другой зоне. Записи NS, которые указывают на срез зоны, являются свойством созданной дочерней зоны, как и любые другие записи для происхождения этой дочерней зоны или любых ее поддоменов. Сервер для зоны не должен возвращать достоверные ответы на запросы, относящиеся к именам в другой зоне, которая включает в себя NS и, возможно, A, записи в разрезе зоны, если только он также не является сервером для другой зоны.

Это устанавливает, что SOAи NSзаписи являются обязательными, но это ничего не говорит о Aили других типах, появляющихся здесь. Может показаться излишним, что я цитирую это тогда, но это станет более актуальным в данный момент.

RFC 1034 был несколько расплывчатым в отношении проблем, которые могут возникнуть, когда CNAMEсуществует наряду с другими типами записей. RFC 2181 устраняет неоднозначность и явно устанавливает типы записей, которые могут существовать вместе с ними:

10.1. Записи ресурса CNAME

DNS-запись CNAME («каноническое имя») существует для предоставления канонического имени, связанного с псевдонимом. Для любого псевдонима может быть только одно такое каноническое имя. Это имя, как правило, должно быть именем, которое существует в другом месте в DNS, хотя существуют некоторые редкие приложения для псевдонимов с сопутствующим каноническим именем, неопределенным в DNS. Псевдоним (метка записи CNAME) может, если используется DNSSEC, иметь SIG, NXT и KEY RR, но может не иметь других данных. То есть для любой метки в DNS (любое доменное имя) верно только одно из следующих:

• существует одна запись CNAME, опционально сопровождаемая SIG, NXT и KEY RR,
• существует одна или несколько записей, ни одна из которых не является записями CNAME,
• имя существует, но не имеет связанных RR любого типа,
• имя не существует вообще.

«псевдоним» в данном контексте относится к левой части CNAMEзаписи. Маркированный список ясно дает понять, что записи a SOA, NSи Aне могут быть видны в узле, где CNAMEтакже появляется a . Когда мы совмещаем это с разделом 6.1, для a невозможно CNAMEсуществовать на вершине, так как он должен был бы жить вместе с обязательными SOAи NSзаписями.

(Похоже, это делает работу, но если у кого-то есть более короткий путь к доказательству, пожалуйста, дайте трещину.)

Обновить:

Кажется, что более свежая путаница связана с недавним решением Cloudflare разрешить определение незаконной записи CNAME на вершине доменов, для которых они будут синтезировать записи A. «Соответствие RFC», как описано в связанной статье, относится к тому факту, что записи, синтезированные Cloudflare, будут хорошо воспроизводиться с DNS. Это не меняет того факта, что это совершенно нестандартное поведение.

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

Консорциум Internet Systems недавно опубликовал статью о CNAME на вершине зоны , почему существует такое ограничение, и ряд альтернатив. Это вряд ли изменится в ближайшее время, к сожалению:

Мы не можем изменить способ использования специальной записи CNAME, не изменив одновременно все> реализации DNS-серверов в мире. Это потому, что его значение и интерпретация были строго определены в протоколе DNS; все текущие реализации клиента и сервера DNS соответствуют этой спецификации. Попытка «ослабить» использование CNAME на авторитетных серверах без одновременной смены всех работающих в настоящее время DNS-распознавателей приведет к сбою разрешения имен (и веб-службы и службы электронной почты будут периодически недоступны для тех организаций, которые внедряют «расслабленные» авторитетные серверные решения).

Но есть надежда:

Другое потенциальное решение, обсуждаемое в настоящее время, добавило бы новый тип записи ресурса DNS, который могли бы искать браузеры, который мог бы существовать на вершине. Это будет специфичное для приложения имя хоста для http-запросов (аналогично тому, как работает MX).

Плюсы: это полностью соответствует дизайну DNS.
Минусы: это еще не доступно, и потребует обновления клиента браузера.

Если вы перенаправляете всю зону, вы должны использовать DNAME. Согласно RFC 6672 ,

DNAME RR и CNAME RR [RFC1034] вызывают поиск для (потенциально) возврата данных, соответствующих доменному имени, отличному от запрашиваемого доменного имени. Разница между двумя записями ресурсов заключается в том, что CNAME RR направляет поиск данных у своего владельца на другое одно имя, тогда как DNAME RR направляет поиск данных у потомков имени своего владельца на соответствующие имена в другом (одном) узле дерево.

Например, просмотрите зону (см. RFC 1034 [RFC1034], раздел 4.3.2, шаг 3) для доменного имени "foo.example.com", и запись ресурса DNAME найдена в "example.com", указывая чтобы все запросы в "example.com" были направлены на "example.net". Процесс поиска вернется к шагу 1 с новым именем запроса "foo.example.net". Если бы имя запроса было "www.foo.example.com", новое имя запроса было бы "www.foo.example.net".