субдомены, имя, безопасность и маршрутизация

218
user863791

ПРИМЕЧАНИЕ: я консультант по маркетинговой стратегии, а не консультант по технологиям, поэтому:

У меня есть клиент, для которого мы используем стороннее решение облачного хостинга для создания небольших (одностраничных) веб-сайтов для своих клиентов. В секторе конечных клиентов всем клиентам будет очень трудно получить собственное имя MyWebSite.com, что является одним из факторов, по которым мой клиент хочет использовать субдомены для этих сайтов: XYZ.MyClient.com. Конечным клиентам хорошо с этим решением из того, что мы видели.

Сторонняя фирма облачного хостинга, которую мы используем, говорит, что мы должны просто использовать подстановочный знак A NAME (например, * .MyClient.com), и это будет направлять весь трафик субдомена через их платформу и на правильный сайт, не затрагивая основной домен в все (www.MyClient.com).

Аутсорсинговая ИТ-фирма моего клиента утверждает, что нет, это универсальное решение фактически направит весь трафик www.MyClient.com через стороннюю хостинговую фирму, прежде чем попасть на нужный сайт. Они утверждают, что лучшее решение - создать запись A NAME для каждого субдомена и управлять теми, которые перемещаются на сотни сайтов.

Мне просто нужны ответы, потому что я могу облегчить дискуссию между всеми сторонами - мне все равно, какой ответ. Я просто хочу, чтобы у моего клиента было безопасное, управляемое и экономически эффективное решение. Мои вопросы тогда:

  1. Будет ли использование подстановочного знака A NAME фактически направлять ядро ​​www.MyClient.com через стороннюю хостинговую фирму?
    1. Если так, то почему это проблема? Задержка? Безопасность? Другой?
    2. Я читал в другом месте (хотя это был 5-летний пост), что было бы хорошо иметь отдельный сертификат безопасности для настройки субдомена. Это так? Если так, может кто-нибудь указать мне хорошую ссылку на это?
    3. Управление сотнями записей A NAME для поддоменов поражает меня как создание большого объема работы, которая поддается ошибкам и доработкам. Верно или нет?
    4. Я что-то пропустил?

Спасибо

0
https://tools.ietf.org/html/rfc4592#section-2.2.1 содержит информацию об этой категории проблем. Я бы предпочел не писать ничего другого, чтобы избежать ошибки A.B 6 лет назад 1

1 ответ на вопрос

1
grawity

Будет ли использование подстановочного знака A NAME фактически направлять ядро ​​www.MyClient.com через стороннюю хостинговую фирму?

Нет. Существующие конкретные имена всегда имеют приоритет над подстановочными совпадениями. (См. «Правила существования» в ранее связанном RFC 4592. )

Если так, то почему это проблема? Задержка? Безопасность? Другой?

Задержка и навязывание довольно небольшого требования к пропускной способности стороннему поставщику, поскольку он должен ретранслировать весь трафик на ваш настоящий веб-сервер. (Я готов поспорить, что они просто не будут этого делать.)

И, конечно же, сторонний поставщик получает полный контроль над содержимым вашего основного веб-сайта. Это нежелательно, даже если вы уже доверяете им веб-страницы своих клиентов.

Я читал в другом месте (хотя это был 5-летний пост), что было бы хорошо иметь отдельный сертификат безопасности для настройки субдомена.

Я не очень много знаю об этом, но по сути у вас есть три варианта:

  • Выдать новый сертификат для каждого субдомена. Вполне возможно, в настоящее время с Let's Encrypt, и сторонний поставщик может сделать это самостоятельно.
  • Выдать несколько сертификатов, каждый из которых действителен для нескольких десятков поддоменов одновременно. Раньше это делалось в прошлом (до LE), но, пожалуй, наиболее трудно поддерживать в сравнении.
  • Выдать групповой сертификат для *.myclient.com. Хотя проще в управлении, но стоит дороже и теоретически позволяет стороннему хосту каким-то образом выдавать себя за ваш wwwподдомен. (Это немного растянутый аргумент; в любом случае, с LE существуют те же проблемы.)

Управление сотнями записей A NAME для поддоменов поражает меня как создание большого объема работы, которая поддается ошибкам и доработкам. Верно или нет?

Самая большая проблема, которую я вижу с direct A/ AAAArecords, заключается в том, что было бы довольно неудобно обновлять их все, если когда-либо изменился IP-адрес сервера. Наличие всех этих поддоменов CNAMEs (псевдонимов) упростит задачу, поскольку необходимо будет обновить только один домен (цель CNAME).

Но количество поддоменов, как правило, не кажется проблемой - если их создание и удаление четко определены как часть процедуры установки нового клиента. (То есть, если ваша система не может полностью автоматизировать ее при открытии веб-страницы нового клиента ...)

Тем не менее, подстановочный знак будет еще проще.

Похожие вопросы