Servindo um site estático S3 a partir de um domínio simples, sem migrar para AWS Route53

Servindo um site estático S3 a partir de um domínio simples, sem migrar para AWS Route53

Estou trabalhando em um site que gostaria de servir a partir de um domínio simples, como foo.com, e a partir do AWS S3 '.

No entanto, odocumentação que posso encontrar na AWSme deu a impressão de que, se eu quiser fazer isso, precisarei mover todo o meu DNS para o Route53 da Amazon.

Prefiro não fazer isso, mas como não posso usar CNAMES para domínios nus, nem registros de ponto A apontam para um IP fixo (porque eles podem mudar), não tenho certeza de quais são minhas opções.

é possívelapenas delegar a veiculação de um domínio sem www a outro provedor, sem precisar transferir tudo?

Vejo trechos como este nos documentos da AWS, que eu poderia adicionar ao meu DNS com Gandi, mas entendo que isso delegariatodosmanipulação de domínio para os servidores Amazon Name, o que acho que não quero.

foo.com. 172800 IN NS ns-9999.awsdns-99.com.

Se meu provedor, Gandi, não oferece suporte a registros ALIAS ou ANAME, quais são minhas opções?

Entendo que poderia ativar uma instância em um IP para o qual aponto com um registro A e, em seguida, usá-lo para devolver solicitações do domínio simples para um site estático hospedado em www.foo.com, mas existem outras opções, mas esta parece que isso iria anular o propósito de ter veiculação estática, além de usar um provedor comonuvemflare, ouwwwizer, que cuida da brincadeira de domínio nu para você, o que mais você pode fazer?

Responder1

O DNS é um sistema hierárquico e simplesmente não fornece um mecanismo para delegar apenas o registro ápice de uma zona em outro lugar.

A solução mais direta é mover sua hospedagem DNS para o Route 53, porque os registros de alias no Route 53 resolvem o problema usando o conhecimento interno do Route 53 sobre o conteúdo dos domínios do S3 (bem como aqueles do ELB e do CloudFront) para retornar um resposta correta do registro A à sua consulta. (Um Alias ​​não é um tipo de registro DNS, é uma diretiva de configuração.)

Há poucas razões que eu possa imaginar para resistir a tal mudança - você não precisa mudar seuregistradorpara o Route 53 (embora seja possível), você só precisa alterar seus servidores de nomes autorizados com seu registrador atual. Você pode continuar a usar o registrador atual para suas renovações anuais e quaisquer outros bônus/pacotes que eles oferecem... mas não para a hospedagem DNS em si.

Outros provedores conseguem a aparência de funcionalidade semelhante ao fazer proxy da solicitação de DNS recebida para um destino "nos fundos", procurando o alvo e retornando as partes apropriadas da resposta ao solicitante original.

É isso que a Cloudflare faz, com o “achatamento CNAME” –

O servidor CloudFlare [DNS] que gera a resposta segue a cadeia CNAME para que a resposta à solicitação do cliente (por exemplo, o navegador) contenha apenas dados não-CNAME – geralmente, um endereço IP. Isso efetivamente cria um registro A ou AAAA.

https://support.cloudflare.com/hc/en-us/articles/200169056-CNAME-Flattening-RFC-compatível-support-for-CNAME-at-the-root

Usar um servidor proxy web, com um endereço IP estático e um registro A é uma opção viável - e, na verdade, não é ruim se você deseja servir seu site com um certificado SSL (S3 não suporta SSL para domínios personalizados). Se o proxy estiver na mesma região da AWS que o bucket, não haverá nenhuma cobrança adicional de transporte de dados, e um proxy em uma determinada peça de hardware certamente poderá fornecer mais conteúdo do que um servidor web real no mesmo hardware, já que há sem acesso ao disco. (Em uma dessas configurações, um micro t2, executando haproxy, atendi 891.683 solicitações da web ontem sem nunca atingir 5% da CPU no gráfico CloudWatch de um minuto). É claro que isso introduz custos adicionais e problemas de disponibilidade.

Mas não existem soluções mágicas.

informação relacionada