One of the most confusing situations when managing a website is when some people see the new version while others are still directed to the old server. There are also cases where a website can be accessed without www, but fails when using www. Domain emails may stop coming in, or Cloudflare displays an error even though the server is still active.
Such issues are often not solely the fault of the hosting provider. The cause may lie in the DNS layer, which is the system that translates domain names into IP addresses or service destinations. Understanding this part is crucial whenever you move servers, change IP addresses, add subdomains, or enable Cloudflare.
DNS is more than just a “website address”
Think of a domain as the name of a building, while DNS is the officer who informs visitors where the building is located. If the address changes, the officer and the directory in various places need to be updated. Not everyone receives the updates at the same time because DNS information can be cached by resolvers and devices.
Some common types of records used are:
- A record: directs the domain name to the server's IPv4 address.
- AAAA record: directs the domain to the IPv6 address.
- CNAME: makes one host name point to another host name.
- MX: specifies the server that receives emails for the domain.
- TXT: stores verification information or policies, such as SPF and service verification.
For websites, changes usually involve A, AAAA, or CNAME records. However, changing website records without checking MX and TXT records can cause email or service verification issues.
TTL explains why changes are not immediately felt
TTL, or Time to Live, is the duration a record can be cached by a DNS resolver before needing to fetch new information. A longer TTL can reduce the frequency of DNS lookups but makes changes take longer to appear. Cloudflare also reminds that local caching can make record changes feel longer than expected. ([developers.cloudflare.com](https://developers.cloudflare.com/dns/manage-dns-records/reference/ttl/?utm_source=openai))
For example, if you change the server IP from 203.0.113.10 to 203.0.113.20. Resolvers that still have the old address cached may continue directing some visitors to the previous server until the TTL expires. Therefore, the term “DNS propagation” does not mean all internet servers receive updates in one second.
If server changes are planned, lower the TTL a few hours or a day in advance. After the migration is complete and the results are stable, the TTL can be increased again. This step is not a guarantee that changes will be instantaneous, but it helps reduce the duration of old cache retention.
Check if the issue is with DNS or the server
Do not immediately delete and recreate all records. Start with a simple question: where is the current domain pointing?
- Check the
AandAAAArecords for the main domain andwww. - Compare the IP that appears with the information from the hosting provider.
- Check if there are any old records still active.
- Ensure the domain's nameserver points to the correct DNS provider.
- Test from different networks, such as home Wi-Fi and mobile networks.
On a computer, you can use the following commands:
dig example.com A
dig www.example.com A
dig example.com MXThese commands help view the DNS responses received by the resolver. For a simpler check, you can also use public DNS checking services. What to look for is not just whether the records are available, but whether their values match the intended server.
Cloudflare: differentiate between DNS only and Proxied
Cloudflare can function as both a DNS manager and a reverse proxy. When a record is set to Proxied, visitor requests pass through the Cloudflare network before being forwarded to the origin server. When set to DNS only, DNS simply returns the destination address and the connection goes directly to that server. For A, AAAA, and CNAME records, the proxy option determines how traffic is processed. ([developers.cloudflare.com](https://developers.cloudflare.com/dns/manage-dns-records/how-to/create-dns-records/?utm_source=openai))
Proxy is suitable for web traffic that can be served via HTTP or HTTPS. However, do not enable it for email services indiscriminately. Mail records like mail.example.com generally need to be set to DNS only so that email connections are not routed through the web proxy. Cloudflare also explains that email configurations require records like MX and address records for the email server according to the provider's instructions. ([developers.cloudflare.com](https://developers.cloudflare.com/dns/manage-dns-records/how-to/email-records/?utm_source=openai))
If the website displays errors 521, 522, or 525 after the proxy is enabled, the cause may lie in the connection between Cloudflare and the origin, closed ports, server firewall, or TLS certificates on the origin server. In such cases, changing the proxy to DNS only for testing can help narrow down the source of the problem. After diagnosis is complete, revert the settings as needed for security purposes.
Don't forget the SSL certificate
Correct DNS does not necessarily make HTTPS work immediately. The new server must also have a certificate that includes the domain name being used, including possibly www.example.com or specific subdomains.
If the certificate is managed automatically through ACME, ensure that the domain validation process can still be performed. Let's Encrypt uses ACME to verify control over the domain before issuing certificates. They also recommend automating renewal since manual processes increase the risk of certificate expiration. ([letsencrypt.org](https://letsencrypt.org/docs/client-options/?utm_source=openai))
Do not frequently delete ACME client configurations and request new certificates just for experimentation. Let's Encrypt enforces certificate issuance limits, including limits for the same domain name combinations. For testing, use a staging environment if available. ([letsencrypt.org](https://letsencrypt.org/docs/rate-limits/?utm_source=openai))
What you can do now
- Keep a list of all DNS records before making changes.
- Note the old and new server IPs, including the time of change.
- Lower the TTL before planned migrations.
- Check
A,AAAA,CNAME,MX, andTXTrecords. - Test the main domain,
www, subdomains, email, and HTTPS separately. - Ensure the server firewall allows ports 80 and 443 if the website uses HTTP/HTTPS.
- Do not delete old records until you are sure no important services still depend on them.
- Add comments or internal documentation to explain the function of each record.
What it means for us
DNS is a small part of the website infrastructure, but errors within it can appear as hosting, Cloudflare, SSL, or even application issues. Therefore, a good troubleshooting approach is not to immediately change providers or redeploy, but to check the request path from the beginning: where the domain points, whether the cache still holds the old address, whether the proxy is active, and whether the server and certificate are ready to accept connections.
By following this order, you not only save time when the website encounters errors. You also reduce the risk of email disruptions, certificate renewal failures, or visitors being directed to servers that are no longer in use.
Sources & further reading
- Cloudflare DNS: Time to Live (TTL)
- Cloudflare DNS: Manage DNS records
- Cloudflare DNS: DNS record types
- Cloudflare DNS: Set up email records
- Let's Encrypt: ACME client implementations
- Let's Encrypt: Rate limits
– Rio Yotto @rioyotto