The site won't come up, the browser gives ERR_NAME_NOT_RESOLVED, but the server responds over SSH and curl -I http://127.0.0.1 also returns 200. That means the problem isn't the web server; you're lost somewhere between the domain and the server. This almost always means a record in the DNS panel is wrong, or it's right but hasn't propagated yet. You can tell the difference between these two states in five minutes, provided you know where to look.
Before making any change, look at the current state from the outside, not from the panel. The panel shows what you've saved; resolvers show what has actually spread across the internet. These two differ by hours when the TTL is high.
dig +short A example.com @1.1.1.1
dig +short A example.com @8.8.8.8
dig +trace example.comIf 1.1.1.1 and 8.8.8.8 don't give the same answer, you're mid-propagation and there's nothing to do but wait. If both give the same wrong IP, the record is wrong. If you get NXDOMAIN, the record doesn't exist at all or was registered on the wrong zone. To see the full chain from the root to authoritative, you can also use the DNS record lookup, which displays the same output in a readable form.
Which record you should change
Most of the confusion starts here: four record types look similar but their jobs are completely separate.
| Type | Its job | Sample value |
|---|---|---|
A | Maps a name to an IPv4 | example.com. 3600 IN A 185.10.20.30 |
AAAA | Same job for IPv6 | example.com. 3600 IN AAAA 2a01::1 |
CNAME | Points a name to another name | www 3600 IN CNAME example.com. |
MX | Determines the email destination | example.com. 3600 IN MX 10 mail.example.com. |
The point that trips up a lot of people: CNAME is not allowed on the domain root (@). If the panel allows it, some resolvers ignore it and others consider the whole zone invalid. Always use A for the root. If a provider mentions a "flattened CNAME" or ALIAS, that's a proprietary record that gets converted to an A in the final answer, not a real CNAME.
For subdomains it's the opposite: CNAME is the better choice because if the destination server's IP changes, you don't have to touch the panel. Just remember that a CNAME and any other record with the same name don't coexist. If you've CNAME'd mail, you can't also put an MX on the same name.
How to choose the TTL
TTL is measured in seconds and tells resolvers how long they're allowed to cache the answer. The number you see in the panel is usually between 300 and 86400. The shortest option isn't always right; every TTL reduction means more queries to your nameservers and more load on them.
- Live and stable site: 3600 to 86400. Anything lower has no benefit.
- Before a planned migration: drop it to 300 24 to 48 hours beforehand, then restore it after things settle.
- Dynamic records or DDNS: 60 to 300, otherwise the IP changes and the user still sees the old address.
- Email records like SPF and DKIM: don't touch them. Email changes propagate more slowly than web and receivers have their own caches.
A real limitation that's rarely mentioned: you set the TTL, but resolvers aren't obligated to respect it. Some local ISPs cache for several times the announced TTL. If you set the TTL to 300 and half an hour later you still see the old IP, it's probably not your problem. I've explained the details of this behavior with numerical examples in What is DNS propagation and why does it take time.
The safe order for changing a record on a live site
This is where most outages happen. The order of operations matters more than the operation itself.
- Reduce the current record's TTL to 300 and wait at least one full TTL so old caches expire.
- Test the new destination separately from the domain:
curl -I --resolve example.com:443:185.10.20.40 https://example.com. If SSL errors here, you're not ready yet. - Edit the record, don't delete and recreate it. Deleting and recreating creates a window in which the name doesn't resolve at all.
- Confirm with
dig +short A example.com @1.1.1.1that the new IP has arrived. - After 24 hours of stability, restore the TTL to its previous value.
If this is a migration to a new server and SSL is involved, I've written the order of records and certificate issuance step by step in Pointing a domain to a VPS; the common mistake is issuing the certificate before changing the record, and after the change the domain reaches a server that doesn't have that certificate.
Where people go wrong
The most common mistake I see in tickets is this: the user correctly changes the A record but forgets the www record, which is a separate CNAME to an old shared host. The site opens with example.com but shows the old version with www.example.com. The tell is that the user says "the site has changed but some people still see the old one" and the problem isn't caching at all. Before any migration, get the full list of records:
dig +noall +answer example.com ANY
dig +short CNAME www.example.comMistake number two: setting * as a wildcard when you only need one subdomain. The result is that every typo'd name also reaches your site and scanning bots register thousands of fake subdomains on your domain. If you genuinely need dynamic subdomains, I've explained the right approach in Wildcard records and managing dynamic subdomains.
Look at email records separately
Changing an A record has no effect on email, but changing MX takes down all correspondence. Before any change to MX, save the output of this command:
dig +short MX example.com
dig +short TXT example.comThe TXT record usually contains SPF, and a common mistake there is exceeding the 255-character limit in a single string. If you have a long SPF, you need to split it into multiple strings; some panels do this automatically and some don't, and the result is that your SPF silently becomes invalid and emails go to spam. The tell isn't obvious either: sending succeeds, delivery doesn't.
If your domain is .ir, you have an extra layer: nameserver changes and some edits are applied from IRNIC's side, not just the panel. I've separated the difference between these two paths in Guide to registering and managing .ir domains, because the order of operations differs for these domains and a mistake there creates several days of delay.
When none of it works
If the record is correct, the TTL has passed, and it still doesn't resolve, the problem is almost always one of these three: the domain's nameservers in the registrar panel don't point to the zone's actual nameservers, the zone was created on the wrong nameserver, or the domain has expired and is in clientHold status. Check the third with whois example.com | grep -i status. If you see clientHold, no DNS change will save you; it must be renewed first. I've written the full order for checking these states in Practical DNS troubleshooting guide and I recommend running through that order once before opening a ticket.
One note about hosting: if the site is on shared hosting, you usually set the provider's nameservers and manage records from their panel; in that case your hands are tied for some records. On Linux hosting these records are editable from the same panel and that's enough for most sites. If you need unusual records like SRV or full zone control, a VPS with dedicated nameservers is the better choice.
Before any change, do this one thing: save the output of dig +noall +answer example.com ANY somewhere. When the site goes down, having the previous state is the difference between five minutes and five hours.
Frequently asked questions
Why does the site still show the old IP after changing the A record?
Because resolvers have cached the previous answer until the TTL expires. If you didn't lower the TTL before the change, this can last up to 24 hours. Check with dig +short A example.com @8.8.8.8 and @1.1.1.1; if one is new and one is old, you just have to wait.
What's the lowest TTL I can set?
Most panels accept a minimum of 60 seconds and some limit it to 300 seconds. Below 60 seconds has no practical benefit because resolvers aren't obligated to respect it and it only increases query load on your nameservers.
Can I put a CNAME record on the domain root?
No. The DNS standard doesn't allow a CNAME on the root because it conflicts with the mandatory NS and SOA records. Use A for the root. If a provider has an option called ALIAS or flattened CNAME, that's a proprietary record that gets converted to an A in the final answer.
What effect does changing the MX record have on previous emails?
Emails that have already been delivered remain untouched. But emails in transit during the propagation window may reach the old server and be rejected there. If you've shut down the old server, email will be lost for several hours; before changing MX, make sure the old server still responds.