When performing DNS lookups for example.com, I noticed inconsistent behavior between the www-prefixed and root domain versions:

# Expected behavior (www)
$ dig +short www.example.com
192.0.2.1

# Unexpected behavior (root)
$ dig +short example.com
198.51.100.42

Checking the authoritative nameservers shows no rogue records:

$ dig +trace example.com NS
;; Received 521 bytes from 8.8.8.8#53(8.8.8.8) in 12 ms

example.com.    3600    IN    NS    ns1.registrar.com.
example.com.    3600    IN    NS    ns2.registrar.com.

$ dig @ns1.registrar.com example.com ANY
;; ANSWER SECTION:
example.com.    300    IN    A    192.0.2.1
example.com.    3600    IN    NS    ns1.registrar.com.
example.com.    3600    IN    NS    ns2.registrar.com.

1. Registrar-level Redirects
Many domain registrars implement "parking page" systems that override DNS:

# Check for HTTP response differences
$ curl -I http://example.com
HTTP/1.1 301 Moved Permanently
Location: http://www.example.com

$ curl -I http://www.example.com
HTTP/1.1 200 OK

2. Hidden CNAME Flattening
Some DNS providers convert CNAME at root to A records:

# Use dig +nocmd +noall +answer +ttlid example.com CNAME

Cross-validate using multiple DNS resolvers:

#!/bin/bash
resolvers=("1.1.1.1" "8.8.8.8" "9.9.9.9" "208.67.222.222")
for resolver in "${resolvers[@]}"; do
    echo "Testing $resolver:"
    dig @$resolver +short example.com
done

Verify nameserver delegation at the TLD level:

$ whois example.com | grep -i "name server"
Name Server: NS1.REGISTRAR.COM
Name Server: NS2.REGISTRAR.COM

For Cloudflare users, ensure proper proxy status:

# Cloudflare API check
curl -X GET "https://api.cloudflare.com/client/v4/zones/?name=example.com" \
    -H "Authorization: Bearer YOUR_API_TOKEN"

For AWS Route 53, check alias records:

aws route53 list-resource-record-sets \
    --hosted-zone-id ZONEID \
    --query "ResourceRecordSets[?Name=='example.com.']"

---

When troubleshooting domain resolution, I encountered a peculiar case where:

nslookup www.example.com
# Returns: 192.0.2.1 (correct server)

nslookup example.com  
# Returns: 203.0.113.45 (unknown server)

Digging deeper showed no trace of 203.0.113.45 in any DNS records:

dig example.com ANY
; No unexpected records found

After extensive testing, these emerged as likely causes:

1. Caching Layers

Intermediate DNS caches might retain outdated records. Verify with:

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

2. Registrar-Level Redirects

Some registrars implement hidden forwarding. Check with:

whois example.com | grep -i "nameserver"

3. Browser HSTS Preloading

For HTTPS sites, test with curl to bypass browser cache:

curl -v http://example.com

Here's my step-by-step verification script:

#!/bin/bash
DOMAIN="example.com"

# Check authoritative NS
echo "Authoritative nameservers:"
dig NS $DOMAIN +short

# Check all record types
echo "\nAll DNS records:"
dig ANY $DOMAIN +nocmd +noall +answer

# Verify global resolution
echo "\nGlobal DNS checks:"
for resolver in {1.1.1.1,8.8.8.8,9.9.9.9}; do
  echo "$resolver: $(dig @$resolver $DOMAIN +short)"
done

Based on my experience, these fixes consistently work:

# Explicit CNAME for root domain
@    IN    CNAME    www.example.com.
www  IN    A        192.0.2.1

Or for modern setups using ALIAS/ANAME:

@    IN    ALIAS    www.example.com.

For persistent cases, these nuclear options help:

• Registrar DNS reset (change nameservers temporarily)
• Submit removal request for Google Public DNS cache
• Contact ICANN if registrar won't resolve the issue