Вопрос: Почему Героку предупреждает о «голых» доменных именах?


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

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

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

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

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


62
2017-07-16 04:55


Источник


я бегу www.yes-www.org и я одобряю этот вопрос. - Michael Hampton♦
Есть и другая проблема: статические активы не могут быть отправлены без прикрепленных файлов cookie (вы не можете добавлять cookie JUST для корневого домена, куки должны быть для субдомена или для .domain.com (подстановочный знак, используемый в корневом домене)). Вы можете обойти это, обслуживая активы из другого домена (SE использует sstatic.net), чтобы избежать отвратительного субдомена www. - Tom Marthenal
@MichaelHampton, почему мы не можем оставлять комментарии на www.yes-www.org? Почему бы вам не упомянуть ALIAS (или ANAME записей) на вашей странице? - Augustin Riedinger
Этот вопрос составляет 6 лет, и в основном это касается ограничений в программном обеспечении. Любые обновления? - Michael Cole


Ответы:


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

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

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


56
2017-07-16 04:59



Как насчет ALIAS (или ANAME) записи? - Augustin Riedinger
@AugustinRiedinger. На самом деле это не тип DNS-записи - они представляют собой конфигурацию, в которой определенные поставщики DNS будут обрабатывать абстрагирование динамической проверки текущего A запись цели, а затем отсылка ее обратно в ответ на запрос для этого имени. Они в основном предназначены для решения этой точной проблемы, поэтому они определенно подходят для использования в этом случае. - Shane Madden♦
Поэтому, если мы их используем, предупреждение о масштабируемости от heroku больше не останется верным, верно? Или есть какой-то технический недостаток в их использовании? - Augustin Riedinger
@AugustinRiedinger Правильно. Технический недостаток заключается в сложности реализации, поскольку «стандартный» DNS-сервер не может выполнить такие вещи без настройки. Пока реализация вашего провайдера является стабильной, она должна быть такой же хорошей, как и CNAME настройка на субдомене. - Shane Madden♦


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

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


12
2017-07-16 05:57