У меня есть платформа, которую я сделал для себя с целью потенциально открыть ее для более широкой аудитории. Он всегда был на Linode и будет там изначально, но я могу представить себе, как переношу его на Elastic Beanstalk на AWS, если он достигнет даже небольшого спроса.
Я попытался, чтобы ориентированные на будущее пользователи могли использовать свой собственный зарегистрированный домен вместо субдомена, который я им предоставляю (user.example.com). В качестве доказательства моей концепции у меня был собственный домен пользователя (me.com) зарегистрирован отдельно от домена платформы (example.com) и смог отлично справиться с этой задачей, создав запись A в регистраторе для me.com который указывал на мой IP-адрес Linode и создавал запись виртуального хоста, которая перехватывала все домены, указывающие ему путь, и проверяла, что это зарегистрированный для пользователя.
Итак, все работает.
Я осознал, что недолго до начала проекта, что это не идеальная практика. Избыточность не была серьезной проблемой, поскольку, если мой единственный IP-адрес вышел из строя, служба все равно не работала. Наличие 5 других серверов имен для отката не поможет в этом сценарии. Моим основным ограничением была вероятность изменения IP-адреса. Я даже предвижу переход на AWS в будущем, как упоминалось выше.
У меня вопрос: действительно ли переход от указания самостоятельно зарегистрированных доменов пользователя к методу, который позволяет мне изменить IP-адрес, будет таким же финансово трудным, как кажется?
Я не буду зарабатывать много денег на этой платформе, так как пользователи не будут платить много за ее использование (она предлагает свежий, локальный вариант немного похожих услуг, но эти услуги сильно финансируются и стоят по низкой цене), поэтому я я уже сокращаю расходы на хостинг. Я также не хочу брать на себя дальнейшие обязанности, например, быть регистратором домена, и у меня недостаточно сообразительности, чтобы уверенно управлять своим собственным сервером имен.
Типичным ответом на это будет использование независимого сервера имен и регистрация A-записи для каждого домена. Моя ситуация - это немного больше ниша, где платформа больше построена на представлении профессии. Так что у меня может быть много пользователей с пользовательскими доменами, мало трафика и мало платящих.
Большинство служб DNS, похоже, предлагают ограниченные записи A или небольшие объемы запросов DNS. У меня есть возможность увидеть кратковременный всплеск запросов, а неожиданный счет за один месяц может оказаться финансово катастрофическим. Я считаю, что в основном это обслуживается на стороне хостинга, но теперь мне придется беспокоиться об этом и на стороне сервера имен. Я не могу перепродавать ресурсы в такой степени, в какой могла бы стандартная платформа, поскольку у меня были бы десятки или сотни пользователей, а не тысячи.
Хотя это, конечно, не рекомендуется, если я не хочу платить сквозь зубы, могу ли я вернуться к использованию записи A для моего IP-адреса и попросить пользователей обновить ее, когда / если я меняю сервер? Мне бы очень понравилось, если бы компания предложила тщеславный IP-адрес, который я мог бы направить на второй (мой сервер) и изменить позже, но я думаю, что серверы имен заполняют эту нишу для большинства применений.
Вместо создания А записи на внешних доменах, создать CNAME те, так например
yourapp.me.com IN CNAME platform.example.com
yourapp.someotherdomain.com IN CNAME platform.example.com
Затем в example.com создайте несколько А записи с несколькими IP-адресами серверов и одним и тем же именем (пока у вас только один)
platform.example.com IN A 1.2.3.4
platform.example.com IN A 1.2.3.5
platform.example.com IN A 1.2.3.6
Таким образом, у вас может быть несколько внутренних серверов, и, когда возникнет необходимость, измените их IP-адреса, и все будет каскадно распространяться на клиентские домены.
Чтобы он работал лучше всего, я бы посоветовал не использовать TTL для записей DNS более 2 часов, предпочтительно 1 час или меньше, если частые запросы DNS не являются проблемой, и уменьшите это время до 15 минут - 24 часов до переноса IP-адресов серверов.
И самое приятное здесь: это бесплатно, этот метод не стоит ни копейки.
Однако размещение записей CNAME в корневых доменах, скорее всего, приведет к поломке всех других записей в домене, от которых мне осталась Эса Джоникен. В этом случае лучше всего ограничить конфигурацию вложенными именами.