Warum löst AWS Route 53 / Application Load Balancer eine mehrstufige Subdomäne auf?

Question

Innerhalb von AWS beende ich TLS bei einem Application Load Balancer. Ich habe ein Wildcard-TLS-Zertifikat mit dem Certificate Manager (ACM) von AWS konfiguriert, z. B. *.example.com.habe ich AWS Route 53-Auflösung *.example.com, aber ich habe nichts dafür, *.*.example.comda ich das nicht brauche.

Ich weiß, dass Sie für Multi-Level-Domains wie keine Wildcard-Zertifikate konfigurieren können *.*.example.com.

https://x.example.comist alles in Ordnung und antwortet mit einem gültigen Zertifikat. Ich erhalte einen Zertifikatsfehler mit https://y.x.example.com, was Sinn macht. Ich muss keine mehrstufigen Subdomains wie bedienen *.*.example.com.

Ich möchte alle Multi-Level-Domain-Anfragen blockieren können https://y.x.example.comoder einfach keine Route 53-Auflösung haben. Grundsätzlich möchte ich eine Regel, die besagt, dass jeder Host https://*.*.example.com404 zurückgibt oder dass der Host nicht aufgelöst werden soll.

Im Anwendungslastenausgleich habe ich zwei Listener, Port 80 und Port 443.

Ich kann eine Regel für den Port-80-Listener konfigurieren, die gut funktioniert, http://x.y.example.comund ich kann eine 404 zurückgeben. Wenn ich dieselbe Regel für Port 443 konfiguriere, funktioniert sie nicht. Was wohl Sinn macht, da der Browser den TLS-Handshake nicht abschließen kann.

nslookupWenn ich ein for abschließe x.example.comund y.x.example.comdieselben Nameserver erhalte, habe ich nicht damit gerechnet, dass Route 53 auflöst y.x.example.com.

Ich suche nach der Antwort auf eine von zwei Fragen:

1. Wie konfiguriert man den AWS Load Balancer, um alle Wildcard-Multilevel-Subdomains auf Port 443 zu blockieren?
2. Warum wird Route 53 aufgelöst y.x.example.combzw. wie kann die Auflösung von Route 53 gestoppt werden?

Answer 1

1. Wenn es hier speziell um den HTTPS/TLS-Fall geht, sehe ich keine sinnvolle Möglichkeit dafür.
   Wenn Sie kein gültiges Zertifikat für den Namen haben, mit dem der Client eine Verbindung herstellen möchte, haben Sie unabhängig von der Konfiguration auf der Serverseite überhaupt keine Möglichkeit, eine gültige Antwort (wie die in der Frage erwähnte 404-Antwort) zu senden.
   Für den einfachen HTTP-Fall ist es möglicherweise möglich, etwas zu tun, wie es verlangt wurde, basierend auf einemHost-Bedingung, aber ich bin nicht sicher, ob es hier tatsächlich möglich ist, zwischen einstufigem und mehrstufigem Fall zu unterscheiden. Ich bin mir allerdings nicht sicher, ob der reine HTTP-Fall heutzutage überhaupt noch so interessant ist.

2. So funktionieren Platzhalter in DNS. Wenn Sie nach einem DNS-Namen suchen, der nicht Teil eines vorhandenen Zweigs des Baums ist (unabhängig davon, ob ein oder mehrere Labels fehlen), wird ein Platzhalterdatensatz darüber gefunden.
   Es ist auch erwähnenswert, dass *nur als Platzhalter funktioniert, wenn es sich um das Label ganz links handelt. *.example.comfunktioniert als Platzhalter, *.foo.example.comfunktioniert als Platzhalter, aber foo.*.example.comoder foo*.example.comsind *foo.example.comkeine Platzhalter in DNS.
   Ich glaube nicht, dass Sie eine praktische Möglichkeit haben, Platzhalter zu verwenden und gleichzeitig die von Ihnen gewünschte „nur eine Ebene“-Funktionalität zu erhalten (mit DNS-Platzhaltern im Allgemeinen oder Route53 im Besonderen). Erwägen Sie stattdessen, die spezifischen Namen hinzuzufügen, die Sie tatsächlich benötigen (dynamisch, falls erforderlich), oder leben Sie andernfalls mit dem normalen Platzhalterverhalten.

Insgesamt vermute ich, dass die beste Option darin besteht, im DNS keine Platzhalter zu verwenden. So entsteht nicht das Problem, dass Clients mit diesen unerwünschten Namen eine Verbindung zum ELB herstellen.