Exibição de um site estático do S3 a partir de um domínio sem acesso, sem migrar para o AWS Route53

Question

Estou trabalhando em um site que gostaria de veicular em um domínio desconhecido como o foo.com e exibi-lo no AWS S3 '.

No entanto, a documentação que posso encontrar com a AWS me deu a impressão de que, se eu quiser fazer isso, precisarei mover o DNS todo para o Route53 da Amazon.

Prefiro não fazer isso, mas como não posso usar o CNAMES para domínios nus, nem apontar que os A-records apontam para um IP fixo (porque eles podem mudar), não sei quais são minhas opções.

É possível somente delegar a veiculação de um domínio nu para outro provedor, sem precisar mover tudo?

Eu vejo trechos como este nos documentos da AWS, que eu poderia adicionar ao meu DNS com o Gandi, mas eu entendo que isso delegaria o all gerenciamento de domínio aos servidores Amazon Name, o que eu não acho que quero.

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

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

Eu entendo que poderia transformar uma instância em um IP para o qual eu indico um registro A e, em seguida, usá-la para rejeitar solicitações do domínio nu para uma estática localizada em www.foo.com, mas há outras opções , mas parece que isso acabaria com o propósito de ter uma veiculação estática, portanto, além de usar um provedor como Cloudflare ou wwwizer , que lida com o domínio japonês para você, o que mais você pode fazer?

    

Answer 1

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

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

Há poucas razões pelas quais posso pensar em resistir a essa mudança - você não precisa mudar o seu registrador para o Route 53 (embora você possa), você só precisa mudar sua autoridade servidores de nomes com o seu registrador atual. Você pode continuar a usar o registrador atual para suas renovações anuais e qualquer outro bônus / pacote que eles forneçam ... apenas não para a própria hospedagem DNS.

Outros provedores obtêm a aparência de uma funcionalidade semelhante, fazendo proxy da solicitação de DNS recebida para um destino "out the back", procurando o destino e retornando as partes apropriadas da resposta ao solicitante original.

Isso é o que o Cloudflare faz, com "achatamento CNAME" -

The CloudFlare [DNS] server generating the response follows the CNAME chain so that the response to the request from the client (for example, the browser) contains only non-CNAME data -- usually, an IP address. This effectively creates an A or an AAAA record.

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

Usar um servidor proxy da 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ê quiser veicular seu site com um certificado SSL (o S3 não suporte SSL para domínios personalizados). Se o proxy estiver na mesma região da AWS que o bucket, não haverá cobranças adicionais de transporte de dados, e um proxy em determinado hardware pode certamente fornecer mais conteúdo do que um servidor da Web real no mesmo hardware, já que há sem acesso ao disco. (Em uma dessas configurações, um micro t2, rodando o haproxy, eu atendi 891.683 solicitações da web ontem, sem ter atingido 5% de CPU no gráfico de um minuto do CloudWatch). Claro, isso apresenta um custo adicional e problemas de disponibilidade.

Mas não há balas mágicas.