У нас есть "ссылки для перехода", где я работаю, например http://go.mycompany.com/foo который перенаправляет в произвольное место. Он работает на простом приложении Python на Google App Engine, которое отображает ключевое слово => URL.
Я работаю над тем, чтобы они работали «неквалифицированно», так что go / foo приведет вас в то же место. Наш DHCP-сервер предоставляет нам поисковые домены, включая «mycompany.com», так что просто «go» разрешает IP-адрес, и все должно работать.
За исключением того, что это точки входа DNS в Cloudfront, которые мы используем в основном для обновления HTTP до HTTPS. При использовании полного домена Host: HTTP-заголовок проходит через go.mycompany.com, и все в порядке. При использовании просто «go» заголовок Host: проходит просто «go». Несмотря на то, что трафик маршрутизируется на уровне TCP, Cloudfront не знает, что с ним делать.
Исправление должно быть таким простым, как добавление "go" к CNAMES данного дистрибутива CloudFront, чтобы оно выглядело так:
Альтернативные доменные имена (CNAME)
go.mycompany.com
go
Однако это поле в пользовательском интерфейсе не принимает домены с голыми словами. Любой трюк, который можно обойти?
Для этого нет обходного пути, и, как правильно указывает Майкл Хэмптон, в любом случае это плохая практика.
Но что касается того, почему, в частности, это невозможно с CloudFront, причина, по крайней мере, частично в том, что значения альтернативных доменных имен для CloudFront находятся в глобальном пространстве имен. Никакие два дистрибутива CloudFront не могут иметь одинаковое значение в настройках альтернативного доменного имени. Если у меня есть дистрибутив CloudFront с example.com в качестве альтернативного доменного имени, никто другой не сможет настроить то же имя в своем дистрибутиве, пока я не удалю его из своего. Итак, если это мы разрешено, только один дистрибутив в любом месте CloudFront мог отвечать на запросы с Host заголовок установлен на "go" или какое-то другое короткое значение, и, конечно, такой сайт не может иметь сертификат от общедоступного CA, поскольку ни один CA не будет уполномочен выдавать такой сертификат.
Для CNAME? Нет. Вы можете использовать Route53 в качестве хоста зоны и использовать записи псевдонимов, но любой хост DNS, который вы используете, который чего-либо стоит, не разрешит записи Apex CNAME. Из документов Cloudfront по ссылке выше:
Если вы используете Route 53 в качестве службы DNS, вы можете создать набор записей ресурсов псевдонима, который имеет два преимущества перед записями CNAME. Вы можете создать набор записей ресурсов псевдонима для доменного имени на верхнем узле (example.com). Кроме того, когда вы используете набор записей ресурсов псевдонима, вы не платите за запросы Route 53.