Hostname Could Not Be Found or Resolved: Fix DNS Errors

Applies to: macOS 27 and iOS apps (according to Apple); Ubuntu 26.04 (curl 8.18.0, git 2.53.0, OpenSSH 10.2p1, wget 1.25.0, sudo 1.9.17p2 and sudo-rs 0.2.13) and Debian 13

"A server with the specified hostname could not be found", "Could not resolve host" and "Name or service not known" all mean the same thing: the DNS lookup for the server name failed, so your device never got an IP address to connect to. Either the name does not exist in DNS (a typo, a missing record, a new or expired domain, wrong name servers) or your device cannot reach a working DNS server. Find out which with one lookup against a public DNS server, then fix the domain's records or your device's DNS settings as shown below.

What each message means

• "A server with the specified hostname could not be found." This is the text Mac, iPhone and iPad apps show for Apple's error code -1003 (NSURLErrorCannotFindHost), which Apple describes as "The host name for a URL could not be resolved."
• "Name or service not known" (Linux): the DNS server answered that the name does not exist.
• "Temporary failure in name resolution" (Linux): no DNS server answered at all, so the problem is your network or DNS settings, not the domain.
• "No address associated with hostname" (Linux): the name exists but has no A or AAAA record.
• "Could not resolve host" (curl, git, PHP's curl functions and other tools built on libcurl): any of the above. curl exits with code 6.

This is the real output for a name that does not exist (.invalid is reserved and never resolves), from an Ubuntu 26.04 lab:

$ ping -c1 no-such-host.invalid
ping: no-such-host.invalid: Name or service not known
$ curl https://no-such-host.invalid/
curl: (6) Could not resolve host: no-such-host.invalid
$ git clone https://no-such-host.invalid/repo.git
Cloning into 'repo'...
fatal: unable to access 'https://no-such-host.invalid/repo.git/': Could not resolve host: no-such-host.invalid
$ ssh no-such-host.invalid
ssh: Could not resolve hostname no-such-host.invalid: Name or service not known
$ wget https://no-such-host.invalid/
Resolving no-such-host.invalid (no-such-host.invalid)... failed: Name or service not known.
wget: unable to resolve host address 'no-such-host.invalid'

When we pointed the same machine at a DNS server that does not answer, the messages changed:

$ ping -c1 example.com
ping: example.com: Temporary failure in name resolution
$ ssh example.com
ssh: Could not resolve hostname example.com: Temporary failure in name resolution
$ dig example.com
;; no servers could be reached

With an unreachable DNS server address, ping waited 10 seconds before it failed, so a slow error is another sign of a network-side problem.

Step 1: Is it the name or your network?

1. Check the spelling of the address, including the part after the last dot. A typo is the most common cause.
2. Look the name up with your normal DNS server and with a public one. On Linux and macOS (macOS 27 includes dig, host and nslookup):

   dig +short A www.example.com
   dig +short A www.example.com @8.8.8.8
   dig www.example.com | grep status

   On Windows, use nslookup www.example.com and nslookup www.example.com 8.8.8.8.
3. Read the result:
   • status: NXDOMAIN from every server: the name does not exist. Go to step 2.
   • status: NOERROR but no IP address: the name exists without an A record. Go to step 2.
   • An IP from @8.8.8.8 but not from your normal server, or no servers could be reached: your DNS setup is the problem. Go to step 3.

Step 2: Fix the domain (when you own it)

• Name servers: run dig +short NS example.com. The result must match the name servers of the DNS host where you edit your records. If it is empty or shows the wrong servers, change the name servers at your registrar (see what a nameserver is and how to change it).
• Missing record: example.com and www.example.com are separate names. Each one needs its own A record (or a CNAME for www) pointing to your server's IP. Add the missing one in your DNS zone.
• New domain or just changed records: resolvers keep old answers until the record's TTL runs out, and a name server change at the registrar can take longer to reach every resolver. If @8.8.8.8 already shows the right IP but your computer does not, clear your local DNS cache.
• Domain on hold or expired: according to ICANN, a domain with the status clientHold or serverHold is not active in DNS and will not resolve. Check the status in a whois lookup or with your registrar, and renew the domain or complete any verification it asks for.

Step 3: Fix DNS on your device

Mac:

1. Open the address in another app or on another device on the same network. If it fails everywhere, check your router or try another network (for example a phone hotspot).
2. Turn off any VPN, proxy or DNS filtering app for a moment and try again: these change which DNS server your Mac uses.
3. Clear the DNS cache, as shown in how to flush the DNS cache on macOS, Windows, Linux and browsers.
4. To use other DNS servers, Apple's path is Apple menu > System Settings > Network, click your network service, click Details, then DNS, and add a server with the Add button.

iPhone and iPad: switch between Wi-Fi and mobile data. If the app works on one and not the other, the DNS server of that network is the problem. Turn off any VPN or DNS profile you installed, then try again.

Linux server or VPS:

1. Look at /etc/resolv.conf. Every nameserver line must be a DNS server that is reachable from the machine.
2. Test a public server directly: if dig example.com @8.8.8.8 works while dig example.com fails, fix the resolver settings as described in how to change DNS settings on Linux and Windows.
3. If both fail with no servers could be reached, check that your firewall allows outgoing DNS (UDP and TCP port 53).

sudo: unable to resolve host

This warning means the machine cannot look up its own host name: the name is neither in /etc/hosts nor in DNS. It often appears after the host name was changed without updating /etc/hosts. In our lab (host name vps1, missing from /etc/hosts) classic sudo printed:

$ sudo true
sudo: unable to resolve host vps1: Name or service not known

The command still ran. Ubuntu 26.04's default sudo (sudo-rs 0.2.13) printed nothing in the same situation; the classic sudo.ws showed the warning. Either way, other software can fail on the same lookup, so fix it:

1. Check the host name: hostname
2. Edit /etc/hosts as root and add a line with that name. On Debian and Ubuntu the usual form is:

   127.0.1.1	vps1

   The Debian reference manual says a system with a permanent IP address should use that IP instead of 127.0.1.1, with the fully qualified name, for example 192.0.2.10 vps1.example.com vps1 (the short name after it is an alias, so both names resolve).
3. Check it: getent hosts vps1 must print the line you added, and sudo no longer warns.

To change the host name itself, see how to set or change the hostname with hostnamectl.

Related articles: DNS lookup commands: dig, nslookup and host, what is a nameserver and how to change yours, how to flush the DNS cache, how to change DNS settings on Linux and Windows.

Official documentation: Apple: change DNS settings on Mac, Debian reference: hostname resolution.