DNS Resolution Failure in curl/wget Despite Successful host/ping Commands: Diagnosing Wireless Network Issues


2 views

I recently encountered a baffling network issue where basic DNS resolution worked inconsistently across different tools. While host and ping could successfully resolve domains, HTTP clients like curl and wget failed with resolution errors.

$ curl -v google.com
* getaddrinfo(3) failed for google.com:80
* Couldn't resolve host 'google.com'
* Closing connection #0
curl: (6) Couldn't resolve host 'google.com'

My setup showed some interesting characteristics:

$ cat /etc/resolv.conf 
# Generated by NetworkManager
nameserver 192.168.1.201

$ netstat -rn
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         192.168.1.254   0.0.0.0         UG        0 0          0 wlan0
127.0.0.0       127.0.0.1       255.0.0.0       UG        0 0          0 lo
192.168.1.0     0.0.0.0         255.255.255.0   U         0 0          0 wlan0
  • Wired networking worked perfectly
  • Wireless connection (WEP) exhibited the issue
  • Different tools used different resolution methods
  • Basic ICMP worked while HTTP failed

Using strace revealed the underlying system calls:

$ strace -e trace=network curl -v google.com
socket(PF_INET, SOCK_DGRAM|SOCK_NONBLOCK, IPPROTO_IP) = 3
connect(3, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("192.168.1.201")}, 16) = -1 EINPROGRESS (Operation now in progress)
  1. DNS Server Configuration: The DNS server at 192.168.1.201 might be filtering certain query types
  2. WEP Encryption Issues: Older encryption might interfere with certain packet sizes
  3. MTU Problems: Fragmentation issues with larger DNS responses
  4. NSSwitch Configuration: Different tools might use different resolution methods

1. Force IPv4 Resolution

$ curl -4 -v google.com
* Trying 142.250.179.46...
* Connected to google.com (142.250.179.46) port 80 (#0)

2. Use Alternative DNS Server

$ sudo sh -c 'echo "nameserver 8.8.8.8" > /etc/resolv.conf'
$ curl -v google.com
* Connected to google.com (142.250.179.46) port 80 (#0)

3. Check DNS Query Types

Some networks block certain DNS query types. Try forcing TCP DNS:

$ dig +tcp google.com

Understanding these nuances is crucial when:

  • Writing network-aware applications
  • Debugging container networking
  • Implementing retry logic
  • Handling network fallback scenarios

Recently encountered a bizarre networking issue where standard tools showed conflicting DNS resolution behavior. While ping and host commands worked perfectly, curl and wget consistently failed with resolution errors:

$ curl -v google.com
* getaddrinfo(3) failed for google.com:80
* Couldn't resolve host 'google.com'

Meanwhile, basic connectivity tests worked:

$ ping google.com
PING google.com (209.85.148.147) 56(84) bytes of data
64 bytes from fra07s07-in-f147.1e100.net: icmp_seq=1 ttl=54 time=34.0 ms

Key observations from the system configuration:

$ cat /etc/resolv.conf
# Generated by NetworkManager
nameserver 192.168.1.201

$ netstat -rn
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         192.168.1.254   0.0.0.0         UG        0 0          0 wlan0

The issue stems from a misconfiguration where DNS resolution works for basic ICMP (ping) but fails for application-level requests. Here's why:

  • WEP encryption on wireless can interfere with certain packet types
  • MTU size mismatches may fragment DNS responses
  • The DNS server (192.168.1.201) might block non-53 port queries
  • IPv6/IPv4 resolution priority differences between tools

Try these diagnostic commands to isolate the problem:

# Check DNS resolution with different tools
dig google.com
nslookup google.com

# Test connectivity to DNS server
nc -zv 192.168.1.201 53

# Check DNS query behavior
tcpdump -i wlan0 port 53

# Force IPv4 resolution
curl -4 -v google.com

Effective fixes that resolved similar issues:

# Solution 1: Override DNS settings
sudo bash -c 'echo "nameserver 8.8.8.8" > /etc/resolv.conf'

# Solution 2: Disable IPv6
sudo sysctl -w net.ipv6.conf.all.disable_ipv6=1

# Solution 3: Adjust MTU size
sudo ifconfig wlan0 mtu 1400

# Solution 4: Force curl to use specific DNS
curl --dns-servers 8.8.8.8 -v google.com

For persistent fixes, modify NetworkManager configuration:

# /etc/NetworkManager/conf.d/dns.conf
[main]
dns=none

# /etc/resolvconf/resolv.conf.d/head
nameserver 8.8.8.8
nameserver 8.8.4.4

Remember to restart networking services after changes:

sudo systemctl restart NetworkManager
sudo resolvconf -u