I have set up a CNAME in Amazon's Route 53 to point to another server.

This is a new CNAME for a new subdomain pointing to an existing domain name.

With other DNS providers that I've worked with, new Canonical Name records have aliased to another canonical domain name instantly.

  • I'd wait a couple minutes. Route53 records go to dozens of datacenters around the world, and presumably, dozens of servers in those datacenters, so I've typically seen between a couple seconds and a couple minutes for the four nameservers addresses for a domain to start returning results.
    – ceejayoz
    Sep 25 '12 at 17:18
  • 2
    How are you testing whether they have "worked" or not? There's a lot of caching in DNS and if you aren't doing it right you will just be seeing a cached record.
    – Ladadadada
    Sep 25 '12 at 17:21
  • 1
    I am testing it by attempting to hit the url that I've setup. In my question, I mentioned that this is a new record, so I'm not sure I should be concerned about cached records on my machine. Sep 25 '12 at 17:31

Route 53 DNS record changes propagate in less than a minute, but TTL times will impact on how quickly DNS resolvers check back for updated records.

Q. How quickly will changes I make to my DNS settings on Amazon Route 53 propagate globally?

Amazon Route 53 is designed to propagate updates you make to your DNS records to its world-wide network of authoritative DNS servers within 60 seconds under normal conditions. A change is successfully propagated world-wide when the API call returns an INSYNC status listing.

Note that caching DNS resolvers are outside the control of the Amazon Route 53 service and will cache your resource record sets according to their time to live (TTL). The INSYNC or PENDING status of a change refers only to the state of Route 53’s authoritative DNS servers.

Or, if you prefer the AWS developer forums...

You can expect it to have propagated to all Route 53 servers around the world within a minute. However, keep in mind that the TTL determines how quickly the clients will see the updated information. If you set the TTL for a record to say 3600 seconds, DNS resolvers can cache that data for up to an hour before going back to Route 53 again. If it is important to make the updated record propagate down to the end users as fast as possible, I would recommend a TTL of 60 seconds.

As the TTL is configured for each record, you can use different values. If you don't plan to make any changes to a record in the near future, a higher TTL can help you save on query costs and make things a bit more efficient. As an example, you might not need to update your MX records just like that. Let's say you have a TTL set to 43200 seconds (12 hours) for your MX records. If you ever switch to another e-mail provider, simply lower the TTL in advance. As soon as the original TTL has expired, you can proceed with the move. The updated records will now propagate much faster thanks to the lower TTL. Change the TTL back to the original value at the same time.

  • Thanks for the answer. I read the FAQs before I reached out here. The only reason I was wondering was because it didn't happen in less than the TTL. The record that I added is a brand new record to a subdomain that hasn't existed before. Sep 25 '12 at 17:34
  • Just want to share my observations. I changed an A record for a subdomain with TTL 1 and it's been about 15 minutes. Created a new subdomain about 5 minutes ago and it's not out there yet. I don't use route 53 on a daily basis, but I've never had updated within 60 seconds. Very confusing.
    – sr9yar
    Apr 8 '21 at 18:07

60 seconds, but make sure your host operating system isn't caching the DNS records for longer. Use a DNS lookup tool to check directly against a name server.


I didn't pay attention the the CNAME value, it was incorrect for the CNAME spec. The answer to the question is 'instant'.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.