Рейтинг:1

Регистратор домена разрешает @CNAME для корневого домена, надежно ли это?

флаг in

Из-за пробела в моих знаниях я настроил виртуальную машину Windows в Azure, затем пошел на Namecheap и зарегистрировал домен. Где-то мне пришла в голову идея поставить запись CNAME против @ и полного доменного имени, и это работает.

В моих записях имени есть буквально 2 записи @ и www для CNAME против полного доменного имени виртуальной машины Azure. Все работает сладко.

Вчера парень, на которого я работаю, переключил серверы имен в запланированном домене, которого не было в Namecheap (я использовал фиктивный домен, который я зарегистрировал в Namecheap), и не смог сделать то, что сделал я, и мы потратили несколько часов разбираюсь в нем.

Сегодня я использовал инструмент для поиска сайта, и оказалось, что Namecheap использует предоставленный мной домен для поиска IP-адреса и вводит запись A для этого IP-адреса, но она не отображается на странице управления. Так это делается в фоновом режиме. Вчера я сбросил виртуальную машину, и IP изменился, и домен был восстановлен через пару минут.

Насколько это нормально? Насколько это стабильно? У меня нет выделенного IP-адреса в Azure.

Теперь я понимаю, что @ в домене без www — это ненормально (т. е. обычно нельзя размещать @ против записи CNAME). Но есть ли авторитетные хосты доменов, которые предоставляют эту услугу бесплатно? Это что-то, что я могу искать? (Вторичная проблема заключается в том, что Namecheap в настоящее время не желает брать на себя передачу этого домена, потому что, по-видимому, домены .com.au сложно передать).

Если это редко, могу ли я платить Azure только за статический IP-адрес и использовать записи A?

Рейтинг:2
флаг gg

CNAME в корне не поддерживаются никаким стандартом, но некоторые провайдеры делают это, поскольку это очень удобно. Проблема, как вы заметили, заключается в том, что, поскольку это не стандартизированное решение, реализации различаются, например, запрос имени в CNAME, его разрешение и вставка IP в качестве A-записи.

Я бы не рекомендовал эту практику, поскольку есть реальные причины, по которым корневая запись должна быть записью A или AAAA.

Правильные способы справиться с этим — либо раскошелиться и заплатить за статический IP-адрес от Azure, либо, в качестве альтернативы, если вы размещали много таких сайтов, получить один статический IP-адрес для балансировщика нагрузки/обратного прокси-сервера и позволить он перенаправляет запросы к вашим динамическим веб-приложениям.

Или вы можете использовать Cloudflare, поскольку им действительно удалось реализовать RFC-совместимый CNAME в корневой реализации. https://blog.cloudflare.com/introduction-cname-flattening-rfc-compliant-cnames-at-a-domains-root/

Patrick Mevzek avatar
флаг cn
Новым стандартом станут записи `SVCB` и `HTTPS`, которые будут поддерживать ту же функцию, что и CNAME, но также и на вершине. По крайней мере, они уже используются iOS и CloudFlare.
флаг gg
Наташа, я о таком не слышал!
user160357 avatar
флаг gb
Пожалуйста, объясните, почему это не рекомендуется?
флаг gg
Технически вы можете иметь CNAME в корне, но в соответствии со стандартом никакие другие записи с тем же именем не могут сосуществовать с CNAME, что делает невозможным наличие CNAME в корне, поскольку есть другие записи с тем же именем, которые должен сосуществовать с корневой записью. Сообщение в блоге Cloudflare объясняет это довольно хорошо.
Рейтинг:-1
флаг de

CNAME просто означает псевдоним. Это так же надежно, как запись A, только то, что несколько доменов используют один и тот же IP-адрес. Однако, если срок действия домена, для которого вы используете CNAME, истекает или перестает существовать, вы столкнетесь с той же проблемой поиска, на что указывает ваш домен.

А записи:

домен1 ip

домен2 ip

такой же как :

домен1 ip

домен2 домен1

только то, что во 2-й ситуации, если ip домена 1 обновляется, то и домен 2 обновляется, а в первой оба домена нужно обновлять по отдельности при изменении ip.

Patrick Mevzek avatar
флаг cn
Вы забыли о конкретном случае использования апекса и правиле, согласно которому `CNAME` НЕ может сосуществовать с какими-либо другими записями, в то время как в апексе уже есть другие записи (для начала `NS` и `SOA`). Таким образом, ваш ответ может быть смутно приемлемым в целом, но совсем не для вершины.
флаг de
Это также зависит от используемого программного обеспечения/службы DNS. Некоторые разрешат, некоторые нет. Однако я хотел объяснить, что в целом запись CNAME или A не имеет значения, независимо от уровня домена. Это связано с тем, что независимо от того, является ли субдомен или верхний уровень над ним, есть другие вещи, такие как .com сзади, в то время как www.domain.com может работать и обычно использует CNAME, хотя он считается субдоменом.Если веб-сервер имеет оба домена, имеет смысл использовать CNAME для основного домена сервера, если запись A обновляется, если NS не совпадает, что может помочь в cloudflare, но не разрешено.
Patrick Mevzek avatar
флаг cn
«Это также зависит от используемого программного обеспечения / службы DNS». Нет, это не так. Конечно, вы можете публиковать любую хрень в своей зоне... это не значит, что рекурсивный сервер имен ее примет. Таким образом, даже если вы обнаружите поддельный сервер имен, позволяющий вам поместить CNAME в вершину (и, например, привязка не будет), это не означает, что он будет работать. Наоборот.
Patrick Mevzek avatar
флаг cn
«Как правило, запись CNAME или A не имеет значения, независимо от уровня домена». В общем может быть, на вершине нет. И вопрос был именно про апекс. Так что ответ должен быть об этом в первую очередь. В целом вы можете продолжить после, но если вы не ответите на основной вопрос вершины, ваш ответ будет менее актуальным, чем другие.
Patrick Mevzek avatar
флаг cn
`CNAME` был полезен 40 дней назад, когда не существовало инструмента для массовых обновлений. Сегодня это в значительной степени неактуально, и мы можем жить без него. Любое хорошее программное обеспечение для инициализации может генерировать все необходимые записи `A`/`AAAA`, не полагаясь на CNAME.

Ответить или комментировать

Большинство людей не понимают, что склонность к познанию нового открывает путь к обучению и улучшает межличностные связи. В исследованиях Элисон, например, хотя люди могли точно вспомнить, сколько вопросов было задано в их разговорах, они не чувствовали интуитивно связи между вопросами и симпатиями. В четырех исследованиях, в которых участники сами участвовали в разговорах или читали стенограммы чужих разговоров, люди, как правило, не осознавали, что задаваемый вопрос повлияет — или повлиял — на уровень дружбы между собеседниками.