How to troubleshoot a DNS change
Check A, AAAA, CNAME, MX, NS, and TXT answers, distinguish a cached response from the intended record, and separate DNS problems from HTTPS or redirect problems.
Write down the intended hostname and record
Start with the hostname visitors actually use. example.com and www.example.com may use different records. Record the expected value from your DNS or hosting provider and the time you changed it. The examples here are documentation placeholders; they are not live infrastructure to configure.
ADEMN’s lookup reports six common public record types. Match the question to the record: website address answers, mail routing, and verification text answer different questions. A correct mail record does not prove the website reaches its intended host.
| Record | What to compare | Useful follow-up |
|---|---|---|
| A | The expected IPv4 destination | Check every returned address. |
| AAAA | The expected IPv6 destination | Check this as well as A when IPv6 is configured. |
| CNAME | The intended alias hostname | An alias is a DNS name, not an HTTP redirect. |
| MX | Mail hostnames and priorities | Compare with the mail provider’s instructions. |
| NS | The expected nameservers | Check delegation at the registrar when providers change. |
| TXT | The exact verification or policy text | Do not replace unrelated TXT records. |
Interpret the resolver’s view
Run DNS Lookup for the hostname and compare the returned values with your written expectation. The results are the public answers visible to ADEMN’s server. Another resolver may still hold an older cached answer, so one successful lookup does not prove that every visitor has the new result.
TTL limits how long a DNS answer can be cached. Lowering a TTL after a previous answer was cached does not retroactively remove that older entry. Avoid repeatedly editing records while investigating: compare the intended configuration, previous TTL, and several resolver observations first.
Hostname: shop.example.com
Changed record: A
Expected documentation address: 192.0.2.10
Also inspect: AAAA if an IPv6 record exists
Record separately: change time and previous TTLSeparate resolution from the web connection
If the address answers are correct but HTTPS fails, check the presented certificate and the destination server. If HTTPS connects but the browser reaches another domain or path, inspect the HTTP redirect chain. DNS sends a hostname toward an address; an HTTP response can then instruct the client to visit another URL.
An unexpected AAAA answer can matter even when A looks correct. Some clients may use IPv6 while another test uses IPv4. Compare the whole set of configured public addresses and check whether each destination serves the intended website.
Distinguish no record from a failed query
A missing record of one type can be normal. A domain without an AAAA record may still have an A record, and a hostname with no MX answer is not automatically a broken website. A timeout or resolver failure means the lookup could not establish the answer; it is not evidence that the record does not exist.
When a change remains unexplained, compare answers at the authoritative nameserver with a public recursive resolver or ask your provider to check the delegation. ADEMN does not perform a full delegation trace or a DNSSEC audit. Keep the change log and avoid publishing private internal hostnames in a support request.