Como configurar o AWS Cloudfront para um número dinâmico de domínios para um site dinâmico?

Question

A CONFIGURAÇÃO
Temos um sistema de gerenciamento de sites web / wix / etc que estamos tentando usar com o CloudFront. Tem os seguintes domínios e subdomínios.
 - ourdomain: nosso site principal
 - admin.ourdomain: a interface de administração para cada site, disponível através de https
 - images.ourdomain: um balde S3
 - router.ourdomain: veja abaixo -  - [customersomething] .domínio: os subdomínios dos nossos usuários gratuitos
 - [customersomething.com]: domínios para nossos clientes premium

O sistema funciona de certa forma, onde a maioria dos domínios são CNAME-d para router.ourdomain (porque essa era a maneira mais fácil para os nossos clientes com diferentes registradores de domínio e tal) e o router.ourdomain é A- alias ao nosso ELB, e então o PHP em nosso EC2-s está manipulando os sites baseados nos valores HTTP_HOST, enquanto as imagens vindas do S3.

NOSSO PLANO
E agora queremos colocar todo esse material por trás de um CloudFront. A maioria das coisas é trivial. Foi fácil colocar o S3 atrás do CF. Era fácil colocar cada ourdomain / *. (Js | css) atrás de CF através de um subdomínio asset.ourdomain. É uma alegria que podemos usar * .temourdomain para dividir entre subdomínios na mosca diminuindo clientide loadtime etc etc. Nós até poderíamos colocar todas as coisas * .domínio incluindo o dyanamic PHP sites gratuitos por trás do CF, colocando "*. Ourdomain" nos parâmetros do CF.

O PROBLEMA
Mas a única coisa que não podemos descobrir é como colocar todos os sites PHP criados dinamicamente com domínios personalizados atrás do CF. Como lembrete: estes são CNAME-d para router.ourdomain. Colocar cada domínio nos parâmetros do 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.

Então, nosso pensamento era que deveríamos colocar router.ourdomain na configuração CF como nome de domínio alternativo, apontar o router.ourdomain para o CF na rota 53 e apontar o CF para nosso ELB como origem. O que descobrimos é uma ótima maneira de obter essa mensagem toda vez: "ERRO A solicitação não pôde ser atendida. Solicitação incorreta. Gerada pelo cloudfront (CloudFront)". Na verdade, não todo tempo, como o www .ourdomain funciona como deveria (é CNAMEd para router.ourdomain), mas todos os outros subdomínios fornecem o erro acima (* .domínio é CNAMEd para router.ourdomain, mas é o mesmo para os subdomínios que são CNAMEd para router.ourdomain um por um, exceto o www e, claro, o roteador). Então, agora nós não apenas não temos idéia de como devemos resolver isso, nem sequer entendemos, por que funciona para o www, se não funciona para todos os outros ou vice-versa.

Quaisquer pensamentos e ideias seriam apreciados, obrigado.

    

Answer 1

As a reminder: these are CNAME-d to router.ourdomain

Sim, você mencionou isso. Aqui está a coisa sobre isso:

Não importa.

Sim, o CloudFront se refere a nomes de host alternativos como CNAMEs. Sim, um registro CNAME DNS é a maneira típica de direcionar o tráfego de determinado site para atingir o CloudFront. Mas não, ter configurado um nome de host como um CNAME apontando para a sua distribuição do CloudFront não é relevante, pois agora o Cloudfront, ou o HTTP em geral, funciona.

Quando um navegador deseja se conectar a um servidor da Web, ele procura o endereço IP do DNS. Se houver um CNAME no caminho, essa informação será descartada. Todo o navegador se preocupa com "qual endereço IP eu conecto?"

Digamos que www.example.org seja um CNAME para webfarm.example.com. O navegador pesquisa www.example.org e termina com o endereço IP para webfarm.example.com.

Com a resposta em mãos, o navegador estabelece uma conexão com o servidor da Web e envia uma solicitação.

GET / HTTP/1.1
Host: www.example.com

O cabeçalho Host: na solicitação http enviada pelo navegador contém o nome do host, conforme mostrado na barra de endereço. As informações do CNAME estão completamente indisponíveis e desconhecidas para o navegador ou para o servidor da Web.

Então, como o CNAME seria relevante para solicitar a análise e o roteamento da camada 7? Não pode ser. O destino CNAME é usado apenas como um caminho para encontrar o endereço IP para se conectar.

Sua distribuição não é a única usando esses endereços IP no Cloudfront. Existem centenas ou milhares de outros. Tudo se resume ao cabeçalho Host: .

A lista de "CNAMEs" (nomes de host alternativos) é um conjunto de nomes de host para o CloudFront para combinar, no cabeçalho Host: de entrada, para determinar que uma solicitação deve ser considerada como pertencente a sua distribuição. É uma lista de Host: cabeçalhos que um navegador pode enviar. Até que o cabeçalho Host: seja correspondido com um valor configurado em uma distribuição, a distribuição associada a essa solicitação é desconhecida e indefinida.

O que a Cloudfront faz se não puder corresponder um cabeçalho Host: recebido a qualquer distribuição?

HTTP/1.1 400 Bad Request

Assim, o comportamento que você vê é esperado e correto. Os curingas funcionam na configuração do CloudFront, desde que eles componham o único elemento mais à esquerda na linha de configuração de 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á-las programaticamente por meio da API, em vez de manualmente:

link

Há um limite de 100 aliases por distribuição, mas você pode solicitar um aumento enviando um formulário ao suporte da AWS. Na verdade, no entanto, você também poderia dividi-las em várias distribuições, porque o CloudFront não armazenará em cache o objeto em um determinado caminho com um host nas esders de solicitação e o retornará como uma resposta armazenada 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ê precisa fazer, se o servidor de origem for capaz de dizer a diferença). Não pode, porque um parâmetro significativo na solicitação foi alterado de uma solicitação para outra.