DNS Changes Not Working: Check the Record, Resolver and Cache

Preparation: Confirm the Record Type and Target

Before troubleshooting, verify exactly what you changed. DNS records serve specific purposes: an A record maps a domain to an IPv4 address, an AAAA record maps to an IPv6 address, and a CNAME record aliases one domain to another. Confusing these types is a common cause of "not working" scenarios. For example, if you intended to point www.example.com to an IP address but created a CNAME pointing to another domain that itself has no A record, the resolution will fail.

• Action: Log in to your DNS provider's dashboard. Identify the specific record you modified (e.g., example.com A record).
• Verification: Note the exact value (IP address or target domain) and the TTL (Time To Live) setting. If you are using Cloudflare, you can refer to their DNS record types documentation to ensure the record type matches your intent.

Step 1: Verify Authoritative DNS Records

The first point of failure is often that the change has not propagated to the authoritative nameservers. Authoritative nameservers are the source of truth for your domain's DNS data. If the record is not present or incorrect on these servers, no resolver will return the new value.

• Action: Use the dig command to query the authoritative nameservers directly. This bypasses local and ISP caches.

bash dig +short example.com A @ns1.your-dns-provider.com Replace ns1.your-dns-provider.com` with the actual nameserver listed in your domain's WHOIS or DNS provider settings.

• Verification: The output should show the new IP address. If it shows the old IP or returns nothing, the change has not been saved or propagated to the authoritative servers. Check for typos in the record name or value. According to MDN's glossary on DNS, the DNS hierarchy relies on authoritative servers providing definitive answers for their zones. If the authoritative server is correct, the issue lies downstream.

Step 2: Check Recursive Resolution and TTL Impact

If the authoritative records are correct, the next layer is the recursive resolver (usually your ISP's DNS server or a public resolver like 8.8.8.8). Recursive resolvers cache DNS responses to improve performance. The TTL determines how long a resolver can cache a record before it must query the authoritative server again.

• Action: Query a public recursive resolver to see what it returns.

bash dig +short example.com A @8.8.8.8

• Verification: Compare the result with the authoritative query.

If the public resolver returns the old IP, the record is likely still cached. Check the TTL of the old record. If the TTL was high (e.g., 86400 seconds/24 hours), it may take up to that duration for the change to propagate globally. If the public resolver returns the new IP, the issue is likely local to your machine or network.

Step 3: Clear Local and Network Caches

Even if the internet sees the new record, your computer may still be using a cached version. Operating systems maintain a local DNS cache to speed up repeated lookups.

• Action: Flush the local DNS cache on your operating system.

Windows: Open Command Prompt as Administrator and run `ipconfig /flushdns`. macOS: Run sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder. Linux:* Restart the systemd-resolved service or use resolvectl flush-caches.

• Verification: After flushing, run ping example.com or nslookup example.com on your machine. If it now resolves to the new IP, the issue was local caching. If it still resolves to the old IP, check if your router or ISP is caching the record. Contacting your ISP to flush their recursive cache may be necessary, though this is less common with modern public resolvers.

Step 4: Verify Origin Reachability and Port Status

If DNS resolves to the correct IP but the website is still inaccessible, the problem may not be DNS but the origin server. The server might be down, or the web service (HTTP/HTTPS) might not be listening on the expected ports.

• Action: Test connectivity to the IP address on ports 80 (HTTP) and 443 (HTTPS).

bash curl -I http://<new-ip-address> curl -I https://<new-ip-address> Or use telnet <new-ip-address> 80` to check if the port is open.

• Verification:

If `curl` returns an HTTP response (e.g., `HTTP/1.1 200 OK`), the server is reachable and serving content. The issue might be a firewall blocking your IP or a misconfigured reverse proxy. If the connection times out or is refused, the server is likely down, or a firewall is blocking the port. This is an application-layer or network-layer issue, not a DNS record issue.

Risks and Rollback: Common Pitfalls and Emergency Handling

Several common errors can lead to persistent resolution issues:

1. CNAME Flattening Issues: Some DNS providers do not support CNAME records at the zone apex (e.g., example.com). If you try to create a CNAME for the root domain, it may fail or cause resolution errors. Use an A record or AAAA record for the root domain, or use a service that supports CNAME flattening (like Cloudflare's proxy).
2. DNSSEC Validation Failures: If DNSSEC is enabled, a mismatch between the public key and the signature can cause resolvers to reject the record. Check your DNS provider's dashboard for DNSSEC status. If you recently changed records, ensure the DNSSEC signatures are updated.
3. Propagation Delays: Even with a low TTL, global propagation can take time due to the distributed nature of DNS. Do not assume the change is broken if it works on some networks but not others.

Rollback Strategy: If your site is down due to a DNS change, immediately revert the record to the previous known-good value. Most DNS providers allow you to edit the record back to the old IP or target. Monitor the resolution using dig to confirm the rollback has taken effect. If the issue persists after rollback, the problem may be with the origin server or a broader network issue, not the DNS record itself.

Verifying Record Types and Syntax Reference

When DNS updates fail, mismatched or improperly formatted record types are a frequent culprit. Consult the official Cloudflare DNS record types reference to ensure your configuration aligns with supported specifications before debugging recursive resolvers.

Verifying Record Types and Resolver Behavior

When a DNS change appears to have no effect, the first step is to confirm that the specific record type you modified matches the protocol your application uses. For example, switching from an A record to an AAAA record will not resolve IPv4 traffic, and a CNAME record cannot coexist with other records at the same hostname. You can verify the exact syntax and supported fields for each record type in the Cloudflare DNS record types reference. This documentation clarifies how different record types interact with the resolution process, helping you distinguish between a misconfigured record and a caching issue. If you are still unsure about the fundamental differences between A, AAAA, and CNAME records, reviewing the DNS for Beginners guide can provide a practical foundation for understanding how these records function in a live environment.

Sources

• DNS record types · Cloudflare DNS docs
• DNS - Glossary | MDN