LA CONFIGURACIÓN
Tenemos un sistema de gestión de sitios web similar a webs/wix/etc que estamos intentando utilizar con CloudFront. Tiene los siguientes dominios y subdominios.
- nuestrodominio: nuestro sitio web principal
- admin.nuestrodominio: la interfaz de administración para cada sitio web, disponible a través de https
- imágenes.nuestrodominio: un depósito S3
- enrutador.nuestrodominio: consulte a continuación
- [algodelcliente].nuestrodominio: los subdominios para nuestros usuarios gratuitos
- [customersomething.com]: dominios para nuestros clientes premium
El sistema funciona de una manera en la que la mayoría de los dominios tienen CNAME-d para router.ourdomain (porque esa era la forma más fácil para nuestros clientes con sus diferentes registradores de dominio y demás) y router.ourdomain tiene un alias A para nuestro ELB y luego PHP en nuestros EC2-s manejan los sitios según los valores HTTP_HOST, mientras que las imágenes provienen de S3.
NUESTRO PLAN
Y ahora queremos poner todo esto detrás de un CloudFront. La mayoría de las cosas son triviales. Fue fácil poner el S3 detrás del CF. Fue fácil poner cada nuestrodominio/*.(js|css) detrás de CF a través de un subdominio active.ourdomain. Es un placer que podamos usar *.images.ourdomain para fragmentar entre subdominios sobre la marcha, disminuyendo el tiempo de carga del lado del cliente, etc. Incluso podríamos poner todos los elementos *.ourdomain, incluidos los sitios dinámicos gratuitos de PHP, detrás de CF poniendo "*.ourdomain" en los parámetros CF.
EL PROBLEMA
Pero lo único que no podemos entender es cómo poner todos los sitios PHP creados dinámicamente con dominios personalizados detrás de CF. Como recordatorio: estos son CNAME-d para router.ourdomain. Poner cada dominio en los parámetros CF no es una opción, ya que necesitamos poder manejar decenas de miles de nombres de dominio y debemos hacerlo sin configuración manual para cada uno de ellos.
Así que pensamos que deberíamos poner router.ourdomain en la configuración CF como nombre de dominio alternativo, apuntar router.ourdomain al CF en la ruta 53 y apuntar el CF a nuestro ELB como origen. Descubrimos que es una buena forma de recibir este mensaje cada vez: "ERROR No se pudo satisfacer la solicitud. Solicitud incorrecta. Generada por cloudfront (CloudFront)". De hechono todostiempo, como elwww.ourdomain funciona como debería (tiene un CNAME para router.ourdomain), pero todos los demás subdominios dan el error anterior (*.ourdomain tiene un CNAME para router.ourdomain, pero ocurre lo mismo incluso para aquellos subdominios que tienen CNAME para router. nuestro dominio uno por uno, excepto el www, y por supuesto el router). Entonces, en este momento no solo no tenemos idea de cómo deberíamos resolver esto, ni siquiera entendemos por qué funciona para www si no funciona para todos los demás o viceversa.
Cualquier pensamiento e idea sería apreciado, gracias.
Respuesta1
Como recordatorio: estos son CNAME-d para router.ourdomain
Sí, mencionaste eso. Esto es lo que pasa con eso:
No importa.
Sí, CloudFront se refiere a los nombres de host alternativos como CNAME. Sí, un registro DNS CNAME es la forma típica en que enrutaría el tráfico de un sitio determinado para llegar a CloudFront. Pero no, haber configurado un nombre de host como CNAME que apunte a su distribución de CloudFront no es relevante ahora que Cloudfront, o HTTP en general, funciona.
Cuando un navegador quiere conectarse a un servidor web, busca la dirección IP en el DNS. Si hay un CNAME en la ruta, esa información se descarta. Lo único que le importa al navegador es "¿a qué dirección IP me conecto?"
Digamos que www.example.org era un CNAME para webfarm.example.com. El navegador busca www.example.org y termina con la dirección IP de webfarm.example.com.
Con la respuesta en mano, el navegador establece una conexión con el servidor web y envía una solicitud.
GET / HTTP/1.1
Host: www.example.com
El Host:encabezado de la solicitud http enviada por el navegador contiene el nombre de host como se muestra en la barra de direcciones. La información CNAME no está disponible en absoluto y es desconocida para el navegador o el servidor web.
Entonces, ¿cómo sería relevante el CNAME para solicitar el análisis y el enrutamiento de capa 7? No puede ser. El destino CNAME solo se utiliza como ruta para encontrar la dirección IP con la que conectarse.
Su distribución no es la única que utiliza esas direcciones IP en Cloudfront. Hay cientos o miles de otros. Todo se reduce al Host:encabezado.
La lista de "CNAME" (nombres de host alternativos) es un conjunto de nombres de host que CloudFront debe hacer coincidir, en el Host:encabezado entrante, para determinar que una solicitud debe considerarse como perteneciente asudistribución. Es una lista de Host:encabezados que puede enviar un navegador. Hasta que el Host:encabezado coincida con un valor configurado en una distribución, la distribución asociada con esa solicitud es desconocida e indefinida.
¿Qué hace Cloudfront si no puede hacer coincidir un Host:encabezado entrante con ninguna distribución?
HTTP/1.1 400 Bad Request
Entonces, el comportamiento que ve es el esperado y correcto. Los comodines funcionan, en la configuración de CloudFront, siempre que constituyan el único elemento situado más a la izquierda en la línea de configuración del nombre de host alternativo. Pero esto no tiene nada que ver con el DNS.
No puede evitar configurar otros nombres de dominio propiedad del cliente en CloudFront si desea que se sumen a su distribución.
Sin embargo, puedes modificarlos mediante programación a través de la API, en lugar de hacerlo manualmente:
http://docs.aws.amazon.com/AmazonCloudFront/latest/APIReference/PutConfig.html
Hay un límite de 100 alias por distribución, pero puede solicitar un aumento enviando un formulario al soporte de AWS. En verdad, sin embargo, sería mejor dividirlas en múltiples distribuciones, porque CloudFront no almacenará en caché el objeto en una ruta determinada con un host en los esders de solicitud y lo devolverá como una respuesta en caché para otro diferente. host, incluso en la misma distribución, si está reenviando el encabezado del host al servidor de origen (lo cual debe hacer, para que el servidor de origen pueda notar la diferencia). No puede, porque un parámetro importante en la solicitud ha cambiado de una solicitud a otra.