Вопрос: Почему нельзя использовать запись CNAME на вершине (aka root) домена?


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

Общеизвестно, что 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 присутствует на узле, никакие другие данные не должны быть   настоящее время; это гарантирует, что данные для канонического имени и его псевдонимов   не могут быть разными.

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

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


104
2017-07-19 10:53


Источник


RFC 1034 предшествует RFC 2119 довольно много времени и опыта. - Michael Hampton♦


Ответы:


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, хотя есть некоторые редкие      приложения для псевдонимов с сопровождающим каноническим именем      undefined в DNS. Имя псевдонима (метка записи CNAME) может,      если DNSSEC используется, имеют SIG, NXT и KEY RR, но могут не иметь      другие данные.  То есть для любой метки в DNS (любое доменное имя)      то верно одно из следующего:

 + one CNAME record exists, optionally accompanied by SIG, NXT, and
   KEY RRs,
 + one or more records exist, none being CNAME records,
 + the name exists, but has no associated RRs of any type,
 + the name does not exist at all.

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

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


Обновить:

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

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


83
2017-07-19 10:53



Я согласен с этим доказательством, и я не думаю, что этот двухэтапный путь доказательства особенно длинный или запутанный. (1. на вершине зоны гарантируется, что SOA + NS записей, 2. CNAME записи не могут сосуществовать с другими данными) - Håkan Lindqvist
В целом, я думаю, это очень хорошее объяснение. Если что-то может быть добавлено, я думаю, что, возможно, это еще раз объяснит, что CNAME запись на самом деле означает, поскольку это, вероятно, наиболее распространенный тип недопонимания. Несмотря на то, что это не что иное, я считаю, что это часто задаваемый вопрос является прямым результатом многих (большинство?), Не имеющих надлежащего понимания CNAME, - Håkan Lindqvist
@Denis Это не может быть всесторонне ответ на комментарий. Самый короткий ответ заключается в том, что вам нужно прочитать RFC (1034, 1035) и хорошо понимать, что такое рефералы, каковы требуемые поведения для реферала (AUTHORITY, присутствие записи SOA и т. Д.) И почему этот тип псевдоним «referral-less» нарушает многие ожидания DNS-серверов на функциональном уровне. И это только для начала. Этот вопрос не является хорошей темой для этого, потому что он является спекулятивным и не связан с проблемой, с которой вы столкнулись бы с работой с правильно спроектированным стандартным DNS-сервером. - Andrew B
@DenisHowe вкратце: нет такой вещи, как «домен» без записей NS и SOA. это не факультативные записи. - hakamadare
@Ekevoo Можно утверждать, что реализация HTTP должна быть принята SRV вместо этого это также сделало бы это не вопросом. Проблема не ограничивается тем, что обсуждается здесь; CNAME вопреки общепринятому мнению, не является отличным соответствием для того, что необходимо. В конце концов, поскольку CNAME не работает, как люди ожидают (!) и не могут быть перепроектированы ретроактивно и поскольку реализации HTTP не используются SRV более вероятно, что функциональность стиля «псевдоним» становится более распространенной для обслуживания HTTP (тип записи, характерный для сглаживания, реализованный за кулисами, а не как вид видимой записи) - Håkan Lindqvist


Если вы перенаправляете всю зону, вы должны использовать 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».


0
2018-03-27 15:41



Это неправильная интерпретация. Обратитесь ко второй строке таблицы в RFC 6672 §2.2, Вершина DNAME приведет к несоответствию типов запросов, отличных от DNAME, на вершине, то есть не приведет к фактическому сглаживанию записи с вершиной A или AAAA. - Andrew B
Вершина DNAME не приведет к перенаправление для запросов имени вершины. Технически не правильно говорить, что это не приведет к совпадение, Вы по-прежнему получите соответствие, если вы запрашиваете NS, SOA или любые другие типы RR, которые на самом деле настоящее время для имени вершины. Из RFC 6672: «Если на вершине зоны присутствует запись DNAME, все равно необходимо иметь обычные записи ресурсов SOA и NS. Такой DNAME нельзя использовать для зеркало зону полностью, поскольку она не зеркало вершины зоны ". - Quuxplusone