Почему AWS Route 53 / Application Load Balancer разрешает многоуровневый поддомен

Question

В AWS я завершаю TLS на Application Load Balancer. Я настроил wildcard TLS-сертификат с помощью AWS Certificate Manager (ACM), например, *.example.com.у меня есть разрешение AWS Route 53 *.example.com, но у меня нет ничего для, *.*.example.comтак как мне это не нужно.

Я знаю, что нельзя настроить подстановочные сертификаты для многоуровневых доменов, таких как *.*.example.com.

https://x.example.comвсе хорошо и отвечает действительным сертификатом. Я получаю ошибку сертификата с https://y.x.example.com, что имеет смысл. Мне не нужно обслуживать многоуровневые поддомены, такие как *.*.example.com.

Я хотел бы иметь возможность блокировать все запросы многоуровневых доменов, такие как https://y.x.example.comили просто не разрешать Route 53. По сути, я хочу правило, которое говорит, что любой хост должен https://*.*.example.comвозвращать 404 или не разрешать хост.

В балансировщике нагрузки приложения у меня есть 2 прослушивателя: порт 80 и порт 443.

Я могу настроить правило для прослушивателя порта 80, которое отлично работает, http://x.y.example.comи я могу вернуть 404, когда я настраиваю то же самое правило для порта 443, оно не работает. Что, я думаю, имеет смысл, поскольку браузер не может завершить рукопожатие TLS.

Если я выполню nslookupfor x.example.comи y.x.example.comполучу те же NameServers, я не буду ожидать, что Route 53 разрешит y.x.example.com.

Итак, я ищу ответ на один из двух вопросов:

1. Как настроить балансировщик нагрузки AWS для блокировки всех подстановочных многоуровневых поддоменов на порту 443?
2. Почему Route 53 разрешается y.x.example.com/ как остановить разрешение Route 53?

Answer 1

1. Если это касается конкретно случая HTTPS/TLS, я не вижу, чтобы это было возможно каким-либо осмысленным образом.
   Если у вас нет действительного сертификата для имени, к которому клиент пытается подключиться, у вас нет средств отправить действительный ответ (например, ответ 404, упомянутый в вопросе) в первую очередь, независимо от конфигурации на стороне сервера.
   Для простого случая HTTP, возможно, можно сделать что-то вроде того, что было запрошено на основеСостояние хозяина, но я не уверен, что там вообще можно отличить одноуровневый случай от многоуровневого. Я не уверен, что простой HTTP-случай в наши дни так уж интересен.

2. Вот как работают подстановочные знаки в DNS. Поиск имени DNS, которое не является частью существующей ветви дерева (независимо от того, отсутствуют ли одна или несколько меток), сопоставит запись подстановочного знака над ним.
   Также стоит отметить, что *работает как подстановочный знак, только когда это самая левая метка. *.example.comработает как подстановочный знак, *.foo.example.comработает как подстановочный знак, но foo.*.example.com, foo*.example.comили *foo.example.comне являются подстановочными знаками в DNS.
   Я не верю, что у вас есть практичный способ использования подстановочных знаков, получая при этом функциональность «только одного уровня», о которой вы просите (с подстановочными знаками DNS в целом или Route53 в частности). Рассмотрите вместо этого добавление конкретных имен, которые вам действительно нужны (динамически, если это необходимо), или в противном случае живите с обычным поведением подстановочных знаков.

В целом я подозреваю, что наилучшим вариантом будет не использовать подстановочные знаки в DNS, и тогда не возникнет проблем с подключением клиентов к ELB, используя эти нежелательные имена.