Почему Heroku предостерегает от «голых» доменных имен?

66

Я наткнулся на эту страницу в документации по Heroku ...

Обнаженные домены, также называемые открытыми или верхними доменами, конфигурируются в DNS через A-записи и имеют серьезные последствия для доступности при использовании в высокодоступных средах, таких как массивные локальные центры обработки данных, службы облачной инфраструктуры и платформы, такие как Heroku.

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

Кто-нибудь здесь говорит на «Энтерпрайзе»? О каких «последствиях доступности» они предупреждают?

(Я заметил, что http://stackoverflow.com не работает, поэтому, очевидно, существуют альтернативные подходы по этому вопросу.)

domain-name-system domain cloud cloud-computing heroku Agvorth
источник
24
Я запускаю www.yes-www.org и одобряю этот вопрос.
Майкл Хэмптон
3
Есть и другая проблема: статические активы не могут обслуживаться без прикрепленных файлов cookie (вы не можете добавить файлы cookie ТОЛЬКО для корневого домена; файлы cookie должны быть для поддоменов или для .domain.com(подстановочный знак, используется, если корневой домен)). Вы можете обойти это, обслуживая ресурсы из другого домена (SE использует sstatic.net ), чтобы избежать отвратительного поддомен www.
Том Мартенал
2
@MichaelHampton, почему мы не можем оставлять комментарии на www.yes-www.org? Почему вы не упоминаете ALIAS(или ANAMEзаписи) на своей странице?
Августин Ридингер
Этот вопрос 6 лет, и в основном об ограничениях в программном обеспечении. Любые обновления?
Майкл Коул

Ответы:

58

Что они говорят о том , что когда вы используете , CNAMEчтобы указать на свои услуги (что возможно только на подобласти, а не корневой зоны - она не может сосуществовать с SOAи NSзаписи, которые необходимы на корень вашей зоны), они могут внести изменения в свои собственные записи DNS, чтобы обойти какую-то проблему доступности.

В корне зоны вы должны использовать Aзапись, чтобы указать конкретный IP-адрес для службы. Если у них есть проблема с маршрутизацией или какой-то отказ в обслуживании по этому конкретному адресу, они не смогут обновить запись вашей зоны, A чтобы указывать на другой IP на лету; они могут обновлять свои собственные, и это то, что CNAMEпозволяет им делать.

Это не относится к Stack Exchange, потому что они не используют стороннюю платформу; они будут теми, кто отвечает на проблему доступности, поэтому не имеет значения, является ли это CNAMEили Aнет.

Шейн Мэдден
источник
1
Как насчет ALIAS(или ANAME) записей?
Августин Ридингер
1
@AugustinRiedinger На самом деле это не тип записи DNS - это конфигурация, в которой определенные поставщики DNS будут обрабатывать абстракцию динамической проверки текущей Aзаписи цели, а затем возвращать ее в ответ на запрос этого имени. По сути, они предназначены для решения именно этой проблемы, поэтому они определенно подходят для этого случая.
Шейн Мэдден
1
Так что, если мы их используем, предупреждение о масштабируемости от heroku больше не остается верным, верно? Или есть какой-то технический недостаток в их использовании?
Августин Ридингер
2
@AugustinRiedinger Правильно. Технический недостаток заключается в сложности реализации, так как «стандартный» DNS-сервер не может выполнить такую ​​работу без настройки. Пока реализация вашего провайдера стабильна, она должна быть такой же хорошей, как CNAMEустановка на поддомене.
Шейн Мэдден
13

В дополнение к ответу @ ShaneMadden, один обходной путь - сторонняя платформа, которая также управляет вашей DNS-зоной. Например, если вы используете сервис AWS Elastic Load Balancer и их службу DNS Route 53 , вы можете надежно указать вершину зоны на экземпляр ELB, используя их пользовательские записи псевдонимов , что позволяет им обновлять вашу зону DNS в ответ на проблемы с доступностью.

Это, однако, аргумент против концепции без www , поскольку www.example.comможет иметь CNAMEзапись.

mgorven
источник