должны домены Apex (и записи) избежаться?
Необходимо отбросить начальную букву '/' от соответствия с RewriteCond
Посмотрите примеры в http://httpd.apache.org/docs/2.2/mod/mod_rewrite.html#rewritecond
RewriteEngine On
RewriteCond %{REQUEST_URI} !^folder/
RewriteRule (.*) /folder/$1
Я считаю, что этот текст Heroku, на который вы ссылаетесь, относится только к службам, размещенным на Heroku и аналогичных типах поставщиков, и не думаю, что он актуален, например. для домена, размещенного на физическом сервере (или виртуальной машине на собственном KVM / Xen / ESXi) хосте.
В контексте Heroku вы не контролируете, где запускается ваша служба, и Heroku хочет гибкости, позволяющей перемещать вещи без нарушения клиентских систем. Для этого имеет смысл их модельное использование записей CNAME.
Для других систем вы должны учитывать, выиграет ли ваша среда от гибкости, предлагаемой схемой именования DNS, предложенной ими.
Аргумент, который они приводят, заключается в том, что использование CNAME позволяет другому объекту (им) обновлять используемые адреса без вашего участия.
Это законный случай для этого, но на самом деле это не имеет ничего общего с масштабируемостью или облачностью. Вашему провайдеру полезно иметь возможность перемещать свои серверы по разным адресам, не заставляя своих клиентов обновлять все записи A .
Вот и все. В статье, кажется, пытаются объединить это с добавлением неотъемлемой устойчивости, в частности, со ссылкой на «массивные локальные центры обработки данных», что вообще не имеет смысла.
Примечание. обойти проблему с помощью записи DNSSimple «Псевдоним» - подробнее см. на http://blog.dnsimple.com/introduction-the-alias-record/ - это их собственное расширение DNS, которое обходит проблема, если вы используете их для своего DNS-хостинга.
Вашему провайдеру выгодно иметь возможность перемещать свои серверы по разным адресам, не заставляя своих клиентов обновлять все записи A.
Мне это кажется хорошей причиной, достаточно хорош, чтобы НЕ использовать записи A и придерживаться CNAME, когда это возможно в облачных сервисах, включая heroku, особенно если ваша запись имеет большой TTL.
Вот интересная статья об этом (от явно фаната heroku, но она объясняет ситуация неплохая): http://neilmiddleton.com/the-dangers-of-a-records-and-heroku/