ping vs nslookup?
Why nslookup
works but ping
says “Name or service not known”?
Let’s get basic terminology straight up — and it’s assumed you already understand how DNS resolution works.
In my quest to understand how tools like nslookup
and ping
behave differently, I was honestly confused by the terms DNS Resolver and Stub Resolver. Aren’t they the same thing?
They’re not. And the docs? Yeah, they don’t make it any easier.
Here’s what I’ve figured out:
-
DNS Resolver: A full-blown service that actually resolves DNS queries — like
systemd-resolved
, Google’s8.8.8.8
, or Cloudflare’s1.1.1.1
. This is the brain of DNS resolution. -
Stub Resolver: A tiny local component (often part of
glibc
orsystemd
) that just forwards DNS queries to a real resolver. It doesn’t resolve anything on its own — it's more of a DNS middleman.
Example:
cat /etc/resolv.conf
nameserver 127.0.0.53
options edns0 trust-ad
search us-east-2.compute.internal
Here, 127.0.0.53
is a local stub resolver run by systemd-resolved. Apps send queries to it; it forwards them upstream and caches the answers.
The Role of glibc (GNU C Library)
Another interesting bit in this rabbit hole: most Linux programs use glibc (GNU C Library) for all core system functions — including DNS lookups.
When a program like ping
or curl
needs to resolve a hostname, it calls:
getaddrinfo("google.com", ...)
At that point, glibc handles:
- Reading /etc/nsswitch.conf
- Looking in /etc/hosts
- Calling stub resolvers if needed
Why nslookup still works?
Here’s the curveball: nslookup
bypasses glibc entirely.
- It doesn’t use glibc's DNS resolver logic.
- It sends DNS queries directly to the server (e.g., 8.8.8.8 or 127.0.0.53).
- It doesn’t care about /etc/nsswitch.conf or even your system’s DNS configuration files.
That’s why nslookup
can work even when ping
fails — it’s not using the same resolution path.
So... is ping
more reliable for troubleshooting?
Honestly? It depends on what you’re troubleshooting.If you want to verify that your system’s DNS resolution path (glibc, nsswitch, stub, etc.) is working properly — then yes, ping
, getent, or curl are more realistic.
If you just want to test whether some DNS server (like 8.8.8.8) knows about your domain, use nslookup
or dig
.
About /etc/nsswitch.conf
This file defines the order and method your system uses to resolve names and other services like:
- Hostnames → IP addresses
- Users (passwd)
- Groups
- Services
- Networks
For DNS, this line is key:
hosts: files dns
This tells glibc:
When resolving a hostname:
- First check /etc/hosts
- Then ask DNS (through the stub resolver)
If dns is missing, your system won’t even try DNS, no matter what’s in /etc/resolv.conf. Brutal.
Reason for behaviour mismatch is beacuse ping
is a native system tool that uses glibc, which follows nsswitch.conf
. nslookup
is an external tool (part of bind-utils or dnsutils) that bypasses glibc and NSS entirely
Understanding what each tool actually uses under the hood is crucial for troubleshooting.
Who homours what?
Tool | Uses glibc ? |
Honors /etc/nsswitch.conf ? |
---|---|---|
ping |
✅ Yes | ✅ Yes |
curl |
✅ Yes | ✅ Yes |
getent |
✅ Yes | ✅ Yes |
nslookup |
❌ No | ❌ No |
dig |
❌ No | ❌ No |