dig and host for DNS

dig and host for DNS investigation.

dig

dig is the standard DNS investigation tool. The host command is simpler; dig is more powerful. Engineers debugging DNS issues reach for dig; the discipline is fluency with its options.

What basic usage looks like:

• dig api.example.com queries default resolver.: The basic invocation. dig queries the system's configured DNS resolver; the response includes the answer and metadata.
• +trace follows the full chain.: The +trace option shows the full resolution chain. From the root servers down through the authoritative servers; each step is visible; the path is comprehensive.
• Default record type is A.: Without specifying a type, dig returns A records. Other types (AAAA for IPv6, MX for mail, TXT for text, CNAME for aliases) require explicit specification.
• Specify type with the type name.: dig MX example.com returns MX records. dig TXT example.com returns TXT records. The type name follows the hostname.
• Multiple records.: Some hostnames have multiple records. dig returns all of them; the application's choice of which to use is downstream.

Basic dig usage is foundational. DNS investigation starts here.

Specific resolver

By default, dig uses the system resolver. Specifying a different resolver lets the team test specific resolution paths; useful when the system resolver is suspect.

• dig @8.8.8.8 api.example.com queries Google DNS.: The @ notation specifies a resolver. dig queries the specified resolver; bypasses the system resolver; the result reflects the specified resolver's view.
• Useful when suspecting your resolver.: When local DNS resolution is failing, querying a public resolver isolates the issue. If 8.8.8.8 returns the answer correctly, the issue is local; if not, the issue is upstream.
• Compare resolvers.: The team can query multiple resolvers; compare answers; identify resolution discrepancies. DNS issues often stem from cache differences; comparison reveals them.
• Specify the authoritative server.: dig @ns1.example.com api.example.com queries the authoritative server directly. The answer is from the authoritative source; intermediate caches are bypassed.
• Useful for verifying changes.: When a DNS record was changed, querying the authoritative server verifies the change took effect. Caches may still hold the old value; the authoritative answer is current.

Specific resolver queries are how dig handles DNS investigation across the resolution chain.

Debugging

dig has many options for debug output. The team uses different combinations for different needs; clean output for scripts; verbose for investigation.

• +short for clean output.: +short reduces the output to just the answer. No headers, no metadata; just the IP address or whatever was queried. Useful for scripting.
• +noall +answer for just answer.: The combination shows just the answer section. More than +short but less than full output; the answer with its TTL and type is visible.
• Compose for parsing.: The output combinations support parsing in scripts. The team's automation extracts specific fields; the dig output is structured enough.
• +stats for query timing.: When investigating slow DNS, +stats shows the query time. Slow queries surface; the team correlates with network or resolver issues.
• +norec for non-recursive.: Sometimes the team wants to query only what the server has directly; +norec disables recursion. Useful for understanding cache state.

dig and host are one of those tooling skills that pay off in DNS investigations. Nova AI Ops integrates with DNS observability, surfaces resolution patterns, and complements local-tool investigation.