< Day Day Up > |
Recipe 24.9. Running a Local Caching Name Server with djbdns24.9.1 ProblemYou want to set up a local djbdns caching name server just to serve your LAN. This will speed up DNS lookups, which in turn will speed up web surfing, email, and all Internet services. 24.9.2 SolutionThe caching component of djbdns is dnscache. First, prepare your system by installing daemontools, uspci-tcp, and djbdns (see Recipe Recipe 24.7). After installing everything, run a dnsip query to confirm that djbdns installed correctly: $ dnsip www.oreillynet.com
208.201.239.37 208.201.239.36 Now create two system users to own dnscache and dnslog. Call them anything you want. In this example, they are simply "dnscache" and "dnslog": # useradd -d /dev/null -s /bin/false dnscache # useradd -d /dev/null -s /bin/false dnslog Then configure the IP address and service directory for dnscache. This also assigns the appropriate file ownerships: # dnscache-conf dnscache dnslog /etc/dnscache 192.168.1.5 Create your "allow" list; this example permits your local subnet to use your dnscache: # touch /etc/dnscache/root/ip/192.168.1 Now start it up: # ln -s /etc/dnscache /service To verify that it's running, use svstat: # svstat /service/dnscache
/service/dnscache: up (pid 6776) 30 seconds To verify that it's working, run dnsqr to query the local cache: # env DNSCACHEIP=192.168.1.5 dnsqr a www.yahoo.com
1 www.yahoo.com:
193 bytes, 1+9+0+0 records, response, noerror
query: 1 www.yahoo.com
answer: www.yahoo.com 286 CNAME www.yahoo.akadns.net
answer: www.yahoo.akadns.net 60 A 66.94.230.52
answer: www.yahoo.akadns.net 60 A 66.94.230.48 Configure clients to point to your dnscache server (see Recipe Recipe 24.10), and you're finished. 24.9.3 DiscussionA caching server, or caching DNS resolver, does two things: it answers DNS requests by getting the information from other servers, and then it stores the results so that it can answer future requests for the same information directly. The cache lives only in memory, so restarting the cache's process or rebooting wipes it all out. A caching server and an authoritative DNS server should always be strictly separated. This means the IP address of your caching server should never match any IP addresses listed in NS records. A few bad things can happen when you put them together:
RFC 2010 also advises keeping caching servers separate from authoritative servers:
With BIND, you cannot separate the two. But you can with djbdns, as you will see in the following recipes. When you're testing dnscache, and making changes and generally futzing around, sometimes you'll find it won't stay up: # svstat /service/dnscache /service/dnscache: up (pid 6776) 1 seconds # svstat /service/dnscache /service/dnscache: up (pid 6781) 0 seconds You probably have too many instances of it running. Try this: # netstat -nap | grep ":53"
tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN 6327/dnscache
tcp 0 0 192.168.1.5:53 0.0.0.0:* LISTEN 6129/dnscache
udp 0 0 127.0.0.1:53 0.0.0.0:* 6327/dnscache
udp 0 0 192.168.1.5:53 0.0.0.0:* 6129/dnscache Yep, that's too many. You should have two instances only: listening on TCP port 53 and UDP port 53. Do a killall supervise dnscache, give it a few seconds, then try again: # svstat /service/dnscache /service/dnscache: up (pid 6776) 21 seconds # netstat -nap | grep ":53" tcp 0 0 192.168.1.5:53 0.0.0.0:* LISTEN 6776/dnscache udp 0 0 192.168.1.5:53 0.0.0.0:* 6776/dnscache That's what you want to see. Another common problem is having an old BIND server still running. There Can Be Only One. djbdns comes with a number of network querying and diagnostic utilities: dnsqr, dnstrace, dnsip, tinydns-get, dnsipq, dnsmx, and dnsname. See the links below to learn more about them. 24.9.4 See Also
|
< Day Day Up > |