AWS Route 53 DNS not resolving to subdomain

amazon-route53amazon-web-servicesdomain-name-system

My DNS domain for numeet.com (just a spare domain) was pointed to Route 53, and resolution of numeet.com and www.numeet.com is working fine.

However, a subdomain called learn.numeet.com is not working, despite a CNAME.

The main A record points to an elastic load balancer where a couple of servers are dealing with web traffic (once SSL is terminated on the ELB)

The CNAME resolves to a specific IP address of one of the above servers (the only one that has Moodle installed). That server has a vhost setup and an elastic IP address to the subnet on the server and HTTP is fully open (and already working with the ELB).

However, when 2 days after setting this up I try to got to http://learn.numeet.com, the DNS still does not resolve.

On the EC2 instance, I can run dig learn.numeet.com, and that resolves to the IP address fine. However, even from the EC2 server, ping learn.numeet.com doesn't work.

The record setup is as per the photo below:

Is there a problem with Route 53 having multiple routes to the server (www.numeet.com via ELB and learn.numeet.com via Elastic IP) ?

What am I missing?

Best Answer

CNAME records must always point to another domain name, never directly to an IP address.

Related Solutions

Nginx AWS ELB – How to Set Real IP from AWS ELB Load Balancer Address

If you can guarantee that all requests will be coming from ELB (I'm not familiar with it), you could try:

real_ip_header X-Forwarded-For;
set_real_ip_from 0.0.0.0/0;

That should tell nginx to trust an X-Forwarded-For header from anyone. The downside is that if anyone directly accesses your server, they would be able to spoof an X-Forwarded-For header and nginx would use the wrong client ip address.

AWS Route 53 alias-record change takes too long

Firstly, it's important to recognise that the DNS records cached on the client or their DNS resolver which are both out of your control (note that I'm referring to the DNS records not your authoritative name server). Therefore it's up the client and their DNS resolver to honour your TTL.

In the case of a new visitor who has never visited your site before and whose DNS resolver has not cached your records (or visited long enough ago that the cache has expired) they will see the new records immediately.

Shouldn't this be under 60 seconds?

It should, but that's only if your client honours the TTL. Some clients have minimum TTL's and some networks also have a DNS resolver which may be caching results.

Is it possible to reduce this time?

You have to remember that the majority of your visitors (assuming this is a public site) won't have been sitting there loading your site every few seconds like you have. Most of your visitors probably won't have visited the site recently and and their DNS resolver may not have the records in their cache. Most DNS resolvers should respect your TTL but you can't guarantee this.

What is a safe time to delete the old stack?

You're better off judging this by what traffic is still being served by the old stack rather than DNS TTL. If you're using ELB you should be able to view how many requests per second are being served by the old ELB in cloudwatch. Wait until this drops below an acceptable level then delete it.

For the sake of viewing the new stack immediately after the switch I recommend just manually flushing your local DNS cache. Leaving your own client to expire records naturally for the sake of seeing how long it takes probably won't be indicative of how long it takes for other clients.

Edit, I noticed Google's Public DNS has a tool to let you flush the cache:

https://developers.google.com/speed/public-dns/cache

This may speed things up as a significant proportion of clients are likely to be using this.

Related Topic