DNS Query & Troubleshooting Tools
Learn how to craft precise queries, interpret responses, and build repeatable troubleshooting playbooks.
Master nslookup, dig, host, and modern PowerShell cmdlets to diagnose DNS issues quickly.
Tool Comparison Overview
| Tool | Strengths | Ideal Use Cases | Limitations |
|---|---|---|---|
| nslookup | Built into Windows and most Unix systems; interactive mode for quick resolver switching. | Ad-hoc checks, verifying resolver responses, reverse lookups. | Older syntax, limited formatting, no native trace capability. |
| dig | Rich output control (+short, +trace, +dnssec); supports scripting and benchmarking. | Detailed troubleshooting, DNSSEC validation, automation. | Not installed by default on Windows (requires BIND tools or WSL). |
| host | Minimalist utility for quick forward or reverse lookups. | Fast checks in shell scripts or pipelines. | Limited option set, no direct support for advanced flags. |
| Resolve-DnsName (PowerShell) | Modern Windows CMDlet with structured output and DNSSEC details. | Windows automation, exporting results as objects. | Requires PowerShell 3+ and differs from Unix tooling syntax. |
Common Query Patterns
| Scenario | Command | Interpretation |
|---|---|---|
| Validate cached resolver answer | nslookup example.com 1.1.1.1 | Confirms public resolver response and flags mismatched authoritative data. |
| Retrieve only IPs for automation | dig example.com A +short | Provides clean output for scripts or monitoring systems. |
| Reverse lookup PTR record | dig -x 93.184.216.34 +short | Links an IP back to a hostname, useful for attribution or SPF checks. |
| Authoritative name server trace | dig example.com +trace | Walks from root to authoritative servers, highlighting delegation breaks. |
| Check SPF / DMARC posture | nslookup -type=TXT _dmarc.example.com | Ensures email authentication records exist and are syntactically correct. |
| Detect DNSSEC signing | dig example.com +dnssec | Look for RRSIG/AD flags to verify signing and validation. |
Captured outputs should include resolver details, TTL values, and authoritative server references for auditing.
Step 1 — Replicate the User Issue
- Identify the failing hostname or service endpoint.
- Run queries from the affected host and note resolver IPs.
Step 2 — Compare Multiple Resolvers
- Query local resolver, corporate resolver, and a public resolver (1.1.1.1/8.8.8.8).
- Note discrepancies in TTL, record existence, or NXDOMAIN.
Step 3 — Inspect Authoritative Sources
- Use `dig +trace` or specify the authoritative NS directly.
- Check for outdated glue, missing records, or stale SOA serial numbers.
Step 4 — Validate Reverse and Email Records
- Ensure PTR entries align with forward hostnames.
- Inspect SPF, DKIM, and DMARC to resolve mail delivery issues.
Step 5 — Document & Remediate
- Capture commands and responses in the ticket.
- Update DNS change management with corrected records or escalate to provider.
Field Tips & Best Practices
- Always include resolver IP and timestamp when capturing evidence for incident tickets.
- Use `dig +nocmd +noall +answer` or `+short` for script-friendly output and log ingestion.
- Benchmark latency with `dig example.com @resolver +stats` to flag slow or degraded DNS services.
- Leverage split-horizon testing (internal vs external resolvers) to detect misaligned records.
- Maintain a notebook of common domains and record expectations to speed future troubleshooting.
Automate recurring checks with scheduled `dig` or `Resolve-DnsName` scripts, storing outputs in version control to spot unexpected changes.