Я работаю над сайтом, который я хотел бы обслуживать из голого домена, такого как foo.com, и обслуживать его из AWS S3 ».
Однако документацию, которую я могу найти с помощью AWS у меня сложилось впечатление, что если я хочу это сделать, мне нужно будет переместить весь мой DNS на Amazon Route53.
Я бы предпочел не делать этого, но поскольку я не могу использовать CNAMES для голых доменов, а также точечные A-записи указывают на фиксированный IP-адрес (потому что они могут измениться), я не уверен, какие у меня есть варианты.
Это возможно только делегировать обслуживание голого домена другому провайдеру без необходимости перемещать все по другому?
Я вижу подобные фрагменты в документации AWS, которые я мог бы добавить в свой DNS с помощью Gandi, но я понимаю, что это делегирует все обработка домена на серверы имен Amazon, чего я не думаю.
foo.com. 172800 IN NS ns-9999.awsdns-99.com.
Если мой провайдер, Gandi, не поддерживает записи ALIAS или ANAME, какие у меня варианты?
Я понимаю, что могу развернуть экземпляр на IP-адресе, на который я указываю, с записью A, а затем использовать его для возврата запросов с голого домена на статический сайт, размещенный на www.foo.com, но есть ли другие варианты, но это кажется, что это нарушит цель статического обслуживания, поэтому, кроме использования такого поставщика, как Cloudflare, или wwwizer, кто обрабатывает голый домен за вас, что еще вы можете сделать?
DNS - это иерархическая система, которая просто не обеспечивает механизма для делегирования только верхней записи зоны в другое место.
Самым простым решением является перенос вашего DNS-хостинга на Route 53, поскольку записи псевдонимов в Route 53 решают проблему, используя внутренние знания Route 53 о содержимом доменов S3 (а также для ELB и CloudFront), чтобы вернуть правильный ответ A-записи на ваш запрос. (Псевдоним - это не тип записи DNS, это директива конфигурации.)
У меня нет особых причин сопротивляться такому изменению - вам не нужно менять регистратор на Route 53 (хотя вы можете), вам нужно только сменить авторитетные серверы имен с вашим текущим регистратором. Вы можете продолжать использовать текущего регистратора для ежегодного продления и любых других бонусов / пакетов, которые они предоставляют ... только не для самого DNS-хостинга.
Другие поставщики достигают подобной функциональности, проксируя входящий DNS-запрос к месту назначения «из спины», отыскивая цель и возвращая соответствующие части ответа исходной запрашивающей стороне.
Вот что делает Cloudflare с "выравниванием CNAME" -
Сервер CloudFlare [DNS], генерирующий ответ, следует цепочке CNAME, так что ответ на запрос от клиента (например, браузера) содержит только данные, отличные от CNAME - обычно это IP-адрес. Это фактически создает запись A или AAAA.
Использование веб-прокси-сервера со статическим IP-адресом и записью A является жизнеспособным вариантом и, на самом деле, неплохим вариантом, если вы хотите обслуживать свой сайт с помощью сертификата SSL (S3 не поддерживает SSL для пользовательские домены). Если прокси-сервер находится в том же регионе AWS, что и корзина, дополнительные расходы на транспортировку данных отсутствуют, и прокси-сервер на данном оборудовании, безусловно, может обслуживать больше контента, чем реальный веб-сервер на том же оборудовании, поскольку существует нет доступа к диску. (На одной из таких установок, t2 micro, работающем под управлением haproxy, вчера я обслужил 891 683 веб-запроса, не нагружая ЦП на 5% на одноминутном графике CloudWatch). Конечно, это приводит к дополнительным затратам и проблемам с доступностью.
Но волшебных пуль нет.