2

I have a subdomain on domain.com and am using A records to point to some IP addresses associated with a github pages site.

I am moving my hosting away from github pages to another provider. This provider suggests using a CNAME to configure the DNS.

In an effort to avoid downtime I am trying to find the best way to make the change.

Should I add the new CNAME and leave the A records in place? I could then delete the A records once the CNAME resolves.

Or should I add the new CNAME and delete the A records?

3
  • 1
    Is it possible you really mean A record when you say @ record? @ refers to the main, subdomainless, naked domain, e.g. example.com and not www.example.com or subdomain.example.com. So by definition you cannot have an "@ record" on a subdomain, because @ quite literally means "not on a subdomain". Commented Dec 7, 2023 at 18:24
  • 1
    If you are looking to move from an A record to a CNAME record for a particular subdomain and @ is not actually relevant to the question, then note that A and CNAME records set for the same subdomain will conflict with each other, so you'll have to remove the A record before adding the CNAME record. This should cause minimal downtime, though if the A record had a high TTL, then you may be waiting for a while before all clients update their DNS records and start hitting the new server instead of the old one. You can mitigate this by lowering the TTL of the A record and waiting. Commented Dec 7, 2023 at 18:32
  • @MaximillianLaumeister - I've edited my question and yes, they are A records.. Feel free to add your comment as an answer and I'll accept. Regarding the TTL, it's set to automatic on my A records. So you're saying if I lower this before making the switch, it will help resolve quickly?
    – jotamon
    Commented Dec 7, 2023 at 20:35

1 Answer 1

2

A and CNAME records for the same subdomain will conflict with each other, so you'll have to remove the A record before adding the CNAME record. This should cause minimal downtime, though if the A record had a high TTL, then you may be waiting for a while before all clients update their DNS records and start hitting the new server instead of the old one. You can help minimize the switchover delay by lowering the TTL of the A record before migrating, then waiting out the duration of the original TTL before making your DNS changes.

An article from Rackspace describes this process of lowering the TTL before making changes:

Generally, we recommend a TTL of 24 hours (86,400 seconds). However, if you are planning to make DNS changes, you should lower the TTL to 5 minutes (300 seconds) at least 24 hours in advance of making the changes. After the changes are made, increase the TTL back to 24 hours.

Best practices for using TTL - Rackspace

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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