Чому Heroku застерігає від "голих" доменних імен?

Я наткнувся на цю сторінку в документах Heroku ...

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

Для максимальної масштабованості та еластичності додатки повинні уникати відкритих доменів і замість цього покладатися виключно на імена хостів на основі субдоменів.

Хтось тут говорить Enterprise? Про які "наслідки щодо доступності" вони попереджають?

(Я помічаю, що http://stackoverflow.com не працює, тому очевидно, що в цьому питанні є життєздатні альтернативні філософії.)

— Аґворт
джерело

Я запускаю www.yes-www.org і схвалюю це питання.

— Майкл Хемптон

Існує ще одна стурбованість: статичні активи не можна подавати без доданих файлів cookie (ви не можете додати файли cookie ОБОВ'ЯЗКОВО для кореневого домену; файли cookie повинні бути для піддомену або для .domain.com(wildcard; використовується, якщо домен root)). Ви можете подолати це, обслуговуючи активи з іншого домену (SE використовує sstatic.net ), щоб уникнути огидного піддомену www.

— Том Мартенал

@MichaelHampton Чому ми не можемо залишати коментарі на www.yes-www.org? Чому ви не згадуєте ALIAS(або ANAMEзаписуєте) на своїй сторінці?

— Августин Рідінгер

Це питання 6 років, і головним чином щодо обмежень у програмному забезпеченні. Будь які оновлення?

— Майкл Коул

Відповіді:

Що вони говорять про те , що коли ви використовуєте , CNAMEщоб вказати на свої послуги (що можливо тільки на підобласті, а НЕ кореневої зони - вона не може співіснувати з SOAі NSзаписи, які необхідні на корінь вашої зони), вони можуть змінити власні записи DNS, щоб вирішити якусь проблему доступності.

З зональним коренем потрібно використовувати Aзапис, щоб вказати на конкретну IP-адресу для послуги. Якщо у них виникають проблеми з маршрутизацією чи якесь відмовлення в обслуговуванні щодо вказаної конкретної адреси, вони не в змозі оновити запис вашої зони, A щоб вказати на інший IP на ходу; вони можуть оновлювати своє власне, і саме це CNAMEдозволяє їм робити.

Це не стосується Stack Exchange, оскільки вони не використовують платформу третьої сторони; вони відповідатимуть на питання про доступність, тож чи є це CNAMEчи не Aмає значення для них.

— Шейн Медден
джерело

Що з ALIAS(або ANAME) записами?

— Августин Рідінгер

@AugustinRiedinger Це фактично не тип запису DNS - це конфігурація, де певні постачальники DNS будуть обробляти абстракцію динамічно перевіряти поточну Aзапис цілі, а потім подавати її у відповідь на запит про це ім'я. Вони по суті розроблені для вирішення цієї точної проблеми, тому їх безумовно доцільно використовувати в цій справі.

— Шейн Мадден

Тож якщо ми їх використовуємо, попередження про масштабність від heroku більше не залишається вірним, правда? Або є якісь технічні недоліки в їх використанні?

— Августин Рідінгер

@AugustinRiedinger Правильно. Технічний недолік - це складність у впровадженні, оскільки "стандартний" DNS-сервер не може виконати подібні речі без налаштування. Поки впровадження вашого провайдера стабільне, воно повинно бути таким же хорошим, як і CNAMEналаштування на субдомен.

— Шейн Мадден

Як доповнення до відповіді @ ShaneMadden, одне вирішення стосується того, щоб стороння платформа також управляла вашою зоною DNS. Наприклад, якщо ви використовуєте службу AWS Elastic Load Balancer та їх службу DNS маршруту 53 , ви можете надійно вказати вершину зони на екземпляр ELB, використовуючи власні записи псевдоніму , що дозволяє їм оновлювати зону DNS у відповідь на проблеми доступності.

Це, однак, аргумент проти концепції no-www , оскільки www.example.comможе мати CNAMEзапис.

— mgorven
джерело