Check DNS propagation and find the source of an old answer

Open the domain's DNS records, refresh the list and inspect History & requests. Confirm that the intended change completed. If it is applying, scheduled or failed, first resolve that state. Clearing your browser cache will not make an unapplied DNS change reach the provider.

1. On the records screen, choose the propagation/check action for the record you are investigating.
2. Use the exact hostname and type, such as www.example.com with A or CNAME, or example.com with MX.
3. Compare the reported answers with the value you intended to publish.
4. Read the nameserver and delegation result as well as the resolver results.

If the registrar delegates the domain to another provider, edit the records there or carry out a planned nameserver move. A green-looking record list in this manager cannot override delegation. The source of authority is a separate question from whether several recursive resolvers agree.

Use dig from a workstation with DNS utilities installed. Replace example.com and ns1.example.net with your domain and an actual authoritative nameserver from its delegation. These queries read DNS and do not change or flush any record.

dig example.com A +noall +answer
dig @ns1.example.net example.com A +norecurse +noall +answer +comments

Read the result: If the authority returns the new address but the recursive lookup returns the old one, compare the remaining TTL and the resolver in use. If the authority still returns the old value, waiting for propagation will not fix an edit made in the wrong DNS panel or on only one server.

Repeat the direct query against every listed authority and keep the full name, record type, server and test time. A successful A lookup does not check AAAA, www or MX records. Test the exact name and type used by the failing service.

• New answer at authority, old answer on some resolvers: cached data may still be within its previous TTL. Reducing TTL after the change does not shorten copies already cached under the old TTL.
• No answer for one hostname: check the precise name, record type and whether a domain suffix was duplicated.
• Different website on IPv6: review the AAAA record as well as A.
• SERVFAIL after a move: investigate DNSSEC and an old parent DS record, as well as nameserver availability.
• Correct DNS, wrong page: check the web server, certificate, redirects and application configuration.

Give support the hostname, queried type, expected answer, observed answer, time and relevant operation reference. State whether authoritative and recursive answers differ. Avoid repeatedly replacing nameservers while waiting, since each new change adds another state to diagnose. A propagation check samples the available locations; it cannot certify that every network worldwide has already refreshed.

• Add, edit and remove DNS records in the client area
• Enable DNSSEC and complete the DS-record setup
• Collect useful details when a DNS change is not working
• Open your DNS Manager and find the right domain

• Cloudflare: Troubleshoot pending nameservers

• ISC BIND: dig and delv reference