A CONFIGURAÇÃO
Temos um sistema de gerenciamento de sites semelhante ao webs/wix/etc que estamos tentando usar com o CloudFront. Possui os seguintes domínios e subdomínios.
- ourdomain: nosso site principal
- admin.ourdomain: a interface de administração de cada site, disponível através de https
- images.ourdomain: um bucket S3
- router.ourdomain: veja abaixo
- [customersomething].ourdomain: os subdomínios para nossos usuários gratuitos
- [customersomething.com]: domínios para nossos clientes premium
O sistema funciona de uma forma em que a maioria dos domínios são CNAME-d para router.ourdomain (porque essa era a maneira mais fácil para nossos clientes com seus diferentes registradores de domínio e outros) e o router.ourdomain tem o alias A para nosso ELB e, em seguida, o PHP em nossos EC2-s estão manipulando os sites com base nos valores HTTP_HOST, enquanto as imagens vêm do S3.
NOSSO PLANO
E agora queremos colocar tudo isso atrás de um CloudFront. A maior parte das coisas é trivial. Foi fácil colocar o S3 atrás do CF. Foi fácil colocar cada ourdomain/*.(js|css) atrás de CF por meio de um subdomínio asset.ourdomain. É uma alegria podermos usar *.images.ourdomain para fragmentar entre subdomínios em tempo real, diminuindo o tempo de carregamento do cliente, etc. nos parâmetros CF.
O PROBLEMA
Mas a única coisa que não conseguimos descobrir é como colocar todos os sites PHP criados dinamicamente com domínios personalizados atrás do CF. Como um lembrete: estes são CNAME-d para router.ourdomain. Colocar cada domínio nos parâmetros CF não é uma opção, pois precisamos ser capazes de lidar com dezenas de milhares de nomes de domínio, e precisamos fazer isso sem configuração manual para cada um deles.
Portanto, pensamos que deveríamos colocar router.ourdomain na configuração do CF como nome de domínio alternativo, apontar o router.ourdomain para o CF na rota 53 e apontar o CF para o nosso ELB como origem. O que descobrimos é uma ótima maneira de receber sempre esta mensagem: "ERRO A solicitação não pôde ser atendida. Solicitação incorreta. Gerada pelo cloudfront (CloudFront)". Na verdadenem todotempo, como owww.ourdomain funciona como deveria (é CNAMEd para router.ourdomain), mas todos os outros subdomínios apresentam o erro acima (*.ourdomain é CNAMEd para router.ourdomain, mas é o mesmo até mesmo para os subdomínios que são CNAMEd para roteador. nossodomínio um por um, exceto o www e, claro, o roteador). Então, no momento, não temos ideia de como devemos resolver isso, nem entendemos por que funciona para www se não funciona para todos os outros ou vice-versa.
Quaisquer pensamentos e ideias serão apreciados, obrigado.
Responder1
Como um lembrete: estes são CNAME-d para router.ourdomain
Sim, você mencionou isso. Aqui está o problema:
Não importa.
Sim, o CloudFront refere-se a nomes de host alternativos como CNAMEs. Sim, um registro DNS CNAME é a maneira típica de rotear o tráfego de um determinado site para atingir o CloudFront. Mas não, ter configurado um nome de host como um CNAME apontando para sua distribuição do CloudFront não é relevante para o funcionamento atual do Cloudfront, ou HTTP em geral.
Quando um navegador deseja se conectar a um servidor web, ele procura o endereço IP no DNS. Se houver um CNAME no caminho, essa informação será descartada. Tudo o que importa ao navegador é "a qual endereço IP eu me conecto?"
Digamos que www.example.org seja um CNAME para webfarm.example.com. O navegador procura www.example.org e termina com o endereço IP de webfarm.example.com.
Com a resposta em mãos, o navegador estabelece uma conexão com o servidor web e envia uma solicitação.
GET / HTTP/1.1
Host: www.example.com
O Host:cabeçalho da solicitação http enviada pelo navegador contém o nome do host conforme mostrado na barra de endereço. As informações CNAME estão completamente indisponíveis e desconhecidas para o navegador ou para o servidor web.
Então, como o CNAME seria relevante para solicitar análise e roteamento da camada 7? Não pode ser. O destino CNAME é usado apenas como um caminho para encontrar o endereço IP ao qual se conectar.
Sua distribuição não é a única que usa esses endereços IP no Cloudfront. Existem centenas ou milhares de outros. Tudo se resume ao Host:cabeçalho.
A lista de "CNAMEs" (nomes de host alternativos) é um conjunto de nomes de host que o CloudFront deve combinar, no Host:cabeçalho de entrada, para determinar se uma solicitação deve ser considerada como pertencente aseudistribuição. É uma lista de Host:cabeçalhos que um navegador pode enviar. Até que o Host:cabeçalho seja correspondido com um valor configurado em uma distribuição, a distribuição associada a essa solicitação é desconhecida e indefinida.
O que o Cloudfront faz se não conseguir corresponder um Host:cabeçalho de entrada a nenhuma distribuição?
HTTP/1.1 400 Bad Request
Portanto, o comportamento que você vê é esperado e correto. Os curingas funcionam na configuração do CloudFront, desde que constituam o único elemento mais à esquerda na linha de configuração do nome de host alternativo. Mas isso não tem nada a ver com o DNS.
Você não pode evitar a configuração de outros nomes de domínio de propriedade do cliente no CloudFront se quiser que eles acompanhem sua distribuição.
No entanto, você pode modificá-los programaticamente por meio da API, em vez de manualmente:
http://docs.aws.amazon.com/AmazonCloudFront/latest/APIReference/PutConfig.html
Há um limite de 100 desses aliases por distribuição, mas você pode solicitar um aumento enviando um formulário para o suporte da AWS. Na verdade, porém, seria bom dividi-los em várias distribuições, porque o CloudFront não armazenará em cache o objeto em um determinado caminho com um host na solicitação esders e o retornará como uma resposta em cache para um diferente host, mesmo na mesma distribuição, se você estiver encaminhando o cabeçalho do host para o servidor de origem (o que você deve fazer, se o servidor de origem quiser saber a diferença). Não é possível, porque um parâmetro significativo na solicitação foi alterado de uma solicitação para outra.