Как крупные поставщики SaaS поддерживают записи A?

В соответствии с RFC 1035 Записи CNAME нельзя использовать в верхней части зоны, потому что запись CNAME не может существовать вместе с такими записями, как SOA.

Это часто является источником разочарования для тех, кто пытается разрабатывать приложения SaaS для поддержки пользовательских доменов, оставаясь при этом высокодоступными и масштабируемыми.

Варианты в основном:

1. Живите с фиксированным набором IP-адресов
2. Настаивайте, чтобы пользователи использовали ваши DNS-серверы, чтобы вы могли обновлять записи
3. Настаивайте, чтобы все использовали www. с CNAME и позволить пользователям выяснить, как перенаправить их голый домен

После изучения ряда крупных продуктов SaaS кажется, что большинство из них поддерживает вариант 1, хотя кажется, что это самый сложный вариант при ожидании быстрого роста и достижения высокой доступности.

Например:

• GitHub: Два IP-адреса для записей A
• SquareSpace: Четыре IP для записей A, хотя я думаю, что до недавнего времени это был только один
• BigCommerce: Рекомендуется использовать их DNS, но у каждого магазина есть определенный IP, который может быть изменен.
• Shopify: Один IP-адрес для записей A
• WordPress.com: Необходимо использовать их DNS

Как правило, наличие фиксированного набора IP-адресов создает следующие проблемы:

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

У меня вопрос, в частности, как провайдеры, предлагающие фиксированный набор записей A, преодолевают эти ограничения? Особенно тем, кто предлагает только одну пластинку A?

Они:

• У вас есть по одному балансировщику нагрузки на каждый IP-адрес, который они предоставляют, в надежде, что они никогда не превысят возможности крупнейших серверов, которые они могут запустить в этой роли, а в случае отказа просто переместите IP-адрес на другой сервер?
• Пользовательские аппаратные балансировщики нагрузки, которые предположительно более надежны и обладают достаточной емкостью, чтобы они никогда не были узким местом?
• Использовать что-то вроде IP anycast, где произвольное количество балансировщиков нагрузки может получать пакеты для определенного IP?
• Смесь вышеперечисленного?

Я предполагаю, что те, кто работает в публичных облаках (например, AWS, Azure и т. Д.), Будут первыми, а те, у кого есть собственная инфраструктура, будут в основном вторыми?