I was debugging some DNS issues and needed to check what records were resolving to.

Basic lookup:

dig example.com

Get just the answer:

dig +short example.com

Specific record types Link to heading

A records (IPv4):

dig A example.com

AAAA records (IPv6):

dig AAAA example.com

CNAME records:

dig CNAME www.example.com

MX records (mail):

dig MX example.com

TXT records:

dig TXT example.com

Query specific DNS server Link to heading

Useful for checking if a change has propagated:

dig @8.8.8.8 example.com
dig @1.1.1.1 example.com

Trace the resolution Link to heading

See the full resolution path:

dig +trace example.com

This shows each step from root servers down to your answer.

Quick reference Link to heading

dig +short example.com        # Just the IP
dig +noall +answer example.com # Clean output
dig -x 1.2.3.4                # Reverse lookup

Real debugging scenario Link to heading

Last month I was investigating why our staging environment wasn’t accessible. The domain was staging.example.com and it was timing out intermittently.

Here’s how I debugged it:

  1. Check what it resolves to locally:

    dig +short staging.example.com

    Got back an IP: 34.123.45.67

  2. Check if it’s a CNAME:

    dig staging.example.com

    Output showed it was a CNAME pointing to a load balancer: lb-prod-xyz.eu-west-2.elb.amazonaws.com

  3. Check what the CNAME resolves to:

    dig +short lb-prod-xyz.eu-west-2.elb.amazonaws.com

    Got multiple IPs (load balancer)

  4. Query Cloudflare’s DNS directly (our DNS provider):

    dig @1.1.1.1 staging.example.com

    Same result as local

  5. Check if it’s cached (query an authoritative nameserver):

    dig +trace staging.example.com

    This showed the full chain and revealed that the CNAME was correct.

The issue turned out to be firewall rules blocking our office IP from the load balancer. But dig helped rule out DNS as the problem within 2 minutes. Without it, I would have wasted time checking application logs, Kubernetes pods, etc.

The key insight was using +trace to verify the CNAME was correct all the way from the root servers, and querying @1.1.1.1 to confirm Cloudflare was serving the right record.

dig vs nslookup vs dog Link to heading

nslookup is the old tool that most people learn first. It works, but the output is verbose and harder to parse. I used to use it but switched to dig years ago and never looked back. The only reason to use nslookup is if you’re on a system that doesn’t have dig installed (rare these days).

dig is the recommended choice. Better output, more control over query types, and widely available on Linux and macOS. The +short flag alone makes it worth using over nslookup.

dog is a modern DNS client written in Rust. It has nice coloured output and JSON support. I tried it briefly but honestly didn’t see enough improvement over dig to justify learning new flags. If you’re starting fresh, it’s worth trying though.

My take: learn dig properly and you’ll be fine. It’s ubiquitous and powerful enough for 99% of DNS debugging.