🚨 Linux Error: Name or service not known — Cause, Fix, and Troubleshooting Guide

Summary

Name or service not known is glibc’s EAI_NONAME from getaddrinfo() — the resolver looked up a hostname (or service name) and got a definitive “no such name” answer. Unlike a temporary DNS timeout, this is usually deterministic: the name is wrong, does not exist in DNS, or the resolver is not consulting the source that would know it. It can also mean an unknown port/service name.

Common Symptoms

• ssh, curl, ping, or git fail against one specific hostname while others work.
• The error is immediate (no long timeout), signalling a hard NXDOMAIN rather than a slow lookup.
• Internal/.local/short hostnames fail while fully-qualified public names resolve.
• getent hosts <name> returns nothing.

Most Likely Causes of the ‘Name or service not known’ Error

1. Typo or non-existent hostname — the name simply is not in DNS (NXDOMAIN).
2. Missing search domain — a short name like db01 needs a search corp.example.com suffix that is not configured.
3. Host not in /etc/hosts and not in DNS — common for internal service names and for the box’s own hostname.
4. Wrong or empty nameserver in /etc/resolv.conf, so even valid names return nothing.
5. nsswitch.conf misordered — the hosts: line does not include dns, or omits files.
6. Unknown service name — e.g. passing a port name that is not in /etc/services.

Quick Triage

# Is it just this one name? Try a name you know resolves.
getent hosts example.com
getent hosts <the-failing-name>

# Raw IP works? -> confirms connectivity is fine, it is name lookup.
ping -c1 1.1.1.1

Diagnostic Commands

# Resolution via the real NSS path (files + dns)
getent hosts db01.corp.example.com

# Direct DNS: does the authoritative/upstream server know it?
dig db01.corp.example.com
dig @1.1.1.1 example.com +short
nslookup db01.corp.example.com

# Search domains and nameservers actually in effect
cat /etc/resolv.conf          # look at 'search' and 'nameserver' lines
resolvectl status             # per-link DNS + search domains

# Is 'dns' even consulted, and in what order?
grep '^hosts:' /etc/nsswitch.conf

# Static overrides
getent ahosts <name>          # shows files+dns merged result
cat /etc/hosts

# Stub resolver health
systemctl status systemd-resolved
ss -tulpn | grep ':53'
nc -vz 1.1.1.1 53

# Verbose client trace
curl -v http://db01.corp.example.com
journalctl -u systemd-resolved --since "10 min ago"

A bare short name that fails but resolves once you append the domain (dig db01.corp.example.com) points straight at a missing search domain.

Fix / Remediation

1. Verify the name is correct and exists. Test the FQDN directly:

   dig db01.corp.example.com +short

   If DNS has no record, the fix is on the DNS side (add the record), not the client.

2. Add the search domain so short names resolve:

   sudo resolvectl domain <IFACE> corp.example.com      # systemd-resolved
   # NetworkManager (RHEL/Rocky):
   sudo nmcli con mod "<CONN>" ipv4.dns-search "corp.example.com"
   sudo nmcli con up "<CONN>"

3. Add a static entry to /etc/hosts for internal names with no DNS record:

   echo '10.0.3.20  db01 db01.corp.example.com' | sudo tee -a /etc/hosts

4. Fix nsswitch.conf if dns is missing:

   grep '^hosts:' /etc/nsswitch.conf
   # should read: hosts: files dns   (or ...resolve dns on systemd-resolved)

   Warning: Edit /etc/nsswitch.conf carefully — a malformed hosts: line can break all name resolution, including for sudo and package tooling. Keep a root shell open until you confirm resolution still works.

5. Point at a working nameserver if /etc/resolv.conf is empty or wrong (see the DNS management steps for your distro — resolvectl dns on Ubuntu, nmcli on RHEL).

Validation

getent hosts <name>          # now returns an IP
dig <name> +short            # returns an answer (or matches /etc/hosts)
ssh -o BatchMode=yes <name> true 2>&1 | grep -v 'Name or service'

Prevention

• Prefer FQDNs in configs and scripts so you do not depend on search domains.
• Keep internal service names in DNS (or a managed /etc/hosts) rather than ad hoc edits.
• Standardise nsswitch.conf and resolv.conf via configuration management.
• Add synthetic getent hosts checks for critical internal names to catch DNS drift before deploys fail.

Related Errors

• Temporary failure in name resolution
• curl: (6) Could not resolve host
• sudo: unable to resolve host
• Connection refused
• Docker: Temporary failure in name resolution

Final Notes

Name or service not known is a definitive “this name does not resolve,” so start by proving whether the name exists in DNS at all with dig on the FQDN. If the FQDN resolves but the short name does not, it is a search-domain gap; if neither resolves, fix DNS or add an /etc/hosts entry.

Want faster Linux incident response? Use DevOps AI Toolkit to turn production errors into clear diagnostics, remediation steps, and reusable runbooks.