The “curl: (6) Could not resolve host” error occurs when your Linux system fails to translate a hostname into an IP address. This guide walks through diagnosing and fixing DNS resolution issues, covering network connectivity checks, DNS resolver configuration, hosts file inspection, and setting up reliable public DNS servers. By the end, you will have a working DNS configuration and the knowledge to troubleshoot similar issues in the future.
Understanding the Curl Error 6 Message
Before diving into solutions, it helps to understand exactly what this error means. When curl attempts to connect to a server, it first needs to resolve the hostname to an IP address using DNS (Domain Name System). If this lookup fails, curl reports error code 6.
The error typically looks like this:
curl: (6) Could not resolve host: example.com
Common causes include network connectivity problems, misconfigured DNS servers, incorrect hosts file entries, or DNS service issues on your system. The following sections address each potential cause systematically.
Verify Network Connectivity First
Start by ruling out basic network issues. If your system cannot reach the internet at all, DNS resolution will also fail. Use the ping command to check connectivity:
ping -c 4 8.8.8.8This command pings Google’s public DNS server by IP address (bypassing DNS resolution). A successful response looks like this:
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data. 64 bytes from 8.8.8.8: icmp_seq=1 ttl=118 time=15.2 ms 64 bytes from 8.8.8.8: icmp_seq=2 ttl=118 time=14.8 ms 64 bytes from 8.8.8.8: icmp_seq=3 ttl=118 time=15.1 ms 64 bytes from 8.8.8.8: icmp_seq=4 ttl=118 time=14.9 ms --- 8.8.8.8 ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3004ms rtt min/avg/max/mdev = 14.800/15.000/15.200/0.150 ms
If the ping fails with “Network is unreachable” or 100% packet loss, the problem is network connectivity rather than DNS. In that case, check your Ethernet cable, Wi-Fi connection, router, or network configuration before proceeding.
Test DNS Resolution with dig
Once you confirm basic connectivity works, test whether DNS resolution is functioning. The dig command queries DNS servers directly and provides detailed output:
dig google.comA working DNS configuration returns output similar to this:
; <<>> DiG 9.18.39 <<>> google.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59526 ;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;google.com. IN A ;; ANSWER SECTION: google.com. 110 IN A 142.250.124.138 google.com. 110 IN A 142.250.124.101 google.com. 110 IN A 142.250.124.100 ;; Query time: 3 msec ;; SERVER: 192.168.1.1#53(192.168.1.1) (UDP) ;; WHEN: Mon Dec 29 12:15:00 UTC 2025 ;; MSG SIZE rcvd: 184
The key indicators are status: NOERROR and the presence of IP addresses in the ANSWER SECTION. If you see status: SERVFAIL or no answer section, your DNS resolver is not working correctly.
If
digis not installed, use the appropriate package for your distribution:sudo apt install dnsutils(Debian/Ubuntu),sudo dnf install bind-utils(Fedora/RHEL/openSUSE),sudo pacman -S bind(Arch), orsudo apk add bind-tools(Alpine). Alternatively, use nslookup for a simpler DNS query.
Check Your /etc/hosts File
The /etc/hosts file provides local hostname-to-IP mappings that take precedence over DNS lookups. Incorrect entries here can cause resolution failures for specific domains.
View the file contents:
cat /etc/hostsA typical hosts file looks like this:
127.0.0.1 localhost 127.0.1.1 your-hostname ::1 localhost ip6-localhost ip6-loopback fe00::0 ip6-localnet ff00::0 ip6-mcastprefix ff02::1 ip6-allnodes ff02::2 ip6-allrouters
If you see incorrect entries mapping domains to wrong IP addresses (or to 127.0.0.1 when they should not be), edit the file with root privileges:
sudo nano /etc/hostsRemove or correct any problematic entries, then save and exit (Ctrl+O, Enter, Ctrl+X in nano). Changes take effect immediately without requiring a restart.
Configure Reliable Public DNS Servers
If your ISP's DNS servers are slow, unreliable, or blocking certain domains, switching to public DNS providers often resolves the issue. Google DNS and Cloudflare DNS are widely used options known for reliability and speed.
Option 1: Configure DNS with systemd-resolved (Modern Method)
Most modern Linux distributions (Ubuntu 18.04+, Debian 12+, Fedora) use systemd-resolved for DNS management. First, check if it is running:
systemctl status systemd-resolvedIf the service is active, configure DNS by editing the resolved configuration:
sudo nano /etc/systemd/resolved.confAdd or modify the DNS settings under the [Resolve] section:
[Resolve]
DNS=8.8.8.8 8.8.4.4
FallbackDNS=1.1.1.1 1.0.0.1This configures Google DNS as the primary resolver and Cloudflare DNS as the fallback. After saving, restart the service:
sudo systemctl restart systemd-resolvedVerify the new settings are active:
resolvectl statusYou should see your configured DNS servers listed in the output.
Option 2: Edit /etc/resolv.conf Directly (Legacy Method)
On systems without systemd-resolved, you can edit /etc/resolv.conf directly. However, be aware that many systems regenerate this file automatically.
sudo nano /etc/resolv.confTo use Google DNS:
nameserver 8.8.8.8
nameserver 8.8.4.4To use Cloudflare DNS instead (recommended for privacy-focused users):
nameserver 1.1.1.1
nameserver 1.0.0.1On systems using DHCP or NetworkManager, changes to
/etc/resolv.confmay be overwritten on reboot or network reconnection. For persistent changes, configure DNS through your network manager settings or use the systemd-resolved method described above.
Verify the Fix
After making DNS configuration changes, test that resolution works correctly:
dig google.com +shortThis should return IP addresses:
142.250.124.138 142.250.124.101 142.250.124.100
Then test curl to confirm the original error is resolved:
curl -I https://example.comA successful response returns HTTP headers:
HTTP/2 200 content-type: text/html; charset=UTF-8 content-length: 1256 date: Mon, 29 Dec 2025 12:20:00 GMT
Common Causes and Quick Fixes Summary
| Symptom | Likely Cause | Quick Fix |
|---|---|---|
| Ping 8.8.8.8 fails | Network connectivity issue | Check cables, Wi-Fi, router |
| dig returns SERVFAIL | DNS server unreachable or broken | Switch to Google or Cloudflare DNS |
| One domain fails, others work | Incorrect hosts file entry | Check and edit /etc/hosts |
| DNS works briefly after reboot | DHCP overwriting resolv.conf | Use systemd-resolved configuration |
| Corporate network blocks DNS | Firewall or proxy restrictions | Contact IT or use VPN |
Conclusion
DNS resolution problems in Linux typically trace back to misconfigured DNS servers, hosts file issues, or network connectivity problems. You now know how to verify connectivity with ping, test DNS with dig, inspect the hosts file, and configure reliable public DNS servers using either systemd-resolved or direct resolv.conf editing. With these troubleshooting skills, you can quickly diagnose and fix curl error 6 and similar DNS-related issues on any Linux system.