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
- Your syntax highlighter is wrong
- Granddad died today
- The Three Ts of Time, Thought and Typing: measuring cost on the web
- I hate telephones
- The sorry state of OpenSSL usability
- The dots do matter: how to scam a Gmail user
- My parents are Flat-Earthers
- How Hacker News stays interesting
- Project C-43: the lost origins of asymmetric crypto
- The hacker hype cycle
- The inception bar: a new phishing method
- Time is running out to catch COVID-19
- A probabilistic pub quiz for nerds
- Smear phishing: a new Android vulnerability