Вот история. У меня есть приложение на azure. Я хотел бы установить A-запись. Мой основной домен — myhost.dk, а azure-адрес — myhost.azurewebsites.net. В руководстве Azure говорится, что я должен настроить CNAME с awverify.myhost.dk, чтобы он указывал на awverify.myhost.azurewebsites.net, прежде чем я смогу создать A-запись. Не знаю, для чего нужен этот awverify. Я действительно запутался. Моя панель управления DNS не очень информативна, и я очень запутался в том, куда поместить все данные.
Если быть точным. Что я должен поместить в CNAME «host» и «canonical name»?
Почему это необходимо в первую очередь? Почему указание доменного имени через запись A не доказывает, что я являюсь владельцем домена? Я имею в виду... как вы можете изменить запись DNS в противном случае? Какие злоупотребления предотвращает это правило?
Ответ 1
Чтобы доказать контроль над доменом, необходимо внести в запись DNS на домене некоторую информацию, которая будет идентифицировать вашу учетную запись Azure.
Такая информация может быть встроена в доменное имя, на которое указывает CNAME. Часть домена, которая была опущена в вашем сообщении, я бы ожидал, что она идентифицирует вашу конкретную учетную запись Azure. На самом деле вам не нужно держать это имя в секрете. В конце концов, оно станет общедоступным, как только вы поместите его в запись DNS. Причина, по которой они не могут сделать то же самое с записью A, заключается в том, что в записи A недостаточно энтропии для достижения такой же безопасности. Это не означает, что CNAME — единственный метод, который они могли использовать. Другие методы, которые могли бы сработать, включают:
TXT-запись
Запись AAAA
Несколько записей A
Лично я считаю TXT-запись на поддомене, случайно сгенерированную верификатором, лучшим методом, поскольку он наименее навязчив. Но в вашем случае это, похоже, не поддерживается.
Ответ 2
Позвольте мне попытаться ответить на ваш вопрос, приведя два случая. В обоих случаях вам все равно нужно будет проверить, что вы являетесь владельцем, это просто шаг безопасности.
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.
Надеюсь, это поможет.
Ответ 3
1) Я создал несколько сайтов на Azure, и все они имеют один и тот же IP-адрес в записи A. Я не знаю, может ли IP-адрес записи A также быть назначен другой учетной записи, но, возможно, такая возможность существует. Если это так, то можно было бы взломать чужой веб-сайт Azure, просто введя домен в собственную панель управления Azure. Это всего лишь теория, я не знаю, возможно ли это на самом деле.
2) Как упоминалось выше, запись CNAME — это, по сути, инертная запись. Она не перенаправляет трафик. Когда я переносил большой сайт и его SSL-сертификат, было счастьем иметь возможность заявить о праве собственности с помощью awsverify, настроить домен и SSL-сертификат, а затем протестировать весь код на Azure. Несколько недель спустя я изменил запись A, чтобы начать работу. Суть в том, что запись A не была изменена до момента запуска, спустя несколько недель после использования awsverify для подтверждения права собственности на домен. Таким образом, в моем случае это было полезно.
Ответ 4
Не то чтобы я был с этим согласен, но вот ответ, который я получил непосредственно от Microsoft. Вкратце, это не позволит кому-то добавить принадлежащий вам домен к другому веб-приложению Azure, но только в том же центре данных, что и вы. То есть, по сути, кто-то должен попытаться зарегистрировать домен, который принадлежит вам, и находиться в том же центре данных (регионе Azure), чтобы эта защита была полезной. С точки зрения DNS это не имеет смысла, поскольку я могу добавить www.microsoft.com и разместить фиктивную веб-страницу на каждом принадлежащем мне веб-сервере, но если у меня нет доступа к изменению DNS-записи, это ничего не значит. Конечно, я могу сделать это с помощью мошеннического DNS-сервера на мошеннической точке доступа, но для чего мне нужно веб-приложение Azure в этом случае? Я могу запустить виртуальную машину и обойти ограничение в любом случае. Это действительно не имеет смысла для меня и просто раздражает всякий раз, когда приходит время добавить новый сайт. Процесс, занимающий несколько минут, теперь полагается на DNS, прежде чем я смогу добавить домен в веб-приложение. Для новых доменов это, в общем, нормально, но если у меня есть существующий домен, то это уже проблема. Мне приходится создавать другую DNS-запись, затем удалять ее после добавления домена в веб-приложение, а затем изменять DNS-запись, которую я действительно хочу изменить. В любом случае вот ответ Microsoft о причинах:
Проблема безопасности заключается в том, что, учитывая этот сценарий, если он позволит кому-то добавить ваш домен в свое приложение до того, как вы сможете сделать это в своем веб-приложении, то вы не сможете добавить свой домен снова из-за конфликта, поскольку веб-приложения Azure используют одни и те же внешние серверы в одном центре данных. Поэтому необходимо проверять каждый домен/поддомен, прежде чем назначить его веб-приложению. Если мы размещаем веб-сайты на виртуальной машине, то никаких ограничений не будет.
Linux