Fix Name or Service Not Known DNS Resolution Errors (2026)

The DNS resolver on your machine gave up trying to find the IP address for a hostname because the upstream DNS server it contacted either didn’t respond or returned an invalid answer. This is the fundamental breakdown: your machine asked, and the server it asked didn’t answer correctly.

Here are the common culprits, from most to least likely:

Local DNS Cache Corruption: Your machine keeps a local cache of DNS records to speed things up. If this cache gets stale or corrupted, it can point to non-existent or incorrect IPs.
- Diagnosis: On Linux/macOS, try flushing the cache. On most modern Linux systems using systemd-resolved, it’s sudo systemd-resolve --flush-caches. On older systems or macOS, it might be sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder. On Windows, it’s ipconfig /flushdns.
- Fix: Running the appropriate flush command.
- Why it works: This clears out any potentially bad entries, forcing your machine to perform a fresh lookup.
Incorrect DNS Server Configuration: Your machine is configured to use DNS servers that are down, unreachable, or misconfigured themselves. This is especially common if you’ve manually set DNS servers or if your DHCP server is handing out bad ones.
- Diagnosis: On Linux, check /etc/resolv.conf. On macOS, go to System Preferences > Network > Advanced > DNS. On Windows, ipconfig /all and look for "DNS Servers".
- Fix: Manually set your DNS servers to known good public resolvers like Google DNS (8.8.8.8, 8.8.4.4) or Cloudflare DNS (1.1.1.1, 1.0.0.1). For example, on Linux, you might edit /etc/resolv.conf to contain:
```
nameserver 8.8.8.8
nameserver 8.8.4.4
```
  If you’re using systemd-resolved, edit /etc/systemd/resolved.conf and set DNS=8.8.8.8 8.8.4.4 and uncomment FallbackDNS=1.1.1.1. Then restart the service: sudo systemctl restart systemd-resolved.
- Why it works: You’re bypassing potentially faulty local or ISP-provided DNS servers by directing your requests to reliable, well-maintained infrastructure.
Firewall Blocking DNS Traffic: A firewall, either on your machine or on your network (router, corporate firewall), is preventing DNS queries (UDP/TCP port 53) from reaching your configured DNS servers.
- Diagnosis: Use ping to test connectivity to your DNS server IPs (e.g., ping 8.8.8.8). If that works but DNS fails, a firewall is a prime suspect. You can also try traceroute (or tracert on Windows) to see where packets stop.
- Fix: If it’s a local firewall (Windows Firewall, ufw on Linux, macOS firewall), create an explicit rule to allow outbound UDP and TCP traffic to port 53 for your DNS server IPs. If it’s a network firewall, you’ll need to consult your network administrator or router’s configuration to ensure port 53 outbound traffic is permitted.
- Why it works: DNS relies on specific network ports. If these are blocked, the query never gets to its destination.
Upstream DNS Server Issues: The DNS server your machine is configured to use is experiencing its own problems – it might be overloaded, undergoing maintenance, or have internal errors.
- Diagnosis: Try querying a different DNS server directly using dig or nslookup. For example, to query Google’s DNS for example.com: dig @8.8.8.8 example.com or nslookup example.com 8.8.8.8. If this works but your normal lookup fails, the issue is with your configured upstream server.
- Fix: As in point 2, switch to a different set of reliable DNS servers temporarily or permanently.
- Why it works: You’re offloading the resolution task from a problematic server to a healthy one.
Network Connectivity Problems: While basic network connectivity might seem to be working (you can ping IPs), there could be subtle packet loss or routing issues that specifically affect DNS traffic, which is often UDP.
- Diagnosis: Run a mtr (My Traceroute) or pathping (Windows) command towards your DNS server. This combines ping and traceroute to show latency and packet loss at each hop. Significant packet loss on any hop to your DNS server is a problem.
- Fix: This is the hardest to fix directly. It might involve contacting your ISP if the issue is beyond your local network, or troubleshooting your local network hardware (router, modem) if the problem is closer to home. For a quick workaround, try using DNS servers that are geographically closer to you.
- Why it works: DNS queries are small and sensitive to packet loss. If the path to the DNS server is unreliable, queries can be dropped before they are answered.
DNS Server IP Address Conflict / Incorrect Host File: In rare cases, there might be a static IP address conflict on your network, or your local hosts file (e.g., /etc/hosts on Linux/macOS, C:\Windows\System32\drivers\etc\hosts on Windows) has an incorrect entry for the hostname you’re trying to reach, overriding DNS entirely.
- Diagnosis: Check your hosts file for any lines that map the problematic hostname to an IP address. For example, if you’re trying to reach my-server.local and hosts has 192.168.1.100 my-server.local, that’s what your system will try to resolve. Also, use arp -a to check for IP conflicts if you suspect issues on your local subnet.
- Fix: Remove or comment out any incorrect entries in your hosts file. If there’s an IP conflict, resolve it by reconfiguring the IP address on one of the conflicting devices.
- Why it works: The hosts file is checked before DNS resolution. An incorrect entry there will always take precedence. IP conflicts can lead to misdirected traffic.

After fixing these, the next error you’ll likely encounter if you haven’t addressed it is a "Connection refused" or "Connection timed out" error if the IP address you did eventually resolve points to a service that isn’t running or is inaccessible.