Невозможно получить доступ к конечной точке CDN через собственный поддомен - PullRequest
0 голосов
/ 31 марта 2020

моя команда и я в настоящее время изучаем использование Azure stati c блобов сайтов и конечных точек CDN для размещения нескольких веб-приложений.

Мы успешно развернули наши файлы stati c в хранилище блога и все наше тестовое приложение загружается как на основной ( имя . ab c .web.core. windows. net), так и на CDN ( имя .azureedge. net) конечные точки. Однако когда дело доходит до сопоставления пользовательского субдомена с помощью временного шага «cdnverify», у меня ничего не получается.

Я очень внимательно следил и пять раз проверял все шаги в поддержке do c "Учебное пособие: Добавить пользовательский домен для вашей Azure конечной точки CDN "( здесь ).

Это моя текущая конфигурация DNS (через Namecheap).

Когда я пропускаю шаг cdnverify , например, присваиваю значение CNAME azureedge непосредственно хосту с именем «v2», и добавляю его в качестве пользовательского домена в моем блейде CDN портала Azure, субдомен начинает загружать CDN конечная точка и даже может иметь сертификат HTTPS, управляемый CDN, без ручной проверки. Команда dig для этого хоста (v2.ourdomain.org) находит ожидаемый ответ (см. Здесь) .

Однако в этом и заключается проблема. Если я назначу хосту CNAME « cdnverify .static» для « cdnverify . name .azureedge. net.» и добавьте его как пользовательский домен в блейд CDN портала, однако этот вторичный поддомен никогда не загружает нашу конечную точку и не может развернуть сертификат HTTPS. Портал Azure проверил этот хост при добавлении к конечной точке, а команда dig для « cdnverify .stati c .ourdomain.org» показывает этот ответ , который выглядит good.

Команда dig для «stati c .ourdomain.org» не возвращает ответа, а команда ping говорит «неизвестный хост». Это ожидаемо, так как я еще не создал такую ​​запись, и поэтому мне интересно, как мы должны гарантировать, что этот поддомен проверен согласно разделу «Проверка пользовательского домена» в вышеупомянутом do c.

Для нас очень важно, чтобы хост cdnverify работал и ему был присвоен сертификат, прежде чем мы окончательно переместим свои домены, так как эти приложения уже работают. На данный момент я в недоумении, что попробовать дальше. Если возможно, я бы хотел узнать, какие шаги я пропустил, или что еще можно сделать для диагностики проблемы.

Большое спасибо всем, кто мог бы дать совет!

1 Ответ

0 голосов
/ 01 апреля 2020

Субдомен cdnverify предназначен для создания временного сопоставления CNAME, чтобы избежать прерывания веб-трафика c. С помощью этого метода пользователи могут получить доступ к вашему домену без прерывания, пока происходит сопоставление DNS. Если у вас нет работы с веб-приложением, вы можете пропустить шаг cdnverify.

Из вашего описания «команда dig для cdnverify.static.ourdomain.org показывает этот ответ, который выглядит неплохо». Это означает, что хост cdnverify работает, и вы это подтвердили. Вам просто нужно связать пользовательский домен с конечной точкой CDN . На этом шаге вы вводите свой пользовательский домен, например static.ourdomain.org, включая поддомен. Не используйте имя субдомена cdnverify .

После успешного добавления пользовательского домена static.ourdomain.org в конечную точку CDN.

На данный момент ваш пользовательский домен был проверен с помощью Azure, но трафик c на ваш домен еще не перенаправлен на конечную точку CDN. После ожидания достаточно долго, чтобы пользовательские настройки домена могли распространяться на граничные узлы CDN (90 минут для Azure CDN от Verizon, 1-2 минуты для Azure CDN от Akamai), возвращаются на веб-сайт вашего регистратора DNS. site и создайте еще одну запись CNAME, которая сопоставляет ваш поддомен с конечной точкой CDN. Например, укажите поддомен как www or cdn, а имя хоста - .azureedge. net. На этом шаге регистрация вашего пользовательского домена завершена.

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

Наконец, вы можете свободно удалить запись cdnverify CNAME в своем провайдере домена, поскольку это было необходимо только в качестве промежуточного шага.

Ссылка: https://github.com/uglide/azure-content/blob/master/articles/cdn/cdn-map-content-to-custom-domain.md#how -to-map- заказ домена к содержанию для доставки сети CDN-конечная точка

...