Почему запись 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, о котором я не думал. Давайте закроем этого ребенка.
3 ответа
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 запись. Маркированный список ясно дает понять, что SOA, NS, а также A записи не могут быть видны в узле, где CNAME также появляется. Когда мы объединяем это с разделом 6.1, это невозможно 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".