DNS Troubleshooting With Kali Linux

DNS is the layer that turns names like example.com into the addresses your services actually connect to — and when it misbehaves, everything downstream looks broken for reasons that have nothing to do with your application. This lesson teaches DNS fundamentals and the query tools Kali ships (dig, nslookup, host) through the everyday problems a DevOps engineer hits: a site that won’t resolve, a stale record after a migration, a load balancer returning the wrong address, and email or domain-verification records that won’t validate.

The DNS lookups here are read-only queries against public domains and public resolvers, so they’re safe to run anywhere. As always in this series: only test systems you own or are explicitly authorized to test — though simply querying public DNS is a benign, everyday operation.

What DNS Actually Does

DNS (the Domain Name System) is a distributed, hierarchical database that maps human-friendly names to machine-usable data — most commonly IP addresses. When you type example.com, your machine asks a resolver (a DNS server that does the lookup work on your behalf), which walks the hierarchy from the root, to the .com servers, to the authoritative name servers for the domain, and returns an answer.

Two roles matter for troubleshooting, and confusing them is the single most common source of DNS confusion:

Role	What it is	Example
Resolver (recursive)	The server that does the lookup and caches the result	1.1.1.1, 8.8.8.8, your corporate DNS
Authoritative	The name server that holds the real records for a domain	The domain’s NS records

The authoritative servers are the source of truth. Resolvers hold cached copies that can be stale. When “it works on my laptop but not in production,” you’re almost always looking at two different resolvers with two different cached views of the same name.

🛠️ DevOps Perspective — Almost every “the service is down” page that turns out to be DNS follows the same shape: the record is correct at the authoritative server but a resolver somewhere — a container’s resolver, a cloud VPC resolver, a cached negative answer — is still serving the old value. Learning to query both sides directly is what turns a two-hour outage into a two-minute diagnosis.

DNS Record Types You’ll Meet

You don’t need every record type, but a DevOps engineer runs into this handful constantly:

Record	Purpose	Typical value
A	Maps a name to an IPv4 address	example.com → 93.184.216.34
AAAA	Maps a name to an IPv6 address	example.com → 2606:2800:220:1:...
CNAME	Alias: “this name is really that name”	www → example.com
MX	Where email for the domain is delivered	10 mail.example.com
TXT	Arbitrary text; used for SPF, DKIM, verification	"v=spf1 include:_spf.example.com ~all"
NS	The authoritative name servers for the domain	a.iana-servers.net
PTR	Reverse lookup: IP address back to a name	34.216.184.93.in-addr.arpa → example.com
SOA	”Start of Authority” — zone metadata and serial	Contains the zone serial number

Two rules save a lot of grief:

• A CNAME can’t coexist with other records at the same name, which is why you can’t put a CNAME on a bare/apex domain (example.com) — that’s what “CNAME at apex” errors are about.
• Every record carries a TTL (time to live), explained next, that controls how long resolvers are allowed to cache it.

TTL: the number that explains “propagation”

TTL is the number of seconds a resolver may cache a record before it must ask again. There is no magic “DNS propagation” process pushing changes around the internet — what people call propagation is simply resolvers worldwide holding cached copies until their TTL expires and they re-query.

• A record with TTL 3600 can be served from cache for up to an hour after you change it.
• Lowering TTL to 300 (5 minutes) before a planned migration means resolvers re-fetch sooner, shrinking your cut-over window.
• You must lower the TTL far enough in advance that the old, high TTL has already expired everywhere — otherwise the old value lingers for the old duration.

💡 Note — “It hasn’t propagated yet” almost always means “a resolver is still inside the old TTL window.” You can see exactly how many seconds remain by watching the TTL count down in dig answers (covered below).

The Query Tools Kali Ships

Kali comes with the standard trio pre-installed. On a plain Debian/Ubuntu box you’d get them with apt install dnsutils bind9-host. Each has a niche.

dig — the DevOps default

dig (Domain Information Groper) is the most precise and scriptable of the three, and the one you should reach for first. Its output shows the full picture: the answer, the TTL, which server responded, and the query flags.

dig example.com A

This asks your default resolver for the A record of example.com. The output has labeled sections — the important ones are ANSWER SECTION (the records returned) and, near the bottom, SERVER (which resolver actually answered).

;; ANSWER SECTION:
example.com.        3600    IN    A    93.184.216.34

;; SERVER: 1.1.1.1#53(1.1.1.1)

Read that answer line left to right: the name, the TTL in seconds (3600), the class (IN), the type (A), and the value. Watch that TTL on repeated queries — it counts down as the resolver’s cache ages, then resets when the resolver re-fetches.

You can query any record type by name, and point at a specific server with @:

dig example.com MX          # mail servers
dig example.com TXT         # SPF/DKIM/verification text
dig example.com NS          # authoritative name servers
dig @1.1.1.1 example.com A  # ask Cloudflare's resolver specifically
dig @8.8.8.8 example.com A  # ask a second public resolver to compare

That @server syntax is the heart of DNS troubleshooting: it lets you ask different resolvers the same question and compare their answers.

dig +short — clean, scriptable output

Full dig output is great for a human but noisy for a script. +short prints just the answer values.

dig +short example.com A
# 93.184.216.34

This is what you pipe into checks, health probes, and CI assertions — for example, confirming a deployment points a hostname at the address you expect.

dig +trace — follow the delegation from the root

+trace makes dig do the resolver’s job itself, walking the hierarchy from the root servers down to the authoritative servers and printing each hop.

dig +trace example.com

Use it when you suspect the problem is delegation — the chain of NS records that hands a domain from .com down to its real name servers. If the trace stalls or shows unexpected name servers at a hop, you’ve found where the domain is misconfigured, independent of any resolver’s cache.

🔎 Troubleshooting Tip — +trace deliberately bypasses your local resolver’s cache and asks the authoritative chain directly. If dig example.com (via your cached resolver) and dig +trace example.com disagree, your resolver is serving a stale cached answer — the fix is usually to wait out the TTL or flush that resolver, not to change the DNS records.

nslookup — interactive and cross-platform

nslookup is older and less detailed than dig, but it’s present almost everywhere (including Windows), which makes it handy when you’re on someone else’s machine.

nslookup example.com                 # basic A/AAAA lookup
nslookup example.com 1.1.1.1         # query a specific resolver
nslookup -type=MX example.com        # request a specific record type

It also has an interactive mode (run nslookup with no arguments, then type queries), but for scripting and precision, prefer dig.

host — quick and readable

host is the terse, human-friendly option — perfect for a fast sanity check.

host example.com            # A, AAAA, and MX in a compact summary
host -t TXT example.com     # just the TXT records
host 93.184.216.34          # reverse lookup (PTR) from an IP

When you just want a yes/no “does this name resolve, and to what,” host gives it in one line.

Tool	Best for	Notable trait
dig	Precise, scriptable diagnostics	Shows TTL, server, flags; @server, +short, +trace
nslookup	Cross-platform / Windows parity	Interactive mode; less detail
host	Quick human-readable checks	One-line summaries

Real DevOps DNS Scenarios

Scenario 1: “The website won’t resolve”

A teammate reports app.example.com is unreachable. Before blaming the app, confirm DNS returns anything:

dig +short app.example.com A

• Empty output → the name has no A record from this resolver. Check whether the record exists at all by asking the authoritative server (Scenario 2) or running dig +trace.
• An address comes back → DNS is fine; the problem is connectivity or the service itself, and you move on to curl/nmap (see the cross-links at the end).

Also check the dig status. NXDOMAIN means the name genuinely doesn’t exist; SERVFAIL means the resolver couldn’t complete the lookup (often a DNSSEC or upstream problem, not a missing record).

Scenario 2: Wrong A record after a migration

You moved app.example.com to a new server, but some users still land on the old one. Compare what different resolvers believe, and compare each against the authoritative name server:

# What the domain's own name servers say (the source of truth)
dig example.com NS +short                 # find the authoritative servers
dig @a.iana-servers.net app.example.com A # ask one of them directly

# What public resolvers are currently caching
dig @1.1.1.1 app.example.com A +short
dig @8.8.8.8 app.example.com A +short

If the authoritative server returns the new address but a resolver still returns the old one, that resolver is inside the old TTL window — a caching issue, not a record error. If the authoritative server itself returns the old address, the record was never actually updated at the source.

🔎 Troubleshooting Tip — This “authoritative vs. resolver” comparison is the most valuable DNS diagnostic you can learn. dig @<resolver> tells you what’s cached; dig @<authoritative-NS> (or dig +trace) tells you what’s true. When they disagree, the record is correct and you’re waiting on a TTL.

Scenario 3: DNS propagation and TTL

Before a planned cut-over, inspect the current TTL so you know how long the old value can survive in caches:

dig app.example.com A          # read the TTL in the ANSWER SECTION

If the TTL is 3600, lower it to 300 at least an hour (one full old-TTL) ahead of the change. After the change, you can watch a resolver’s cache expire in real time by re-querying and watching the countdown:

dig @1.1.1.1 app.example.com A | grep -E "IN\s+A"
# run it again a few seconds later — the TTL number drops each time

When that number hits zero and resets, the resolver has re-fetched — for that resolver, the cut-over is complete.

🛠️ DevOps Perspective — Plan migrations around TTL, not luck. Lower TTL well in advance, make the change, verify the authoritative answer immediately, then track public resolvers catching up. Raise the TTL back afterward so you’re not paying for constant re-lookups.

Scenario 4: TXT records — SPF, DKIM, and domain verification

TXT records carry the text that other systems validate against: email authentication (SPF and DKIM) and the “add this record to prove you own the domain” checks from cloud and SaaS providers.

dig +short example.com TXT              # SPF and general TXT records
dig +short google._domainkey.example.com TXT   # a DKIM key at its selector
dig +short _dmarc.example.com TXT       # DMARC policy

Common failures this catches:

• Email marked as spam / failing DMARC → the SPF (v=spf1 ...) record is missing an include: for a sending service, or there are two SPF records (only one is allowed).
• A verification check that “won’t validate” → the TXT value has a typo, extra quotes, or was added at the wrong name (e.g. on www instead of the apex). dig +short TXT shows the exact bytes the resolver returns, which is what the validator sees.

🔐 Security Note — SPF, DKIM, and DMARC are the records that stop attackers from spoofing your domain in email. When you verify them with dig, you’re confirming that anti-spoofing protection is actually published — a small check with a large security payoff.

Scenario 5: Reverse DNS (PTR)

A PTR record maps an IP address back to a name — the reverse of an A record. It matters most for mail deliverability (many mail servers reject senders whose IP has no matching reverse record) and for making logs readable.

dig -x 93.184.216.34 +short    # reverse lookup via dig
host 93.184.216.34             # the same, in host's compact form

The -x flag tells dig to build the special in-addr.arpa query for you. If a mail server’s IP returns no PTR — or a PTR that doesn’t match its A record (forward-confirmed reverse DNS) — expect deliverability problems.

Scenario 6: Load balancers and API hostnames

Cloud load balancers and API gateways are usually reached through a CNAME that points at a provider-managed hostname, which in turn resolves to a rotating set of addresses. Follow the chain to see what’s really happening:

dig api.example.com            # shows the CNAME → target → A records in ANSWER
dig +short api.example.com     # just the resolved addresses

• Multiple A records returned for one name is normal for a load balancer — it’s DNS-level distribution, and the set can change between queries as the provider scales.
• If your app connects to a stale load-balancer address, remember the addresses behind these CNAMEs can change frequently and often have low TTLs for exactly that reason — a client caching them too long (or ignoring TTL) is a classic bug.

🔎 Troubleshooting Tip — When an API is intermittently unreachable, run dig api.example.com a few times and watch whether the CNAME target or the address set changes. If your service pins to one address instead of re-resolving, you’ll break every time the provider rotates. Re-resolve on the TTL, don’t cache addresses forever.

Try It: A Safe DNS Walk-Through

🧪 Try It — Every command here is a read-only lookup against public infrastructure, so it’s safe from any machine. Run them in order and read the differences:

dig example.com A                    # the A record, with its TTL
dig +short example.com A             # just the address
dig example.com NS +short            # the authoritative name servers
dig +trace example.com               # walk root → .com → authoritative
dig @1.1.1.1 example.com A +short    # ask Cloudflare's resolver
dig @8.8.8.8 example.com A +short    # ask a second public resolver
dig -x 93.184.216.34 +short          # reverse lookup (PTR)
host example.com                     # the compact one-line summary

Note whether the two public resolvers agree, and compare the plain dig answer with dig +trace. When they match, DNS is healthy; when they don’t, you’ve just isolated a caching or delegation problem — the exact skill these scenarios are built on.

Troubleshooting Checklist

When a name “doesn’t work,” walk this order:

1. Does it resolve at all? dig +short name A — empty means no record from this resolver.
2. Check the status. NXDOMAIN = doesn’t exist; SERVFAIL = resolver couldn’t complete (often DNSSEC/upstream); NOERROR with no answer = the name exists but has no record of that type.
3. Compare resolver vs. authoritative. dig @1.1.1.1 name vs. dig +trace name or dig @<NS> name. Disagreement = caching/TTL, not a bad record.
4. Read the TTL. A high TTL explains why an old value is lingering.
5. Right record type at the right name? TXT/verification and CNAME-at-apex mistakes hide here.

⛔ Production Warning — DNS queries are safe and read-only, but changing records is not. Editing a zone — especially TTLs, NS, or MX on a production domain — can take mail or a whole site offline, and the old values can persist in caches for the full length of the previous TTL. Make record changes only on domains you administer, understand the current TTL before you touch anything, and change one thing at a time.

Where to Go Next

DNS is one layer of the diagnostic stack. To keep building the picture:

• Networking Fundamentals — how addresses, ports, and routing sit underneath the names you just resolved.
• HTTP and API Troubleshooting — once a name resolves, this is how you test that the service behind it actually responds correctly.

For broader, cross-cutting troubleshooting playbooks that tie DNS, HTTP, and connectivity together, browse the guides library.

What You Learned

• DNS maps names to data through a hierarchy of resolvers and authoritative servers — and most “outages” are really a resolver serving a stale cached answer, not a broken record.
• The record types a DevOps engineer lives with — A, AAAA, CNAME, MX, TXT, NS, PTR — each answer a specific operational question, and TTL controls how long any of them can be cached.
• dig is the precise default (+short for scripts, +trace to follow delegation, @server to target a resolver), with nslookup and host as cross-platform and quick-check alternatives.
• Comparing authoritative answers against resolver answers (dig +trace or dig @<NS> vs. dig @1.1.1.1) is the single most valuable DNS diagnostic — disagreement means a caching/TTL issue, not a record error.
• Real scenarios follow patterns — failed resolution, stale A records after migration, TTL-driven “propagation,” TXT/SPF/DKIM validation, PTR for mail, and rotating load-balancer/API addresses — and the same handful of dig queries diagnoses them all.