When performing DNS queries against specific nameservers, dig and host exhibit fundamentally different behaviors despite appearing similar on the surface. The key distinction lies in how they handle the recursion desired (RD) flag in DNS packets.

With dig (Domain Information Groper):

dig @ns1.example-nameserver.com hostname.example.com
# Explicitly sets RD=0 by default (non-recursive query)
# Directly queries the specified authoritative nameserver

With host:

host hostname.example.com ns1.example-nameserver.com
# Implicitly sets RD=1 (recursive query)
# May be rejected by authoritative nameservers not offering recursion

The RD flag difference explains why you might get different responses:

• Authoritative nameservers (like ns1.livedns.co.uk) often refuse recursive queries
• Recursive resolvers (like ISP DNS) always accept recursive queries

Example showing the actual packet difference:

# tcpdump showing host command (RD=1)
15:03:22.123456 IP client.12345 > ns1.example.com.53: 1234+ [1au] A? hostname.example.com. (45)

# tcpdump showing dig command (RD=0)
15:03:25.654321 IP client.54321 > ns1.example.com.53: 5678 A? hostname.example.com. (39)

When debugging DNS configurations:

1. Prefer dig for authoritative lookups (more reliable results)
2. Use host -r to disable recursion (mimics dig behavior)
3. Check response flags with dig +norecurse or host -v

Advanced debugging example:

dig +trace @ns1.example-nameserver.com hostname.example.com
host -v -t ANY hostname.example.com ns1.example-nameserver.com

In your specific example with cardiff.tzmchapters.org:

• The host command failed because the authoritative server refused recursive queries
• The dig command succeeded by making a non-recursive authoritative query
• The CNAME record only appeared in the dig output because it was properly queried

For comprehensive DNS troubleshooting:

# Check DNSSEC validation
dig +dnssec hostname.example.com

# Verify DNS glue records
dig +trace example.com NS

# Test specific record types
dig +noall +answer hostname.example.com CNAME
host -t CNAME hostname.example.com

While both dig and host perform DNS lookups, their underlying query mechanisms differ significantly:

// host command basic syntax
host [-t query_type] name [server]

// dig command basic syntax
dig @server name [query_type] [+additional_options]

The key behavioral differences that explain your observation:

• Recursion Handling: host typically sets the RD (Recursion Desired) flag by default, while dig leaves recursion control explicit
• Response Processing: host simplifies output, while dig shows raw DNS packet details
• Error Handling: host may terminate on certain errors where dig would show the full error response

Let's analyze your test case with technical precision:

// host command output shows NXDOMAIN
$ host cardiff.tzmchapters.org ns1.livedns.co.uk
Host cardiff.tzmchapters.org not found: 3(NXDOMAIN)

// dig reveals the actual CNAME record
$ dig @ns1.livedns.co.uk cardiff.tzmchapters.org
;; ANSWER SECTION:
cardiff.tzmchapters.org. 3600 IN CNAME ghs.google.com.

The discrepancy occurs because:

1. host follows a stricter interpretation chain
2. The nameserver configuration affects how each tool processes referrals
3. Some DNS implementations handle CNAME chains differently

For comprehensive DNS debugging, combine both tools:

// Check authoritative response with dig
dig +norecurse @ns1.example.com example.com

// Compare with host's simplified view
host -v -t any example.com ns1.example.com

// Verify DNSSEC validation
dig +dnssec example.com
host -t RRSIG example.com

When troubleshooting DNS issues:

1. Always check both tools for discrepancies
2. Use +trace with dig for resolution path:
   dig +trace example.com
3. Verify TTL values match expectations
4. Test with TCP fallback:
   dig +tcp @ns1.example.com example.com
5. Check all record types:
   host -t MX example.com
   dig example.com MX

Here's how to investigate a CNAME resolution failure:

# First with host (may fail)
host subdomain.example.com ns1.provider.net

# Then with detailed dig
dig @ns1.provider.net subdomain.example.com +norecurse +nocmd +noall +answer

# Check for DNSSEC validation issues
delv @ns1.provider.net subdomain.example.com

# Verify glue records if needed
dig +additional example.com NS