When troubleshooting DNS issues, many sysadmins encounter puzzling situations where different DNS tools return conflicting results for the same query. Let's examine why this happens through a concrete example:

# dig @192.168.1.2 test.example.com
;; ANSWER SECTION:
test.example.com.  41  IN  CNAME  123.123.12.123.

# host test.example.com 192.168.1.2
Host test.example.com not found: 3(NXDOMAIN)

# nslookup test.example.com 192.168.1.2
server can't find test.example.com: NXDOMAIN

The root cause lies in how these tools handle DNS queries differently:

• dig: The "DNS Swiss Army knife" that shows raw DNS responses including CNAME records
• host: Simplified output that follows CNAME chains but may filter some responses
• nslookup: Behaves similarly to host but with different default query types

The original issue stemmed from an improper CNAME record configuration:

test.example.com. IN CNAME 123.123.12.123.  # Wrong: CNAME to IP
test.example.com. IN A 123.123.12.123       # Correct: A record

Here's how each tool reacted to this misconfiguration:

For correct DNS resolution, always use proper record types. Here's how the tools behave with proper A records:

# Correct configuration
$ dig @192.168.1.2 good.example.com
;; ANSWER SECTION:
good.example.com.  300 IN  A  203.0.113.45

$ host good.example.com 192.168.1.2
good.example.com has address 203.0.113.45

$ nslookup good.example.com 192.168.1.2
Non-authoritative answer:
Name:   good.example.com
Address: 203.0.113.45

When facing DNS resolution issues:

1. Always start with dig +trace to see full resolution path
2. Use dig +short for scripting purposes
3. Compare results across multiple tools
4. Check for CNAME chains ending in invalid targets

Remember that different DNS servers in your network path (resolver, forwarder, authoritative) may also affect the final result.

When troubleshooting DNS resolution, many sysadmins encounter puzzling behavior where different DNS query tools (dig, host, and nslookup) return conflicting results for the same domain. Let's examine a concrete example:

$ dig @192.168.1.2 test.example.com
;; ANSWER SECTION:
test.example.com.  41  IN  CNAME  123.123.12.123.

$ host test.example.com 192.168.1.2
Host test.example.com not found: 3(NXDOMAIN)

$ nslookup test.example.com 192.168.1.2
** server can't find test.example.com: NXDOMAIN

These utilities aren't just different interfaces to the same functionality - they have distinct behaviors:

• dig: The most comprehensive tool, showing raw DNS protocol details including EDNS, flags, and full response sections
• host: Simplified output designed for quick lookups, with different default query behavior
• nslookup: An older interactive tool with its own resolver logic

Several technical aspects explain the different results:

// Example of query type differences
dig test.example.com A      # Explicit A record query
host -t A test.example.com  # Must specify record type
nslookup -query=A test.example.com

The original case revealed a critical configuration error - using a CNAME record pointing to an IP address (invalid per RFC 1034) rather than an A record. This triggered different handling by each tool:

1. dig displayed the invalid CNAME as-is
2. host and nslookup performed additional validation

When facing inconsistent results:

# Always check multiple record types
dig test.example.com A
dig test.example.com CNAME
dig test.example.com ANY

# Verify DNSSEC validation
dig +dnssec test.example.com

# Compare recursive vs authoritative
dig +trace test.example.com

Remember that different tools may:

• Use different resolvers by default
• Apply different timeout settings
• Handle certain record types differently
• Have varying levels of EDNS support

For deeper investigation:

# Capture raw DNS traffic
sudo tcpdump -i eth0 -n -s0 port 53

# Check tool versions (behavior changes between versions)
dig -v
host -v
nslookup -version

# Test with different DNS servers
dig @8.8.8.8 test.example.com
dig @1.1.1.1 test.example.com

The solution in this case was correcting the DNS configuration by replacing the invalid CNAME with a proper A record. This made all tools return consistent results.