¿Por qué AWS Route 53/equilibrador de carga de aplicaciones resuelve un subdominio multinivel?

Question

Dentro de AWS termino TLS en un balanceador de carga de aplicaciones. He configurado un certificado TLS comodín con el Administrador de certificados (ACM) de AWS, por ejemplo, *.example.com.tengo AWS Route 53 resolviendo *.example.com, pero no tengo nada porque *.*.example.comno lo necesito.

Sé que no se pueden configurar certificados comodín para dominios multinivel como *.*.example.com.

https://x.example.comEstá todo bien y responde con un certificado válido. Recibo un error de certificado https://y.x.example.com, lo cual tiene sentido. No necesito ofrecer subdominios de varios niveles como *.*.example.com.

Me gustaría poder bloquear todas las solicitudes de dominio multinivel, como por https://y.x.example.comejemplo que Route 53 no se resuelva. Básicamente, quiero una regla que diga que cualquier host para https://*.*.example.comdevolver 404 o para el host no se resuelva.

En el balanceador de carga de la aplicación tengo 2 oyentes, el puerto 80 y el puerto 443.

Puedo configurar una regla para el oyente del puerto 80 que funciona bien http://x.y.example.comy puedo devolver un 404, cuando configuro la misma regla para el puerto 443 no funciona. Lo cual supongo que tiene sentido porque el navegador no puede completar el protocolo de enlace TLS.

Si completo un nslookupfor x.example.comy y.x.example.comobtengo los mismos NameServers, no esperaba que se resolviera la Ruta 53 y.x.example.com.

Entonces, estoy buscando la respuesta a una de dos preguntas:

1. ¿Cómo se configura el balanceador de carga de AWS para bloquear todos los subdominios multinivel comodín en el puerto 443?
2. ¿Por qué se está resolviendo la Ruta 53 y.x.example.com/cómo evitar que la Ruta 53 se resuelva?

Answer 1

1. Si se trata específicamente del caso HTTPS/TLS, no veo que esto sea posible de ninguna manera significativa.
   Si no tiene un certificado válido para el nombre al que el cliente intenta conectarse, no tiene los medios para enviar una respuesta válida (como la respuesta 404 mencionada en la pregunta) en primer lugar, independientemente de la configuración. en el lado del servidor.
   Para el caso HTTP simple, es posible hacer algo como lo que se solicitó en función de unCondición de anfitrión, pero no estoy seguro de que sea realmente posible distinguir el caso de un solo nivel del de varios niveles allí. Sin embargo, no estoy seguro de que el caso HTTP simple sea tan interesante en estos días.

2. Así funcionan los comodines en DNS. Buscar un nombre DNS que no sea parte de una rama existente del árbol (independientemente de si faltan una o más etiquetas) coincidirá con un registro comodín encima de él.
   También vale la pena señalar que *solo funciona como comodín cuando está en la etiqueta más a la izquierda. *.example.comfunciona como comodín, *.foo.example.comfunciona como comodín, pero foo.*.example.como foo*.example.comno *foo.example.comson comodines en DNS.
   No creo que tenga una forma práctica de utilizar comodines mientras obtiene la funcionalidad de "un solo nivel" que solicita (con comodines DNS en general o Route53 específicamente). En su lugar, considere agregar los nombres específicos que realmente necesita (dinámicamente si es necesario) o vivir con el comportamiento normal de los comodines.

En general, sospecho que la mejor opción es no usar comodines en DNS y así no tener el problema de que los clientes se conecten al ELB usando estos nombres no deseados.