You find that DNS queries take a long time from your machine, and you decide to fix this by installing a local DNS resolver. You ask the internet, which says:
You could use
There’s an odd one out in this list. One of them is not a DNS server at all!
An ordinary DNS server listens on UDP port 53.
When running a local caching DNS resolver,
local processes will contact
localhost:53 for any DNS lookups.
But, unlike the other caching DNS resolvers,
nscd does not listen on any ports!
nscd listens on a socket,
How, though, do local processes know to connect to
The answer is that local processes don’t know to connect to
Or rather, some do, and some don’t.
The processes that do know about
are those linked against
glibc and using
getaddrinfo from that library.
Only GNU’s implementation of the C standard library
has the knowledge of
If your process is linked against a different libc (e.g.
or if your process uses a different runtime (e.g. the Go runtime),
it knows nothing of
This is your first reason for not using
Other systems have not implemented support for
because there is no specification, or even informal documentation, for
nscd is entirely internal to glibc.
The source code for the daemon is part of glibc,
even though the daemon is not part of the libc library.
If you try installing
you’ll find the second reason for not using
it’s horribly unstable.
I can’t keep it running for more than a few seconds
before I get log lines like this in the system log:
Feb 3 19:36:17 vagrant-ubuntu-trusty-64 kernel: [11799.496494] nscd: segfault at 43c000010 ip 00007fba29180753 sp 00007fba1e4741f0 error 4 in nscd[7fba2916c000+25000] Feb 3 19:39:46 vagrant-ubuntu-trusty-64 kernel: [12008.644917] nscd: segfault at 0 ip 00007ff37679cdfa sp 00007ff36ce901e8 error 4 in libc-2.19.so[7ff376714000+1be000] Feb 3 19:51:09 vagrant-ubuntu-trusty-64 kernel: [12691.893221] nscd: segfault at 0 ip 00007f82d31aadfa sp 00007f82c989e1e8 error 4 in libc-2.19.so[7f82d3122000+1be000]
This is not just my experience. Denys Vlasenko explains:
nscd problems are not exactly unheard of. Over the years, there were quite a bit of bugs in it. This leads people to invent babysitters which restart crashed/hung nscd. This is ugly.
After looking at nscd source in glibc I arrived to the conclusion that its design is contributing to this significantly. Even if nscd’s code is 100.00% perfect and bug-free, it can still suffer from bugs in libraries it calls.
As designed, it’s a multithreaded program which calls NSS libraries. These libraries are not part of libc, they may be provided by third-party projects (samba, ldap, you name it).
Thus nscd cannot be sure that libraries it calls do not have memory or file descriptor leaks and other bugs.
Since nscd is multithreaded program with single shared cache, any resource leak in any NSS library has cumulative effect. Even if a NSS library leaks a file descriptor 0.01% of the time, this will make nscd crash or hang after some time.
Vlasenko writes this in the context of his single-threaded
nscd replacement for BusyBox.
But he notes “as of 2008-08 it is not in wide use”.
But it won’t be in widespread use, ever,
and there won’t be any other stable replacements for
nscd protocol is internal to glibc,
with no stability guarantees.
nscd, use a local DNS server registered in
The protocol is specified and stable, all processes respect
resolv.conf, and there are many implementations.
More by Jim
- Smear phishing: a new Android vulnerability
- A probabilistic pub quiz for nerds
- Time is running out to catch COVID-19
- The inception bar: a new phishing method
- The hacker hype cycle
- Project C-43: the lost origins of asymmetric crypto
- How Hacker News stays interesting
- My parents are Flat-Earthers
- The dots do matter: how to scam a Gmail user
- The sorry state of OpenSSL usability
- I hate telephones
- The Three Ts of Time, Thought and Typing: measuring cost on the web
- Granddad died today
- Your syntax highlighter is wrong