Troubleshooting with dig

Troubleshooting with dig means you query DNS directly from the command line so you can see what a nameserver actually returns. You aim dig at a specific server, read the answer and the remaining TTL, and decide whether the zone is wrong or a cache is simply old. Four flags cover most tickets: @server, +short, +norecurse, and +trace. Ping is not a DNS test, so paste dig output instead of a browser screenshot.

Check the authoritative server, then a public cache

Start with our nameserver so you know what the zone holds right now. The first command below asks ns1 without recursion. If that A record is wrong, fix the zone and stop waiting on propagation. If ns1 is correct and a public resolver still shows the old address, you are seeing remaining TTL in a cache. Wait it out, or try a second resolver. When ns1 itself looks wrong, ask the TLD whether the registrar NS change has landed.

dig example.com A @ns1.logicweb.com +norecurse
dig example.com A @1.1.1.1 +ttlunits

You can also run dig example.com NS @a.gtld-servers.net +norecurse when the nameserver set is the real question. The whois NS list is what the registrar last published, and it should match what the TLD returns. Our nameservers are ns1.logicweb.com and ns2.logicweb.com when the domain points here.

When ping does not help

Ping needs ICMP, a resolved address, and a host that answers. None of that proves the DNS tree is correct. A host can reply to ping and still have the wrong MX. A host can fail ping and still serve HTTPS just fine. Paste dig output in the ticket so we can read the answer section. Ask ns1 first, then a public resolver, then the TLD if the NS set is in doubt.

What +trace is for

Use +trace when you are not sure the NS set is what you expect. It starts at the root, follows the TLD, and then reaches the authoritative servers. If the TLD still names the old host, the registrar change did not land. If the TLD names ns1.logicweb.com and ns1 has the right A record, public caches are only slow. whois NS and TLD NS should match; when they do not, whois may be stale or the change is still in flight.

Paste the two commands above in a ticket, not a screenshot. Include the exact name you queried. If you queried www and we asked about the apex, say so, because mixed names hide leftover CNAMEs. The fifth flag, +dnssec, is mainly for a SERVFAIL caused by a DS mismatch, not a missing A. A CNAME at the apex is a special case dig shows right away: a CNAME answer where you expected A. See CNAME flattening at the apex if that is the line you just got.