`dig +short` Is the DNS Command You Should Run Before You Blame the Server for a Domain Pointing Somewhere Stupid

Why this command matters: a lot of “server is down” incidents are really “DNS is pointing somewhere else” incidents wearing a cheaper costume.

When a domain resolves to the wrong IP, no amount of nginx tuning, app restarts, or certificate checking will save your time. You need to confirm what DNS is actually returning first. That is where dig +short is useful: it strips the ceremony away and shows the answer you care about.

The command

dig +short example.com

For a subdomain:

dig +short api.example.com

If you need to inspect a CNAME:

dig +short www.example.com

This output is fast to scan because +short removes most of the verbose section noise.

What it helps you answer

It quickly tells you:

1. which IP address or canonical name the domain currently resolves to
2. whether the answer matches the infrastructure you expected
3. whether the record changed at all after a DNS update

That is enough to catch a lot of wrong-host debugging before it begins.

Why developers skip the obvious

People often assume the domain layer is fine because “we already changed the record.” That is not proof. What matters is what the resolver returns right now from the machine doing the check.

A useful pattern is:

dig +short example.com
dig +short www.example.com
dig +short api.example.com

Now you can compare what the main domain, web alias, and API hostname are doing instead of treating them as one thing.

Good follow-up habit

If you suspect a specific public resolver difference, query one directly:

dig @1.1.1.1 +short example.com
dig @8.8.8.8 +short example.com

That helps separate origin-record issues from local resolver caching weirdness.

Final recommendation

If a domain-based problem feels suspicious, run dig +short before touching the server. DNS mistakes are common, quiet, and embarrassingly good at tricking people into debugging the wrong machine.

Sources

• BIND dig manual