10

I'm trying to use nscd (Nameservices Cache Daemon) to cache DNS locally so I can stop using Bind to do it. I've gotten it started and ntpd seems to attempt to use it. But everything else for hosts seems to ignore it. e.g if I do dig apache.org 3 times none of them will hit the cache. I'm viewing the cache stats using nscd -g to determine whether it's been used. I've also turned the debug log level up to see if I can see it hitting and the queries don't even hit nscd.

nsswitch.conf

# Begin /etc/nsswitch.conf passwd: files group: files shadow: files publickey: files hosts: cache files dns networks: files protocols: files services: files ethers: files rpc: files netgroup: files # End /etc/nsswitch.confenter code here

nscd.conf

# # /etc/nscd.conf # # An example Name Service Cache config file. This file is needed by nscd. # # Legal entries are: # # logfile <file> # debug-level <level> # threads <initial #threads to use> # max-threads <maximum #threads to use> # server-user <user to run server as instead of root> # server-user is ignored if nscd is started with -S parameters # stat-user <user who is allowed to request statistics> # reload-count unlimited|<number> # paranoia <yes|no> # restart-interval <time in seconds> # # enable-cache <service> <yes|no> # positive-time-to-live <service> <time in seconds> # negative-time-to-live <service> <time in seconds> # suggested-size <service> <prime number> # check-files <service> <yes|no> # persistent <service> <yes|no> # shared <service> <yes|no> # max-db-size <service> <number bytes> # auto-propagate <service> <yes|no> # # Currently supported cache names (services): passwd, group, hosts, services # logfile /var/log/nscd.log threads 4 max-threads 32 server-user nobody # stat-user somebody debug-level 9 # reload-count 5 paranoia no # restart-interval 3600 enable-cache passwd yes positive-time-to-live passwd 600 negative-time-to-live passwd 20 suggested-size passwd 211 check-files passwd yes persistent passwd yes shared passwd yes max-db-size passwd 33554432 auto-propagate passwd yes enable-cache group yes positive-time-to-live group 3600 negative-time-to-live group 60 suggested-size group 211 check-files group yes persistent group yes shared group yes max-db-size group 33554432 auto-propagate group yes enable-cache hosts yes positive-time-to-live hosts 3600 negative-time-to-live hosts 20 suggested-size hosts 211 check-files hosts yes persistent hosts yes shared hosts yes max-db-size hosts 33554432 enable-cache services yes positive-time-to-live services 28800 negative-time-to-live services 20 suggested-size services 211 check-files services yes persistent services yes shared services yes max-db-size services 33554432

resolv.conf

# Generated by dhcpcd from eth0 nameserver 127.0.0.1 domain westell.com nameserver 192.168.1.1 nameserver 208.67.222.222 nameserver 208.67.220.220

as kind of a side note I'm using Arch Linux.

note: this has been moved twice, I've never figured out why apps, excluding dig, are not hitting the nscd cache, browsers, IM, IRC, all should have been, but they didn't

Improve this question
1
  • You don't have to reboot the machine for ncsd, you can flush it or restart the service, works for me. Commented Jul 21, 2015 at 0:00

6 Answers 6

Reset to default
15

The reason why you are missing the cache hits is that dig queries the DNS directly. You can try and see whether the cache works with the getent command:

getent hosts host.example.com

Running a separate caching DNS is a good idea, but you should consider running it on the network level if possible. If each host cache the data separately they will still run multiple queries for the same hosts. Single cache works around this problem.

Nscd itself is a caching daemon for NSS functions. So the focus is a bit different than native caching nameservers. So if you just want a caching nameserver, use something else than nscd. If instead you wish to cache things like shared usernames and hostdata outside of the normal DNS system, go for nscd.

And for the record, I've grown quite fond of powerdns resolver (pdns-resolver).

Improve this answer
4
  • but shouldn't other stuff besides dig appear to be using it? this is a desktop system. I know that some of the software (like my package manager) doesn't implement its own cache. Commented Aug 2, 2010 at 20:53
  • Also outside of my ISP this is the only computer on the network ;) I'm just trying to avoid latency since my connection is slow. Commented Aug 2, 2010 at 20:55
  • 2
    Other software should indeed hit the nscd cache. Just make sure you restart the software after starting nscd. Commented Aug 4, 2010 at 10:41
  • I rebooted the system.... only software to seemingly attempt to use nscd was ntp. Commented Aug 5, 2010 at 4:01
3

You're missing the hosts configuration in nscd.conf. I'm posting mine as an example:

enable-cache hosts yes positive-time-to-live hosts 3600 negative-time-to-live hosts 20 suggested-size hosts 211 check-files hosts yes persistent hosts yes shared hosts yes max-db-size hosts 33554432

This will break some things. The following information is from the Debian package:

 Since this release, hosts caching in nscd is off by default: for some of the libc calls (gethostby* calls) nscd does not respect the DNS TTLs. It can lead to system lockups (e.g. if you are using pam-ldap and change the IP of your authentication server) hence is not considered safe. See debian bug #335476 and how upstream answered to that in http://sourceware.org/bugzilla/show_bug.cgi?id=4428. -- Pierre Habouzit <[email protected]> Sat, 28 Apr 2007 11:10:56 +0200
Improve this answer
1
  • 2
    actually I do have this you just have to scroll the file in the question. Commented May 6, 2010 at 11:48
2

I don't know that much about nscd except that it so often caused trouble with DNS lookups that I always disabled it (or at least the host lookups part of it). Nscd lets you set the time-to-live values and I know DNS expects to "own" those values and have all resolvers honor them. You can end up with weird results if the TTLs in DNS aren't honored. My recommendation is not to use nscd for caching DNS. It looks like you already have a caching name server running on your local box, so no need to cache DNS lookups twice.

Improve this answer
1
  • 1
    I was hoping to disable it, although it doesn't really matter (my box is so powerful the weight of bind for caching isn't an issue). This is partially a matter now of just learning something new. Not being able to get it to work is a bit annoying. Commented Apr 10, 2010 at 1:56
1

nscd is really unreliable for everything, not just DNS. It's well worth avoiding unless you desperately need it for some reason. You should use a purpose-made DNS caching daemon if you want to cache DNS locally (which is a good idea!).

Two of my favourites are dnsmasq and dnscache from djbdns.

Improve this answer
1
  • To use nscd, you need first to understand how it works, that it is a system cache system, not a plain dns cache daemon Commented Mar 5, 2018 at 19:51
1

If there is DNS caching in Hell, it is provided by nscd. Don't. Use. It.

Just to be different: pdnsd is actually a very nice replacement. Or unscd (used by default at least in openSUSE).

Improve this answer
2
  • +1 This. For small networks NSCD, or places with horrible DNS servers, this is a serious PITA. This has to be one of the most frequent reasons I see "newbies" rebooting Linux & Solaris servers any place I've worked. Commented May 22, 2014 at 13:57
  • 1
    link to pdnsd is down. Maybe this is a good link instead: members.home.nl/p.a.rombouts/pdnsd Commented Jan 14, 2015 at 18:14
1

I would like to add that when you have shared enabled your stats will not reflect correctly:

shared hosts yes

http://prefetch.net/blog/index.php/2006/02/08/viewing-name-service-cache-statistics/

I did not see anyone else mention this and it took me quite some time to figure out why my hit rate kept showing as 0%

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.