Route 53 record set not resolving for Elastic Beanstalk instance

Question

I am trying to route a specific subdomain to the url of an Elastic Beanstalk application environment instance. Other routes within that domain are working properly.

My configuration screen for the Route 53 record set looks like this:

I can access the environment using environment.url.elasticbeanstalk.com , but I can't using subdomain.domain.com .

Do you have any clue about what could be going wrong? Maybe something about Elastic Beanstalk Load Balancers or Security Groups?

I found this AWS troubleshooting page. It seems like I am following their configuration properly.

Answer 1

This is in agreement with Nick Brady's answer in item #2, and sonlexqt's answer. .app domains also force https by default. Although i was eventually able to get it to connect via http using an old browser.

For our AWS Route 53 / Elastic Beanstealk deployment, everything DNS related was working fine (host, dig, whois) but the browser wouldn't resolve the url. Curl would work from the command line. Ping wouldn't work but that's common as ICMP is blocked at the firewall by default.

I installed an older browser version and was then able to access the site via URL via that old browser version. With current browser versions, I wasn't even getting that security warning "continue anyway", it just was failing to establish a connection. Continuing the AWS configuration process and getting the https connection set up resolved the issue with browser connectivity.

Answer 2

In my case, I was using a .DEV domain which always requires HTTPS connections and my Elastic Beanstalk application only serves on port 80. I fixed it by letting my application to serve on port 443, too.

Answer 3

Here are a few things to try. I spoke with an AWS support representative and he had extremely helpful feedback. Here is what he had to say:

1. From AWS Support staff - quoting this issue

While some of these values are simply not correct, most of the values are URL's and are not DNS names as it includes "http://". This generally happens due to copying the name from the browser address bar after testing access to the beanstalk application. Although you would have been able to set this up in Route53 you would not have been able to connect to it. You may have seen an error similar to "We can’t connect to the server at test.example.com." When you connect to a web application using its DNS name, the first thing that will happen is DNS resolution. So as an example the domain name "test.example.com." would be resolved to "http://test-env.eba-xxxxxx.us-east-1.elasticbeanstalk.com/ " and this value is then cached in your DNS cache. If you then update the DNS record with the correct value and then try to resolve the same name again "test.example.com" it will get the value from the cache instead of the new value from the name server in your hosted zone. You would then continue to see the error in your browser even though you have now updated the record with the correct value. This Value stays in the cache for the duration set in the TTL(Time to Live)1. Once the TTL expires then your DNS resolver would query the name server in your hosted zone again and get the correct value. Looking at the ChangeResourceRecordSets API calls I can see that the changes were made quite close together. And with default TTL for a CNAME being 300 seconds, i can confirm that this is a very like cause of the issue you experienced. It is therefore recommended to set a low TTL when testing DNS records. Additionally you can also clear your DNS cache or test from different networks. On a Windows machine you can use the command "ipconfig /flushdns" to clear your DNS cache.

2. (From my personal experience) If you're webserver doesn't have HTTPS yet, and you're using a domain you've been to before that had HTTPS before (for me, I was using a domain I commonly use for testing), then the browser might be automatically upgrade your request to HTTPS like mine was which isn't immediately clear (especially with the protocol text being stripped often in the browser's address bar) which will cause issues if you're app is only serving on 80 and you make request to 443. Clear the browsers data to make sure that it doesn't remember old usage and automatically upgrade your request or turn off that upgrading entirely to ensure the request is made over HTTP.

I'm fairly certain I was encountering both issues at the same time which led to this issue being a headache. Somewhat related - my use case had my Route53 domain on a separate account than the elastic beanstalk environment.

Hope this helps

Answer 4

Ok, not sure what happened, but I tried to configure the Record Set again by changing from A-IPv4 address to CNAME with no luck.

Then I changed back to A-IPv4 address and tried to enter again the Alias target to the Elastic Beanstalk environment. When I selected my intended environment environment.url.elasticbeanstalk.com from the list and saved changes, it just worked.

I don't know if it's a bug, but I don't remember changing this value. Furthermore, I could copy the value from the field and test it in a browser with no problem. In any case, I hope this helps.

Answer 5

You should be setting up a CNAME record instead of an A record. Enter your subdomain in the Name field, and the Elastic Beanstalk URL in the Value field. You should use A or Alias record to point to the root domain only: domain.com