Advanced DNS Troubleshooting on macOS with dig and nslookup (2026)

DNS failures often look alike from an application. A stale cache, broken delegation, or bad DNSSEC signature can all cause a timeout or SERVFAIL.

Use a fixed process. Ask the same DNS question at each layer: the Mac’s resolver, public resolvers, and every authoritative server. This usually finds the owner before the ticket tours the building.

Prerequisites

Tested on macOS 15 Sequoia and macOS 26 Tahoe in August 2026. These commands also work on many Linux and Unix systems. Resolver settings and cache commands vary by platform.

You need:

• A macOS account with Terminal access
• dig, nslookup, scutil, and dscacheutil
• Outbound DNS access to recursive and authoritative servers
• The domain name, expected record type, and expected value
• Administrative access only when clearing the macOS DNS cache

Confirm the tools are present:

command -v dig
command -v nslookup
dig -v

Expected output resembles:

/usr/bin/dig
/usr/bin/nslookup
DiG 9.x.x

Exact versions vary between macOS releases. The DNS fields used here are stable across current dig versions.

Use example.com for practice, then replace it with the affected domain. Some corporate networks block direct access to public resolvers. Others redirect DNS without telling you. That’s worse because the command appears to work.

Quick Diagnosis

Run these checks before changing records or clearing caches. A cache flush removes useful evidence, including the stale value and its remaining TTL.

1. Identify the Mac’s configured resolvers

scutil --dns

Find the active resolver block and its nameserver[0] entries:

resolver #1
nameserver[0] : 192.0.2.53
flags : Request A records
reach : Reachable

macOS can assign separate resolvers to VPNs, scoped interfaces, and specific domains. scutil --dns is more reliable than /etc/resolv.conf, which omits some active resolver paths.

2. Query the local resolver

dig example.com A

This uses the resolver chosen by the system. Keep the SERVER line because it shows which resolver answered.

3. Compare two public resolvers

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

The @server argument sends the query straight to that resolver. It bypasses the local recursive cache. Each public resolver can still return its own cached answer.

4. Discover the authoritative nameservers

dig example.com NS +short

Expected output resembles:

elliott.ns.cloudflare.com.
hera.ns.cloudflare.com.

5. Query an authoritative server directly

dig @elliott.ns.cloudflare.com example.com A +norecurse

+norecurse clears the recursion-desired bit. This keeps the test focused on data from the chosen nameserver.

6. Trace the delegation if the authoritative path looks wrong

dig example.com A +trace

The trace follows referrals from the root servers to the top-level domain, then the authoritative server. It works well for delegation faults. It won’t reproduce a cached result from a normal validating resolver.

How to Read a dig Response

A full response gives you more evidence than +short:

dig example.com A

Representative output:

; <<>> DiG 9.x.x <<>> example.com A
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31872
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; QUESTION SECTION:
;example.com. IN A

;; ANSWER SECTION:
example.com. 287 IN A 192.0.2.10

;; Query time: 18 msec
;; SERVER: 192.0.2.53#53(192.0.2.53)
;; WHEN: Thu Aug 6 05:00:00 UTC 2026
;; MSG SIZE rcvd: 56

Read it in this order:

• Status: NOERROR, NXDOMAIN, or SERVFAIL shows whether the server completed the query.
• Flags: These show how the server handled the query and response.
• ANSWER section: This contains the returned record, if one exists.
• TTL: The number before IN is the remaining lifetime in seconds.
• SERVER: This shows which resolver answered.
• Query time: High or uneven times can point to delay or reachability trouble.

The ANSWER line has five fields:

example.com. 287 IN A 192.0.2.10

They mean:

Field	Example	Meaning
Owner name	example.com.	Name to which the record belongs
TTL	287	Remaining cache lifetime in seconds
Class	IN	Internet DNS class
Type	A	Record type
Data	192.0.2.10	Record value

A cached TTL normally counts down. Repeat the query after 10 seconds, and 287 should fall to about 277. An authoritative response usually shows the zone’s set TTL instead of a falling cache timer.

Important flags include:

Flag	Meaning	Diagnostic value
aa	Authoritative Answer	The responding server claims authority for the answer
rd	Recursion Desired	The client requested recursion; dig enables it by default
ra	Recursion Available	The server says it supports recursion
ad	Authenticated Data	A validating resolver says the answer passed DNSSEC validation
cd	Checking Disabled	The client asked the resolver not to perform DNSSEC validation
tc	Truncated	The UDP response was too large; retry over TCP

Don’t treat ra as proof that a response is authoritative. A normal recursive response has rd ra. A direct authoritative response often has aa without ra.

Common Issues and Solutions

Problem: Different resolvers return different record values

Symptoms:

• The hostname works for some users but not others.
• The local resolver returns an old address.
• Google Public DNS and Cloudflare DNS disagree.
• TTL values differ widely between resolvers.

Why it happens: Each recursive resolver has its own cache. After a record change, answers can differ until old cached records expire. Other causes include uneven authoritative servers, split-horizon DNS, and DNSSEC behavior.

Fix:

Query the same name and type through the local resolver and both public resolvers:

printf 'Local resolver:\n'
dig example.com A +noall +answer

printf 'Google Public DNS:\n'
dig @8.8.8.8 example.com A +noall +answer

printf 'Cloudflare DNS:\n'
dig @1.1.1.1 example.com A +noall +answer

Expected comparison:

Local resolver:
example.com. 84 IN A 192.0.2.10
Google Public DNS:
example.com. 231 IN A 192.0.2.20
Cloudflare DNS:
example.com. 207 IN A 192.0.2.20

The local resolver has the old value with 84 seconds left. Both public resolvers return the new value. This points to a stale local or upstream cache.

Direct queries to 8.8.8.8 and 1.1.1.1 bypass the local resolver’s cache. They still use public caches, so check the authoritative servers before calling the zone correct.

Verification:

Wait longer than the old answer’s remaining TTL, then repeat the local query:

dig example.com A +noall +answer

If the local answer matches the public resolvers, the cause was a stale recursive cache. If it still differs, check every authoritative server.

Problem: A resolver keeps returning an old record

Symptoms:

• The returned value remains old after its displayed TTL should have expired.
• The TTL resets instead of reaching zero.
• Flushing the Mac’s cache doesn’t change the answer.
• Different clients using the same upstream resolver get the old value.

Why it happens: The stale value may be in macOS, a network resolver, or a public recursive service. One authoritative server may still publish it. Clearing the Mac’s cache can’t remove upstream data.

Fix:

First, query twice and watch whether the TTL falls:

dig example.com A +noall +answer

Run the same command again after a short wait. A normal cached answer should return with a smaller TTL.

Next, find the authoritative nameservers:

dig example.com NS +short

Query each returned server. Replace these names with the real results:

dig @ns1.example.net example.com A +norecurse +noall +answer
dig @ns2.example.net example.com A +norecurse +noall +answer

If every authoritative server has the new value, the old recursive result should vanish after its TTL expires. If one server still has the old value, fix the zone or its sync first.

Clear the local macOS cache only after you confirm the authoritative data:

sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

These commands normally print nothing. They affect only the Mac’s cache. Routers, VPN gateways, ISP resolvers, and public DNS services carry on regardless.

Verification:

dig example.com A +noall +answer
dig @8.8.8.8 example.com A +noall +answer
dig @1.1.1.1 example.com A +noall +answer

The record values should match. TTLs can differ because each resolver cached the answer at a different time.

Problem: Authoritative nameservers return inconsistent data

Symptoms:

• Responses alternate between old and new values.
• One authoritative server returns NXDOMAIN.
• Only some users see the record.
• A direct authoritative query lacks the intended record.
• One nameserver times out while the others answer.

Why it happens: Common causes include failed zone transfers, an unpublished provider change, stale secondary servers, different zone serials, or delegation to an old provider.

Fix:

Find the delegated nameservers through a recursive resolver:

dig example.com NS +short

Then query each nameserver directly:

dig @ns1.example.net example.com A +norecurse
dig @ns2.example.net example.com A +norecurse

Look for:

• The same A or AAAA value
• The aa flag
• The same response status
• Similar authoritative TTLs
• No unexpected CNAME chain
• No timeout from any server

Check each server’s Start of Authority record:

dig @ns1.example.net example.com SOA +norecurse +noall +answer
dig @ns2.example.net example.com SOA +norecurse +noall +answer

Representative output:

example.com. 3600 IN SOA ns1.example.net. hostmaster.example.com. 2026080601 3600 900 1209600 300

The long integer is usually the zone serial. Different serials can show that a secondary hasn’t loaded the current zone. Providers with hidden masters or generated zones may handle serials differently, so compare the records too.

Verification:

Every delegated authoritative server should return the intended answer:

dig @ns1.example.net example.com A +norecurse +noall +answer
dig @ns2.example.net example.com A +norecurse +noall +answer

One stale or dead server means the fault is still active. Intermittent DNS has an annoying habit of passing the one test run during a maintenance call.

Problem: The delegation path fails

Symptoms:

• Recursive queries return SERVFAIL.
• Direct queries work only when you already know the authoritative server.
• Parent and child zones list different nameservers.
• A recently changed nameserver set isn’t being used.
• Glue records point to the wrong addresses.

Why it happens: The parent zone may have the wrong NS delegation or glue records. The child zone may list a different NS set. A listed server may also lack authority for the domain.

Fix:

Follow the delegation path:

dig example.com A +trace

Representative stages:

. 518400 IN NS a.root-servers.net.
com. 172800 IN NS a.gtld-servers.net.
example.com. 172800 IN NS ns1.example.net.
example.com. 300 IN A 192.0.2.20

Check the first stage with an unexpected result:

• The root response should refer the query to the correct top-level-domain servers.
• The top-level-domain response should list the intended authoritative nameservers.
• Glue A or AAAA records must be correct when required.
• The final server must answer with authority for the child zone.

+trace sends iterative queries directly. It can fail on networks that block direct DNS, even when the system resolver works. Test from another network before you rewrite a sound delegation.

Verification:

Query the parent delegation and child zone separately:

dig @a.gtld-servers.net example.com NS +norecurse
dig @ns1.example.net example.com NS +norecurse

Use the correct parent server for domains outside .com. The parent and child NS sets should match the intended design.

Problem: A specific record type is missing or wrong

Symptoms:

• IPv4 works but IPv6 fails.
• A web alias resolves to the wrong target.
• Mail delivery fails despite the domain resolving.
• Domain verification can’t find a TXT value.
• A nameserver migration appears incomplete.

Why it happens: A general lookup can hide the record type that matters. Query each type directly and check its fields.

Fix:

Run focused queries:

dig example.com A +noall +answer
dig example.com AAAA +noall +answer
dig www.example.com CNAME +noall +answer
dig example.com MX +noall +answer
dig example.com TXT +noall +answer
dig example.com NS +noall +answer

Check each type as follows:

Type	What to verify
A	Correct IPv4 address; no stale address remains
AAAA	Correct IPv6 address; the target service actually accepts IPv6 traffic
CNAME	Target is correct and terminates in address records; avoid conflicting data at the same owner name
MX	Mail exchanger names and numeric priorities are correct; lower numbers have higher preference
TXT	Exact text, quoting, and all required chunks are present
NS	Delegated servers match the intended provider and answer authoritatively

A blank ANSWER section with status: NOERROR usually means NODATA. The name exists, but the requested record type doesn’t. NXDOMAIN means the name itself doesn’t exist. This difference affects negative caching and shows which record needs work.

For mail, query the returned exchanger directly:

dig example.com MX +short
dig mail.example.com A +short
dig mail.example.com AAAA +short

For a CNAME chain, keep the full output. You need to see both the alias and final address:

dig www.example.com A

Verification:

Repeat the affected record-type query against an authoritative server:

dig @ns1.example.net example.com MX +norecurse +noall +answer

Change MX and the owner name to match the service under test.

Problem: DNSSEC validation causes SERVFAIL

Symptoms:

• A validating resolver returns SERVFAIL.
• The same query works when checking is disabled.
• Direct authoritative queries return records, but recursive resolution fails.
• The expected ad flag is missing.
• Failures began after DNSSEC keys, signatures, or nameservers changed.

Why it happens: A broken chain of trust can make valid records unusable. Common faults include an old DS record at the parent, missing or expired RRSIG records, a wrong DNSKEY, or uneven signing across authoritative servers.

+dnssec sets the DNSSEC OK bit and asks for DNSSEC records. It doesn’t make dig validate the chain locally. That detail prevents a fair amount of false confidence.

Fix:

Ask a validating resolver for DNSSEC data:

dig @1.1.1.1 example.com A +dnssec

Check the status and flags. A response that passed validation may contain ad:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR
;; flags: qr rd ra ad

Now ask the same resolver to disable checks for this query:

dig @1.1.1.1 example.com A +dnssec +cdflag

If the normal query returns SERVFAIL and the +cdflag query returns the record, DNSSEC validation is the likely cause.

Check the chain parts:

dig @1.1.1.1 example.com DS +dnssec
dig @1.1.1.1 example.com DNSKEY +dnssec
dig example.com A +trace +dnssec

Then compare the authoritative servers:

dig @ns1.example.net example.com DNSKEY +dnssec +norecurse
dig @ns2.example.net example.com DNSKEY +dnssec +norecurse
dig @ns1.example.net example.com A +dnssec +norecurse
dig @ns2.example.net example.com A +dnssec +norecurse

Don’t remove DS records on instinct. Compare the parent DS record with the active child DNSKEY set. Then confirm every authoritative server has current signatures. Removing a DS record can restore service, but it also removes the chain of trust.

Verification:

dig @8.8.8.8 example.com A +dnssec
dig @1.1.1.1 example.com A +dnssec

Both validating resolvers should return NOERROR. Valid signed data normally gets the ad flag. Resolver policy and the security of your path to that resolver can affect it.

Problem: dig and nslookup appear to disagree

Symptoms:

• dig shows one address while nslookup appears to show another.
• One command returns IPv6 data and the other returns IPv4.
• The tools report different DNS servers.
• Search-domain expansion changes the queried name.

Why it happens: The tools format results in different ways. A bad comparison may also use different record types, resolvers, or names after search-domain expansion.

dig is usually the better diagnostic tool. It shows flags, sections, TTLs, status codes, DNSSEC records, and trace controls. nslookup remains useful for old support procedures and quick checks. Its output gives you less evidence when DNS gets strange.

Fix:

Set the same full domain name, record type, and resolver:

dig @1.1.1.1 example.com. A
nslookup -type=A example.com. 1.1.1.1

The trailing dot makes the name absolute. It stops a search domain from quietly changing the query.

Compare the returned A values, not the formatting around them. Confirm that dig reports:

;; SERVER: 1.1.1.1#53(1.1.1.1)

The matching nslookup output should name the same server:

Server: 1.1.1.1
Address: 1.1.1.1#53

Verification:

Both tools should return the same record set when the server, name, and type match. Use dig when you need TTLs, flags, DNSSEC details, or authority tracing.

Problem: DNS queries time out or work intermittently

Symptoms:

• dig reports communications error or no servers could be reached.
• Only one resolver times out.
• UDP queries fail while TCP succeeds.
• Queries work off VPN but fail when connected.
• Some authoritative servers answer while others don’t.

Why it happens: A timeout doesn’t prove the DNS data is wrong. Packet loss, firewall rules, VPN routes, resolver failure, blocked direct DNS, broken IPv6, and large responses can cause the same symptom.

Fix:

Test the local and public resolvers separately:

dig example.com A +time=2 +tries=1
dig @8.8.8.8 example.com A +time=2 +tries=1
dig @1.1.1.1 example.com A +time=2 +tries=1

+time=2 waits two seconds per attempt. +tries=1 prevents retries from hiding a failed first attempt. These values are deliberately impatient. Use longer ones on high-delay links.

Retry over TCP:

dig @1.1.1.1 example.com A +tcp +time=3 +tries=1

If TCP works while UDP fails, check the firewall, VPN, and path Maximum Transmission Unit. DNS usually starts over UDP. TCP handles cut-off replies and larger exchanges.

Test every authoritative server:

dig @ns1.example.net example.com A +norecurse +time=2 +tries=1
dig @ns2.example.net example.com A +norecurse +time=2 +tries=1

Check basic route reachability, but don’t mistake ping for a DNS test:

route -n get 1.1.1.1
ping -c 4 1.1.1.1

A blocked ping doesn’t prove DNS is down. The dig result tests the service you care about.

Verification:

Repeat the query several times. Confirm that each required recursive and authoritative server answers over the expected transport. One good reply proves little when the fault comes and goes.

Error Messages Quick Reference

Error or status	Meaning	First check
status: NOERROR with an answer	Query succeeded	Verify value, type, TTL, and responding server
status: NOERROR with no answer	Name may exist but lack that record type	Query A, AAAA, CNAME, and SOA as appropriate
status: NXDOMAIN	Queried name doesn’t exist according to the response	Check spelling, search suffixes, authority, and negative caching
status: SERVFAIL	Server couldn’t complete the query	Test DNSSEC with +cdflag, then inspect delegation and authoritative reachability
status: REFUSED	Server policy rejected the query	Confirm the server accepts queries from your source and whether recursion was requested
status: FORMERR	Server rejected the query format	Retry without uncommon options and compare another server
connection timed out; no servers could be reached	No usable response arrived	Test each resolver, TCP, VPN routing, and firewall policy
communications error ... timed out	A particular destination didn’t answer in time	Record the destination and compare local, public, and authoritative servers
WARNING: recursion requested but not available	Query set rd, but server didn’t set ra	Expected on many authoritative servers; use +norecurse
flags: ... tc ...	UDP response was truncated	Retry with +tcp
Missing aa	Response isn’t marked authoritative	Confirm you queried an authoritative server directly
Missing ad	Resolver didn’t assert successful DNSSEC validation	Confirm the zone is signed, the resolver validates, and the chain is intact
Old record with decreasing TTL	Recursive cache still holds the prior answer	Wait for TTL expiry and compare authority
Old record at an authoritative server	Source zone still publishes old data	Fix zone data or secondary synchronization

Platform-Specific Issues on macOS

macOS uses an unexpected resolver

VPN clients, configuration profiles, and split DNS can create scoped resolvers. Check the full resolver state:

scutil --dns

Pay attention to:

• domain and search domain entries
• nameserver addresses
• if_index interface scope
• Resolver order
• VPN-specific supplemental domains

A query to @1.1.1.1 tests that address directly. Normal macOS applications may use a different resolver path. This often happens when a VPN provides DNS settings for specific domains.

/etc/resolv.conf does not tell the full story

The file can still give you some context:

cat /etc/resolv.conf

macOS applications normally use the system resolver framework. It can combine scoped and extra configurations. Treat scutil --dns as the main source. /etc/resolv.conf is the short version, and short versions are rarely kind during an outage.

Short names behave differently from absolute names

Search domains can turn server1 into server1.corp.example. Use a trailing dot when you need an exact public name:

dig server1.example.com. A
nslookup -type=A server1.example.com. 1.1.1.1

That final dot looks fussy, but it removes a whole class of false comparisons.

Cache clearing does not fix upstream data

Use these commands only after you confirm that the authoritative servers have the right record:

sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

No output is expected. Query the local resolver again afterward. If the upstream server still has the stale value, the Mac will fetch it again with impressive efficiency.

Configuration Issues to Check

Record name entered at the wrong zone location

DNS control panels differ in how they read host fields. Entering www.example.com in a panel that adds example.com can create www.example.com.example.com.

Check the exact owner names from authority:

dig @ns1.example.net www.example.com A +norecurse
dig @ns1.example.net www.example.com.example.com A +norecurse

This error is mundane, common, and quite able to consume an unreasonable afternoon.

CNAME conflicts with other data

A CNAME owner shouldn’t also have A, AAAA, MX, TXT, or other normal record data. Query the owner directly:

dig www.example.com CNAME
dig www.example.com A
dig www.example.com TXT

Some control panels block this conflict. Others accept the records and leave the zone loader to complain later.

MX points to a CNAME or lacks address records

An MX target should resolve to usable A or AAAA records:

dig example.com MX +short
dig mail.example.com A +short
dig mail.example.com AAAA +short

An MX record can look correct while its target leads nowhere. Follow the returned hostname to its address records.

Parent and child NS sets disagree

Compare the delegation with the authoritative zone:

dig @a.gtld-servers.net example.com NS +norecurse
dig @ns1.example.net example.com NS +norecurse

Replace the parent server for other top-level domains. The registrar controls the parent delegation. Editing only the child zone won’t change it.

TTL was lowered too late

Lowering a TTL after a change doesn’t shorten records already cached with the old TTL. Plan the reduction at least one old-TTL period before a migration.

For example, an old TTL of 86400 needs at least 24 hours of lead time. Lower it first, then wait out the old TTL. Make the record change and restore a normal TTL after the service is stable.

Split-horizon DNS is mistaken for stale cache

Internal and public resolvers may return different answers by design. Compare the exact servers:

dig @192.0.2.53 app.example.com A
dig @1.1.1.1 app.example.com A

Confirm that the difference matches the internal DNS policy before you edit either zone. Stable public and private differences can be healthy. Random differences between authoritative servers can’t.

dig and nslookup Command Cheat Sheet

Diagnostic question	Command
What does the local resolver return?	dig example.com A
What does Google Public DNS return?	dig @8.8.8.8 example.com A
What does Cloudflare DNS return?	dig @1.1.1.1 example.com A
Show only answer records	dig example.com A +noall +answer
Show compact record values	dig example.com A +short
Query IPv6 records	dig example.com AAAA
Query aliases	dig www.example.com CNAME
Query mail exchangers	dig example.com MX
Query text records	dig example.com TXT
Discover nameservers	dig example.com NS +short
Query authority directly	dig @ns1.example.net example.com A +norecurse
Inspect SOA and serial	dig @ns1.example.net example.com SOA +norecurse
Trace delegation	dig example.com A +trace
Request DNSSEC records	dig @1.1.1.1 example.com A +dnssec
Disable resolver validation for comparison	dig @1.1.1.1 example.com A +dnssec +cdflag
Query over TCP	dig @1.1.1.1 example.com A +tcp
Limit timeout and retries	dig @1.1.1.1 example.com A +time=2 +tries=1
Use nslookup with a chosen server	nslookup -type=A example.com 1.1.1.1
Query MX with nslookup	nslookup -type=MX example.com 1.1.1.1
Query TXT with nslookup	nslookup -type=TXT example.com 1.1.1.1
Show active macOS resolvers	scutil --dns

Use full dig output during diagnosis. +short is useful in scripts and quick checks. It hides the status, flags, responder, and sections that explain failures.

Getting Help

Capture evidence before you contact a DNS provider, registrar, network team, or domain owner. A ticket with one browser screenshot usually earns a request for these details two hours later.

Collect:

date -u
scutil --dns
dig example.com A
dig @8.8.8.8 example.com A
dig @1.1.1.1 example.com A
dig example.com NS
dig example.com SOA
dig example.com A +trace
dig @1.1.1.1 example.com A +dnssec

Also record:

• The affected fully qualified domain name
• The expected and actual values
• The exact record type
• The time of the DNS change in UTC
• The old and new configured TTLs
• Whether the problem occurs on VPN, off VPN, or both
• Which recursive and authoritative servers fail
• Whether +cdflag changes a SERVFAIL result
• Whether TCP works when UDP fails

Check macOS DNS events in Console.app. Filter for mDNSResponder, then reproduce the problem. For recent command-line messages:

log show --last 10m --predicate 'process == "mDNSResponder"' --info

Check logs before you share them. Search domains, internal hostnames, VPN interfaces, and private resolver addresses can expose network details.

Useful public references include the BIND 9 Administrator Reference Manual, Google Public DNS documentation, Cloudflare 1.1.1.1 documentation, and ICANN DNSSEC resources.

Prevention Tips

• Lower TTLs before migrations: Change the TTL at least one old-TTL interval before changing the record.
• Monitor every authoritative server: A single stale or unreachable server can cause intermittent failures.
• Check parent and child NS data: Registrar delegation and zone NS records should match the intended design.
• Use absolute names in tests: A trailing dot prevents search domains from changing the query.
• Record the queried resolver: Preserve the SERVER line when you collect evidence.
• Test key record types separately: A successful A lookup says nothing about AAAA, MX, TXT, or DNSSEC.
• Validate DNSSEC during changes: Check DS, DNSKEY, and signed answers before and after key or provider migrations.
• Keep before-and-after output: Saved dig results preserve exact values, TTLs, flags, and times.
• Test from more than one network: DNS interception and VPN split DNS can skew one Mac’s results.
• Don’t flush caches first: Capture the stale answer and its TTL before removing useful evidence.

Wrapping Up

Step	Action	Applies To
1	Query the Mac’s configured resolver	Local cache and split DNS
2	Compare 8.8.8.8 and 1.1.1.1	Recursive cache differences
3	Query every authority directly	Zone data and server consistency
4	Run dig +trace	Delegation and glue faults
5	Compare normal and +cdflag results	DNSSEC validation failures

Work outward one layer at a time: local resolver, public resolver, delegation, then authority. Use dig for hard cases because it keeps the useful evidence. Keep nslookup for compatibility checks and established support procedures; it hides too much detail for deeper faults.

Last updated: August 6, 2026 | Applies to dig and nslookup on macOS 15 Sequoia and macOS 26 Tahoe