Я работаю над сайтом, который хотел бы обслуживать с голого домена, например foo.com, и обслуживать его с помощью AWS S3.
Однакодокументацию, которую я могу найти в AWSу меня сложилось впечатление, что если я захочу это сделать, мне придется перенести все свои DNS на Route53 Amazon.
Я бы предпочел этого не делать, но поскольку я не могу использовать CNAME для голых доменов, а записи Point A не указывают на фиксированный IP-адрес (потому что они могут измениться), я не уверен, какие у меня есть варианты.
Это возможнотолько делегировать обслуживание «голого» домена другому провайдеру, не перенося при этом все?
Я вижу подобные фрагменты в документации AWS, которые я мог бы добавить в свой DNS с помощью Gandi, но я понимаю, что это делегировало бывсеобработку доменов на серверах имен Amazon, что, как мне кажется, мне не нужно.
foo.com. 172800 IN NS ns-9999.awsdns-99.com.
Если мой провайдер Gandi не поддерживает записи ALIAS или ANAME, какие у меня есть варианты?
Я понимаю, что я мог бы запустить экземпляр на IP-адресе, на который я указываю с помощью записи A, а затем использовать его для перенаправления запросов с голого домена на статический сайт, размещенный на www.foo.com, но есть ли другие варианты? Кажется, что это противоречит цели статического обслуживания, поэтому, кроме как использовать поставщика, напримерКлаудфлер, илиwwwizer, кто занимается для вас мошенничеством с голыми доменами, что еще вы можете сделать?
решение1
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% CPU на одноминутном графике CloudWatch). Конечно, это приводит к дополнительным расходам и проблемам с доступностью.
Но волшебных пилюль не существует.