См. Например: Как настроить CNAME для указания на Azure
или текст на лазурном портале:
Почему это вообще необходимо? Почему указывает доменное имя через запись A не доказать, что я владелец домена?
Я имею в виду ... как иначе вообще можно изменить запись DNS?
Какое злоупотребление предотвращает это правило?
Если у вас есть контроль над поиском DNS для компьютера или вы можете внедрить запись хоста, вы можете подделать запись A для этого компьютера и указать ее на веб-сайт Azure (на самом деле ничто не мешает вам делать это для виртуальной машины. хотя)
Заставляя вас создавать запись cname и независимо проверять ее (через свою внутреннюю / общедоступную систему DNS), это означает, что вы действительно контролируете домен и не подделываете чужой домен.
Позвольте мне попытаться ответить на ваш вопрос, приведя два случая. В обоих случаях вам все равно нужно будет подтвердить, что вы являетесь владельцем, это просто шаг безопасности.
1) www.example.com
не посещают и не производят
2) www.example.com
в настоящее время в производстве и активно используется
1) Если ваш домен сейчас настраивается или не находится в производстве / не используется, вы можете создать запись CNAME, указывающую на yoursite.azurewebsites.net
. Нет awverify.myhost.azurewebsites.net
необходимо.
2) Если ваш домен интенсивно используется и к нему в настоящее время осуществляется доступ, и вы хотите проверить, видит ли Azure изменения в ваших записях DNS, вы можете создать поддомен с именем 'awverify
' как в awverify.example.com
и укажите его на созданный поддомен awverify.myhost.azurewebsites.net
. Это не повлияет на ваших текущих пользователей, заходящих на ваш сайт www.example.com
. Как только Azure подтвердит, что видит изменение в CNAME, вы можете уведомить пользователей об обслуживании и изменить запись A. Если вы просто измените запись A, сайт может оставаться в автономном режиме до 8 часов.
Чтобы просто ответить на ваш вопрос, вам не нужно использовать awverify
. Также может сработать простое изменение CNAME. Кроме того, простое изменение записи A перенаправит весь трафик с yourdomain.com
к yoursite.azurewebsites.net
Надеюсь это поможет.
Чтобы доказать контроль над доменом, вам необходимо поместить некоторую информацию в DNS-запись домена, которая будет идентифицировать вашу учетную запись Azure.
Такая информация может быть встроена в доменное имя, на которое указывает CNAME. Я ожидал, что та часть домена, которая не указана в вашем сообщении, будет идентифицировать вашу конкретную учетную запись Azure.
На самом деле вам не нужно держать это имя в секрете. В конце концов, он станет общедоступным после того, как вы поместите его в запись DNS.
Причина, по которой они не могут сделать то же самое с записью A, заключается в том, что в записи A недостаточно энтропии для достижения такой же безопасности.
Это не означает, что CNAME - единственный метод, который они могли использовать. Другие методы, которые могли бы сработать, включают:
Лично я считаю, что запись TXT на подобласти, случайно сгенерированная верификатором, является лучшим методом, поскольку она наименее навязчива. Но, похоже, в вашем случае это не поддерживается.
1) Я установил несколько сайтов в Azure, и все они имеют один и тот же IP-адрес в записи A. Я не знаю, может ли IP-адрес записи A быть также назначен другой учетной записи, но, возможно, это возможно. Если это так, то можно взломать чужой веб-сайт Azure, просто введя домен в свою собственную панель управления Azure. Это всего лишь теория, я не знаю, возможно ли это отдаленно.
2) Как упоминалось выше, запись CNAME в основном инертная. Он не перенаправляет трафик. Когда я перенес большой сайт и его SSL-сертификат, для меня было благословением иметь возможность заявить о праве собственности с помощью awsverify, настроить домен и SSL-сертификат, а затем весь код протестировать в Azure. Спустя несколько недель я изменил пластинку A, чтобы она стала живой. Дело в том, что запись A не изменялась до момента запуска, через несколько недель после использования awsverify для проверки права собственности на домен. Так что в моем случае это было полезно.
Не то чтобы я согласен с этим, но вот ответ, который я получил непосредственно от Microsoft. Короче говоря, он не позволяет кому-либо добавлять принадлежащий вам домен в другое веб-приложение Azure, но только в том же центре обработки данных, что и вы. По сути, кто-то должен попытаться зарегистрировать домен, которым вы владеете, И находиться в том же центре обработки данных (регион Azure), чтобы эта защита была полезной. С точки зрения DNS в этом нет особого смысла, поскольку я могу добавить www.microsoft.com и разместить поддельную веб-страницу на каждом своем веб-сервере, но если у меня нет доступа для изменения записи DNS, это ничего не значит. Конечно, я мог бы сделать это с поддельным DNS-сервером на мошеннической точке доступа, но для чего мне нужно веб-приложение Azure в этом случае? В любом случае я могу развернуть виртуальную машину и обойти ограничение. Для меня это действительно не имеет смысла и действительно раздражает всякий раз, когда приходит время добавить новый сайт. Процесс, который занимает несколько минут, теперь полагается на DNS, прежде чем я смогу даже ДОБАВИТЬ домен в веб-приложение. Обычно это нормально для новых доменов, но если у меня есть уже существующий домен, это больно. Мне нужно создать эту другую запись DNS, затем удалить ее после добавления своего домена в свое веб-приложение, а затем изменить запись DNS, которую я действительно хочу изменить. В любом случае, вот ответ Microsoft о том, почему:
Проблема безопасности заключается в том, что, учитывая этот сценарий, если он позволяет кому-то добавить ваш домен в свое приложение до того, как вы сможете сделать это в своем веб-приложении, вы не сможете снова добавить свой домен из-за конфликта, потому что веб-приложения Azure используют один и тот же серверы переднего плана в одном центре обработки данных. Поэтому он должен проверять каждый домен / поддомен, прежде чем назначать его веб-приложению. Если мы размещаем веб-сайты на виртуальной машине, ограничений на это не будет.