When encountering a situation where dig successfully resolves a hostname while ping fails with "unknown host", we're dealing with a classic DNS resolution inconsistency. Let's break down what's happening in your specific case:

# Successful dig query to first nameserver
dig admin.example-preprod.foobar.it @200.200.200.1
;; ANSWER SECTION:
admin.example-preprod.foobar.it. 86400 IN A 100.100.100.100

# Failed ping attempt
ping admin.example-preprod.foobar.it
ping: unknown host admin.example-preprod.foobar.it

Several factors could cause this behavior in Linux systems:

• Multiple DNS servers configuration: Your system uses three nameservers with different behaviors
• DNS caching mechanisms: systemd-resolved or other DNS caches might be involved
• Search domain configuration: The resolver might be appending incorrect search domains

First, let's verify how the system is actually performing resolution:

# Check the resolution order and active DNS servers
systemd-resolve --status

# Alternative method for non-systemd systems
cat /etc/nsswitch.conf | grep hosts

# Test with getent which uses the system resolver
getent hosts admin.example-preprod.foobar.it

Based on your dig outputs, we can observe:

# Nameserver 200.200.200.1 returns correct A record
# Nameserver 200.200.200.2 returns NXDOMAIN
# Nameserver 200.200.200.3 returns correct A record

The Linux resolver library will:

1. Try the first nameserver (200.200.200.1) which succeeds
2. Cache the positive response
3. For subsequent queries, it might hit the second nameserver (200.200.200.2) which returns NXDOMAIN

Try these solutions in order:

# 1. Clear DNS caches
sudo systemd-resolve --flush-caches
# Or for older systems
sudo /etc/init.d/nscd restart

# 2. Modify resolv.conf to use only working nameservers
sudo nano /etc/resolv.conf
# Comment out problematic nameserver
#nameserver 200.200.200.2

For production environments, implement these fixes:

# Configure DNS failover properly in /etc/resolv.conf
options timeout:1 attempts:2 rotate

# Or configure NetworkManager to maintain DNS settings
nmcli con modify "YourConnection" ipv4.dns "200.200.200.1 200.200.200.3"
nmcli con up "YourConnection"

For deeper analysis, use these tools:

# Trace DNS resolution path
dig +trace admin.example-preprod.foobar.it

# Check DNS query timings
time dig admin.example-preprod.foobar.it

# Verify DNSSEC validation
delv admin.example-preprod.foobar.it

Remember that DNS changes might take time to propagate due to TTL settings. The 86400 second TTL in your records means changes could take up to 24 hours to fully propagate.

---

When working with DNS configurations in Linux environments, you might encounter a puzzling scenario where dig successfully resolves a hostname while ping fails with "unknown host" errors. This typically indicates a DNS resolution inconsistency between different nameservers configured in your system.

// Example of failing ping command
$ ping admin.example-preprod.foobar.it
ping: unknown host admin.example-preprod.foobar.it

The key difference lies in how these commands interact with your DNS configuration:

• dig queries specific DNS servers directly (as shown in your tests)
• ping uses the system's resolver library which follows /etc/resolv.conf order

// Example resolv.conf with multiple nameservers
nameserver 200.200.200.1
nameserver 200.200.200.2
nameserver 200.200.200.3

From your dig outputs, we can observe critical differences:

// Successful response from 200.200.200.1
;; ANSWER SECTION:
admin.example-preprod.foobar.it. 86400 IN A      100.100.100.100

// NXDOMAIN response from 200.200.200.2
;; AUTHORITY SECTION:
foobar.it.               85817   IN      SOA     qwert.foobar.it. webmaster.foobar.it. 2016092901

Several factors could cause this behavior:

1. DNS caching inconsistencies
2. Round-robin DNS resolution failure
3. Different authoritative answers from nameservers
4. Missing search domains in resolver configuration

Here's how to systematically diagnose the issue:

// Check the resolution order
$ sudo tcpdump -i any -n port 53

// Verify DNS server response times
$ time dig @200.200.200.1 example.com
$ time dig @200.200.200.2 example.com

// Test with full qualification
$ ping admin.example-preprod.foobar.it.

Based on the symptoms, consider these approaches:

// Option 1: Modify resolv.conf to prioritize working DNS
sudo bash -c 'echo "nameserver 200.200.200.1" > /etc/resolv.conf'

// Option 2: Configure nsswitch to use DNS before other methods
sudo nano /etc/nsswitch.conf
# Change: hosts: files dns

// Option 3: Implement local DNS caching
sudo apt install resolvconf
sudo systemctl restart resolvconf.service

For persistent issues, use these professional tools:

// Check DNS resolution path
$ drill admin.example-preprod.foobar.it

// Test with different record types
$ host -t A admin.example-preprod.foobar.it
$ host -t AAAA admin.example-preprod.foobar.it

// Verify DNSSEC validation
$ delv admin.example-preprod.foobar.it

To avoid future DNS resolution problems:

1. Implement consistent DNS server configurations across environments
2. Set up monitoring for DNS resolution failures
3. Configure proper TTL values for DNS records
4. Use DNS caching servers like dnsmasq in critical infrastructure

Remember that DNS issues can be intermittent and environment-specific. The key is methodical testing and understanding how different tools interact with your DNS infrastructure.