False Gems

Recently, I faced an issue where curl (and browsers) couldn't resolve a hostname, but other tools like dig and nslookup worked fine. I want to share how I solved this problem in a simple way.

When I tried to use curl I got this error:

Could not resolve host: my.local.hostname

But when I used other tools:

dig my.local.hostname
nslookup my.local.hostname

They both returned the correct IP address for my.local.hostname.

Understanding the Cause

I learned that different tools resolve DNS in different ways: – dig and nslookup: They query DNS servers directly, bypassing the system's settings. – curl: It uses the system's resolver library, which follows the configuration in /etc/nsswitch.conf. I checked my /etc/nsswitch.conf file and found this line:

hosts: mymachines resolve [!UNAVAIL=return] files myhostname dns

This line tells the system how to resolve hostnames. The [!UNAVAIL=return] part means that if the resolve method (which uses systemd-resolved) doesn't find the hostname (and doesn't return UNAVAIL), the system stops looking and doesn't try the dns method. That's why curl couldn't resolve the hostname, even though DNS was working.

The Solution

I changed the hosts line to remove the [!UNAVAIL=return] part and reorder the methods to prioritize DNS:

hosts: files dns myhostname mymachines resolve

and restarted all DNS realted

sudo systemd-resolve --flush-caches
sudo systemctl restart systemd-resolved

Afterthoughts

If you don't need systemd-resolved, you can disable it:

sudo systemctl disable --now systemd-resolved

Then update /etc/nsswitch.conf:

hosts: files dns myhostname