У вас есть несколько вариантов, о которых я знаю, в основном в зависимости от того, идет ли трафик на тот же ip или нет.
При настройке записей DNS вы можете указать шаблон для поддоменов. *.example.com, который делает это так, чтобы любой запрос для любого поддомена, который не соответствует другой записи DNS, отправляется example.com.
Таким образом, имея:
*.example.com <ip A>
blog.example.com <ip B>
сделать бы blog.example.com пойти < внутрибрюшинно B> и example.com и все остальные субдомены перейти к < внутрибрюшинно A>.
Это означает, что у вас может быть возможность предоставить каждому новому поддомену свой собственный ip (очень маловероятный). Вы также можете поймать их всех на одном и том же ip и обрабатывать их там.
Как вы упомянули, вы можете добавить новый виртуальный хост для каждого созданного нового поддомена. Тем не менее, это своего рода тяжелое решение, и я думаю, что это, как правило, предполагает перезапуск вашей программы веб-сервера для перезагрузки новой конфигурации. Вместо этого вы можете использовать что-то вроде перезаписи для достижения чего-то похожего на виртуальный хост.
Правило перезаписи, которое делает <subdomain>.example.com/<resource> => example.com/<subdomain>/<resource>, будет означать, что все, что потребуется, - это создать новую папку в корне ваших обслуживаемых каталогов, содержащих контент пользователя. Никаких изменений в конфигурации. Кроме того, я не уверен, что вы знакомы с переписываниями, но они невидимы для браузера/пользователя, поэтому пользователь все еще видит <subdomain>.example.com/<resource>, даже если они обслуживаются содержимым от example.com/<subdomain/<resource>.
Это не окончательный список возможностей, просто пара возможностей. Любое большое или масштабируемое решение, вероятно, будет включать в себя множество уровней косвенности, позволяющих более сложное управление DNS, балансировку нагрузки и обслуживание контента.