2

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:

enter image description here

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.

buzoherbert
  • 1,253
  • 1
  • 8
  • 29
  • check the propagation using https://dnschecker.org/ – electrodragon Jan 27 '20 at 10:52
  • Thanks @saitejapakalapati , I checked the tool and it seems to be for checking DNS resolutions in different locations. This is not my problem, the subdomain does not work on any location. Am I missing something about the tool? – buzoherbert Jan 28 '20 at 06:48

3 Answers3

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.

enter image description here

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.

buzoherbert
  • 1,253
  • 1
  • 8
  • 29
0

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

littleforest
  • 1,604
  • 19
  • 26
  • thanks for your comments. I tried to use CNAME instead of A with no luck. Could another AWS configuration be causing this problem? – buzoherbert Jan 28 '20 at 06:54
  • CNAME works, but alias is set to "No" then since it's a direct pass along. Note AWS charges for CNAME redirects as well. Major limitation using the CNAME here -> https://stackoverflow.com/a/20230670/5180047. – Nick Brady Jul 21 '20 at 21:57
0

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.

  1. (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

Nick Brady
  • 4,708
  • 1
  • 30
  • 57