Это Канонический вопрос о CNAME на вершинах (или корнях) зон
Относительно общеизвестно, что CNAME записи на вершине домена являются запретной практикой.
Пример: example.com. IN CNAME ithurts.example.net.
В лучшем случае программное обеспечение сервера имен может отказать в загрузке конфигурации, а в худшем случае оно может принять эту конфигурацию и аннулировать конфигурацию для example.com.
Недавно я попросил компанию, занимающуюся веб-хостингом, передать инструкции бизнес-подразделению, которые нам нужны для CNAME вершины нашего домена для новой записи. Зная, что при загрузке в BIND это будет самоубийственная конфигурация, я посоветовал им, что мы не сможем подчиниться, и что это вообще бессмысленный совет. Компания, занимающаяся веб-хостингом, заявила, что это не запрещено стандартными RFC, и что их программное обеспечение поддерживает это. Если бы мы не могли CNAME вершины, они посоветовали вообще не иметь записи вершины и не предоставляли бы перенаправляющий веб-сервер. ...Какой?
Большинство из нас знает, что 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 для источника зоны, которые, наряду с записью начала полномочий (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 запись. Маркированный список ясно дает понять, что SOA, NS, и A записи нельзя увидеть на узле, где CNAME тоже появляется. Когда мы объединяем это с разделом 6.1, невозможно CNAME существовать на вершине, поскольку он должен был бы жить рядом с обязательными SOA и NS записи.
(Кажется, это работает, но если у кого-то есть более короткий путь к доказательству, пожалуйста, дайте ему трещину.)
Обновить:
Кажется, что недавняя путаница исходит из Недавнее решение Cloudflare чтобы разрешить определение недопустимой записи CNAME на вершине доменов, для которых они будут синтезировать записи A. «Соответствие RFC», как описано в связанной статье, относится к тому факту, что записи, синтезированные Cloudflare, будут хорошо работать с DNS. Это не меняет того факта, что это полностью настраиваемое поведение.
На мой взгляд, это оказывает медвежью услугу большему сообществу DNS: на самом деле это не запись CNAME, и это вводит людей в заблуждение, заставляя думать, что другое программное обеспечение не позволяет этого делать. (как показывает мой вопрос)
Консорциум Интернет-систем недавно опубликовал обзор 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».