Я наткнулся эта страница в документах Heroku ...
Голые домены, также называемые голыми или верхними доменами, настраиваются в DNS с помощью A-записей и имеют серьезные последствия для доступности при использовании в средах с высокой доступностью, таких как крупные локальные центры обработки данных, службы облачной инфраструктуры и платформы, такие как Heroku.
Для максимальной масштабируемости и отказоустойчивости приложениям следует избегать голых доменов и вместо этого полагаться исключительно на имена хостов на основе поддоменов.
Кто-нибудь здесь говорит на Enterprise? О каких «последствиях доступности» они предупреждают?
(Я заметил, что http://stackoverflow.com не работает, так что, очевидно, есть жизнеспособные альтернативные философии по этому вопросу.)
Они говорят о том, что когда вы используете CNAME указывать на их службы (что возможно только в субдомене, а не в корне зоны - оно не может сосуществовать с SOA и NS записи, которые необходимы в корне вашей зоны), они могут вносить изменения в свои собственные записи DNS, чтобы обойти некоторые проблемы с доступностью.
С корнем зоны вы должны использовать A запись, указывающая на конкретный IP-адрес службы. Если у них есть проблема с маршрутизацией или какой-либо отказ в обслуживании для этого конкретного адреса, они не смогут обновить ваша зона A запись, указывающая на другой IP-адрес на лету; они могут обновлять свои собственные, и вот что CNAME позволяет им делать.
Это не относится к Stack Exchange, потому что они не используют стороннюю платформу; они будут теми, кто ответит на проблему доступности, так что будь то CNAME или A им все равно.
В дополнение к ответу @ShaneMadden, один обходной путь заключается в том, что сторонняя платформа также может управлять вашей зоной DNS. Например, если вы используете AWS Балансировщик эластичной нагрузки служба, и их Маршрут 53 DNS-сервис, вы можете надежно указать вершину зоны на экземпляр ELB, используя их настраиваемые записи псевдонимов, что позволяет им обновлять вашу зону DNS в ответ на проблемы с доступностью.
Однако это аргумент против no-www концепция, поскольку www.example.com может иметь CNAME запись.