dig — Query DNS Records Directly
dig is the reference tool for asking a name server a question and seeing the complete answer. Unlike a browser lookup or a ping, it shows you the whole response: the records returned, the response code, the flags the server set, the TTL remaining on each record, and which server actually answered. When two people disagree about what a domain resolves to, dig is how the disagreement gets settled, because it lets you query a specific resolver directly rather than whatever your operating system happens to have cached.
Why run it
You run dig when something is not resolving the way you expect, and the usual suspects are all invisible from a browser. Perhaps a record was updated but a resolver is still serving the old value from cache, in which case the TTL in the answer tells you exactly how long you have to wait. Perhaps the record exists but the response is SERVFAIL because DNSSEC validation is failing. Perhaps a wildcard is catching a name you thought was explicit. Each of those looks identical from the outside — the site does not load — and each has a completely different fix. The response code and flags in a dig answer separate them in one command.
Why automate it
A manual dig tells you what is true at the moment you typed it, which is the wrong resolution for a problem that arrives at three in the morning or drifts over weeks. DNS records are edited by people who are not you: a registrar migration, a CDN onboarding, a colleague fixing something unrelated. Running the same query on a schedule and comparing each answer with the last turns a manual check into change detection, and change detection is what catches a record that was replaced at the weekend rather than the outage it causes on Monday. It also builds the history you need to answer "when did this change?" — a question that is almost impossible to answer after the fact from memory.
What it gives you
dig converts a vague report that something is broken into a specific, quotable fact about what a named server returned at a named time. That is worth having during an incident and worth keeping afterwards: the same query, run continuously, is the difference between discovering a DNS change when it happens and discovering it when a customer calls.