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’s 8.8.8.8, or Cloudflare’s 1.1.1.1. This is the brain of DNS resolution.

• Stub Resolver: A tiny local component (often part of glibc or systemd) 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?