Por que o AWS Route 53 / Application Load Balancer está resolvendo um subdomínio multinível

Question

Na AWS eu encerro o TLS em um Application Load Balancer. Configurei um certificado TLS curinga com o AWS Certificate Manager (ACM), por exemplo, *.example.com.tenho a resolução do AWS Route 53 *.example.com, mas não tenho nada para fazer, *.*.example.compois não preciso disso.

Eu sei que você não pode configurar certificados curinga para domínios de vários níveis, como *.*.example.com.

https://x.example.comestá tudo bem e responde com um certificado válido. Recebo um erro de certificado com https://y.x.example.com, o que faz sentido. Não preciso servir subdomínios de vários níveis, como *.*.example.com.

Gostaria de poder bloquear todas as solicitações de domínio de vários níveis, como https://y.x.example.comou simplesmente não ter a resolução do Route 53. Basicamente eu quero uma Regra que diga qualquer Host para https://*.*.example.comretorno 404 ou para o Host não ser resolvido.

No balanceador de carga do aplicativo, tenho 2 ouvintes, porta 80 e porta 443.

Posso configurar uma regra para o listener da porta 80 que funciona bem http://x.y.example.come posso retornar um 404, quando configuro a mesma regra para a porta 443 ela não funciona. O que acho que faz sentido porque o navegador não consegue concluir o handshake TLS.

Se eu preencher um nslookupfor x.example.come y.x.example.comobtiver os mesmos NameServers, não esperarei que o Route 53 resolvesse y.x.example.com.

Então, estou procurando a resposta para uma de duas perguntas:

1. Como configurar o AWS Load Balancer para bloquear todos os subdomínios curinga de vários níveis na porta 443?
2. Por que o Route 53 está resolvendo y.x.example.com/ como impedir que o Route 53 resolva o mesmo?

Answer 1

1. Se se trata especificamente do caso HTTPS/TLS, não vejo isso sendo possível de forma significativa.
   Se você não tiver um certificado válido para o nome ao qual o cliente está tentando se conectar, você não terá como enviar uma resposta válida (como a resposta 404 mencionada na pergunta), independentemente da configuração no lado do servidor.
   Para o caso HTTP simples, pode ser possível fazer algo parecido com o que foi solicitado com base em umCondição do anfitrião, mas não tenho certeza se é realmente possível distinguir o caso de nível único versus multinível. Não tenho certeza se o caso HTTP simples é tão interessante hoje em dia.

2. É assim que os curingas funcionam no DNS. Procurar um nome DNS que não faça parte de uma ramificação existente da árvore (independentemente de um ou mais rótulos estarem faltando) corresponderá a um registro curinga acima dele.
   É importante notar também que *só funciona como curinga quando é o rótulo mais à esquerda. *.example.comfunciona como curinga, *.foo.example.comfunciona como curinga, mas foo.*.example.com, foo*.example.comou *foo.example.comnão são curingas no DNS.
   Não acredito que você tenha uma maneira prática de usar curingas e obter a funcionalidade de "apenas um nível" solicitada (com curingas DNS em geral ou Route53 especificamente). Considere, em vez disso, adicionar os nomes específicos que você realmente precisa (dinamicamente, se necessário) ou, de outra forma, viver com o comportamento normal do curinga.

No geral, suspeito que a melhor opção seja não usar curingas no DNS e assim não ter o problema de clientes se conectarem ao ELB usando esses nomes indesejados.