Join Log in
Score:0
Darragh avatar Server

Why is AWS Route 53 / Application Load balancer resolving a multilevel subdomain

ru flag
Darragh

Within AWS I terminate TLS at an Application Load Balancer. I have configured a wildcard TLS certificate with AWS' Certificate Manager (ACM), e.g. *.example.com. I have AWS Route 53 resolving *.example.com, but I have nothing for *.*.example.com as I have no need for this.

I know you can't configure wildcard certificates for multi-level domains such as *.*.example.com.

https://x.example.com is all good and responds with a valid certificate. I get a certificate error with https://y.x.example.com, which makes sense. I have no need to serve multi-level subdomains such as *.*.example.com.

I would like to be able to block all multi-level domain requests such as https://y.x.example.com or just not have Route 53 resolving. Basically I want a Rule that says any host for https://*.*.example.com return 404 or for the Host not to be resolved.

In the application load balancer I have 2 listeners port 80 and port 443.

I can configure a rule for the port 80 listener which works fine for http://x.y.example.com and I can return a 404, when I configure the same rule for port 443 it does not work. Which I guess makes sense because the browser can't complete the TLS handshake.

If I complete an nslookup for x.example.com and y.x.example.com I get the same NameServers, I won't have expected Route 53 to resolve y.x.example.com.

So, I am looking for the answer to one of two questions:

  1. How does one configure AWS Load balancer to block all wildcard multi-level subdomains on Port 443?
  2. Why is Route 53 resolving y.x.example.com/ how to stop Route 53 resolving same?
184
1 + 0
Score:0
avatar Server
cn flag
Håkan Lindqvist

  1. If this is about the HTTPS/TLS case specifically, I do not see this being possible in any meaningful way.
    If you don't have a valid certificate for the name that the client is trying to connect to, you do not have the means to send a valid response (like the 404 response mentioned in the question) in the first place, regardless the configuration on the server side.
    For the plain HTTP case, it may be possible to do something like what was asked for based on a Host condition, but I am not sure that it's actually possible to distinguish the single-level vs multi-level case there. I am not sure that the plain HTTP case is that interesting these days anyway, though.

  2. This is how wildcards work in DNS. Looking up a DNS name that is not part of an existing branch of the tree (regardless if one or more labels are missing) will match a wildcard record above it.
    It is also worth noting that * only works as a wildcard when it is the left-most label. *.example.com works as a wildcard, *.foo.example.com works as a wildcard, but foo.*.example.com, foo*.example.com or *foo.example.com are not wildcards in DNS.
    I do not believe you have a practical way of using wildcards while getting the "only one level" functionality that you are asking for (with DNS wildcards in general or Route53 specifically). Consider instead adding the specific names that you actually need (dynamically if need be), or otherwise live with the normal wildcard behavior.

Overall, I suspect that the best option is to not use wildcards in DNS, and then not have the problem of clients connecting to the ELB using these undesired names.

0 + 1
Patrick Mevzek avatar
cn flag
Patrick Mevzek
+1 on "the best option is to not use wildcards in DNS". They often create more problems than solutions. They were created at a time where DNS was only text files without any kind of automation or provisioning tools. Nowadays there are many other possibilities to configure "dynamically" nameservers, without having to rely on wildcards. Wildcards can be used, if understood correctly, of course, they are fully described. Yet they make everything more complex, starting with DNSSEC.
0
Reply
ธงชาติไทย
Elon Musk
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.