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

Question

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

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

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

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

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

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

Спасибо

Answer 1

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

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

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

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

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

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

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

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

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

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

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

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