*Tags*: cache only dns server - caching only name server
dnsmasq - A small caching DNS proxy and DHCP server
dnsmasq is a lightweight DNS and DHCP implementation, designed for LAN's and is gaining popularity due to their ease of use and higher built-in security.
Configure dnsmasq dns forwarder http://leaf.sourceforge.net/doc/bk02ch13s03.html
set up dnsmasq serves http://www.ubuntuforums.org/showthread.php?t=200855
Dnsmasq is lightweight, easy to configure DNS forwarder and DHCP server. It is designed to provide DNS and, optionally, DHCP, to a small network. It can serve the names of local machines which are not in the global DNS. The DHCP server integrates with the DNS server and allows machines with DHCP-allocated addresses to appear in the DNS with names configured either in each host or in a central configuration file. Dnsmasq supports static and dynamic DHCP leases and BOOTP for network booting of diskless machines.
from http://www.ibiblio.org/pub/Linux/docs/HOWTO/DNS-HOWTO http://howtos.linux.com/howtos/DNS-HOWTO-3.shtml
A first stab at DNS config, very useful for dialup, cable-modem, ADSL and similar users.
On Red Hat and Red Hat related distributions you can achieve the same practical result as this HOWTO's first section by installing the packages bind, bind-utils and caching-nameserver. If you use Debian simply install bind (or bind9, as of this writing, BIND 9 is not supported by Debian Stable (potato)) and bind-doc. Of course just installing those packages won't teach you as much as reading this HOWTO. So install the packages, and then read along verifying the files they installed.
First you need a file called /etc/named.conf (Debian: /etc/bind/named.conf). This is read when named starts. What comes default from RH8 contains:
options {
directory "/var/named";
/*
* If there is a firewall between you and nameservers you want
* to talk to, you might need to uncomment the query-source
* directive below. Previous versions of BIND always asked
* questions using port 53, but BIND 8.1 uses an unprivileged
* port by default.
*/
// query-source address * port 53;
};
//
// a caching only nameserver config
//
controls {
inet 127.0.0.1 allow { localhost; } keys { rndckey; };
};
zone "." IN {
type hint;
file "named.ca";
};
zone "localhost" IN {
type master;
file "localhost.zone";
allow-update { none; };
};
zone "0.0.127.in-addr.arpa" IN {
type master;
file "named.local";
allow-update { none; };
};
include "/etc/rndc.key";
The Linux distribution packages may use different file names for each kind of file mentioned here; they will still contain about the same things.
The `directory' line tells named where to look for files. All files named subsequently will be relative to this. /var/named is the right directory according to the Linux File system Standard.
The file named /var/named/name.ca describes the root name servers in the world. It contains the following. You do not need to modify it.
; This file holds the information on root name servers needed to ; initialize cache of Internet domain name servers ; (e.g. reference this file in the "cache . <file>" ; configuration file of BIND domain name servers). ; ; This file is made available by InterNIC registration services ; under anonymous FTP as ; file /domain/named.root ; on server FTP.RS.INTERNIC.NET ; -OR- under Gopher at RS.INTERNIC.NET ; under menu InterNIC Registration Services (NSI) ; submenu InterNIC Registration Archives ; file named.root ; ; last update: Aug 22, 1997 ; related version of root zone: 1997082200 . 3600000 IN NS A.ROOT-SERVERS.NET. A.ROOT-SERVERS.NET. 3600000 A 198.41.0.4 [...] . 3600000 NS M.ROOT-SERVERS.NET. M.ROOT-SERVERS.NET. 3600000 A 202.12.27.33 ; End of File
The next section in named.conf is the last zone. You don't need to alter it either.
/var/named/named.local
$TTL 86400
@ IN SOA localhost. root.localhost. (
1997022700 ; Serial
28800 ; Refresh
14400 ; Retry
3600000 ; Expire
86400 ) ; Minimum
IN NS localhost.
1 IN PTR localhost.
The called rndc key in the controls sections specify that your named can be remotely controlled by a program called rndc if it connects from the local host, and identifis itself with the encoded secret key. This key is like a password.
All configure files comes with caching-nameserver rpm package are:
/etc/named.conf /var/named/localhost.zone /var/named/named.ca /var/named/named.local
/etc/resolv.conf looking something like this:
search ... nameserver 127.0.0.1
echo "nameserver 127.0.0.1" > /etc/resolv.conf
Note:
Named never reads this file, the resolver that uses named does. Note 2:
In some resolv.conf files you find a line saying "domain". That's fine, but don't use both "search" and "domain", only one of them will work
please note the lack of periods at the end of the domain names.
With the configuration about, our DNS server will contact one of the name server machines named in your "name.ca" file, and asked its way from there.
After all this it's time to start named. If you're using a dialup connection connect first. Now run named, either by running the boot script: /etc/init.d/named start or named directly: /usr/sbin/named. If you have tried previous versions of BIND you're probably used to ndc. In BIND 9 it has been replaced with rndc, which can controll your named remotely, but it can't start named anymore. If you view your syslog message file (usually called /var/log/messages, Debian calls it /var/log/daemon, another directory to look is the other files /var/log) while starting named (do tail -f /var/log/messages) you should see something like:
Oct 13 22:38:57 localhost named[18103]: starting BIND 9.2.1 -u named Oct 13 22:38:57 localhost named[18103]: using 1 CPU Oct 13 22:38:57 localhost named[18106]: loading configuration from '/etc/named.conf' Oct 13 22:38:57 localhost named[18106]: no IPv6 interfaces found Oct 13 22:38:57 localhost named[18106]: listening on IPv4 interface lo, 127.0.0.1#53 Oct 13 22:38:57 localhost named[18106]: listening on IPv4 interface eth0, 192.168.0.100#53 Oct 13 22:38:57 localhost named[18106]: listening on IPv4 interface ppp0, 64.7.158.155#53 Oct 13 22:38:57 localhost named[18106]: command channel listening on 127.0.0.1#953 Oct 13 22:38:57 localhost named[18106]: zone 0.0.127.in-addr.arpa/IN: loaded serial 1997022700 Oct 13 22:38:57 localhost named[18106]: zone localhost/IN: loaded serial 42 Oct 13 22:38:57 localhost named[18106]: running Oct 13 22:38:57 localhost named: named startup succeeded
If there are any messages about errors then there is a mistake. Named will name the file it is reading. Go back and check the file. Start named over when it is fixed.
% /etc/init.d/bind9 start % tail /var/log/syslog Jul 2 11:53:22 localhost named[21305]: no IPv6 interfaces found Jul 2 11:53:22 localhost named[21305]: listening on IPv4 interface lo, 127.0.0.1#53 Jul 2 11:53:22 localhost named[21305]: listening on IPv4 interface eth0, 192.168.0.100#53 Jul 2 11:53:22 localhost named[21305]: command channel listening on 127.0.0.1#953 Jul 2 11:53:22 localhost named[21305]: zone 0.in-addr.arpa/IN: loaded serial 1 Jul 2 11:53:22 localhost named[21305]: zone 127.in-addr.arpa/IN: loaded serial 1 Jul 2 11:53:22 localhost named[21305]: zone 255.in-addr.arpa/IN: loaded serial 1 Jul 2 11:53:22 localhost named[21305]: zone localhost/IN: loaded serial 1 Jul 2 11:53:22 localhost named[21305]: running
Now you can test your setup. Traditionally a program called nslookup is used for this. These days dig is recommended:
$ dig -x 127.0.0.1 ; <<>> DiG 9.2.1 <<>> -x 127.0.0.1 ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33807 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1 ;; QUESTION SECTION: ;1.0.0.127.in-addr.arpa. IN PTR ;; ANSWER SECTION: 1.0.0.127.in-addr.arpa. 86400 IN PTR localhost. ;; AUTHORITY SECTION: 0.0.127.in-addr.arpa. 86400 IN NS localhost. ;; ADDITIONAL SECTION: localhost. 86400 IN A 127.0.0.1 ;; Query time: 40 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Mon Oct 13 22:58:31 2003 ;; MSG SIZE rcvd: 93
If that's what you get it's working. We hope. Anything very different, go back and check everything. Each time you change a file you need to run rndc reload.
Now you can enter a query. Try looking up some machine close to you.
$ dig google.com
[...] ;; ANSWER SECTION: google.com. 300 IN A 216.239.53.99 [...] ;; Query time: 1019 msec ;; SERVER: 127.0.0.1#53(127.0.0.1)
This time dig asked your named to look for google.com. It then contacted one of the name server machines named in your "name.ca" file, and asked its way from there. It might take tiny while before you get the result as it may need to search all the domains you named in /etc/resolv.conf.
If you ask the same again you get this:
$ dig google.com [...] ;; Query time: 38 msec ;; SERVER: 127.0.0.1#53(127.0.0.1)
As you can plainly see this time it was much faster, 38ms versus more than one second earlier. The answer was cached.
With cached answers there is the possibility that the answer is out of date, but the origin servers can control the time cached answers should be considered valid, so there is a high probability that the answer you get is valid.
With the configuration about, our DNS server will contact one of the name server machines named in your "name.ca" file, and asked its way from there. But by using the DNS server of your network provider as a “forwarder” you can make the responses to queries faster and less of a load on your network. This works by your nameserver forwarding queries to your ISP nameserver. Each time this happens you will dip into the big cache of your ISPs nameserver, thus speeding your queries up, your nameserver does not have to do all the work itself. If you use a modem this can be quite a win.
For the sake of this example we assume that your network provider has two name servers they want you to use, with IP numbers 10.0.0.1 and 10.1.0.1. Then, in your named.conf file, inside the opening section called “options”, insert these lines:
forward first;
forwarders {
10.0.0.1;
10.1.0.1;
};
There is also a nice trick for dialup machines using forwarders, it is described in the “qanda” section.
Restart your nameserver and test it with dig. Should still work fine.
$ dig google.com [...] ;; Query time: 256 msec ;; SERVER: 127.0.0.1#53(127.0.0.1)
$ dig google.com [...] ;; Query time: 38 msec ;; SERVER: 127.0.0.1#53(127.0.0.1)
You can see it took much less time than previously. This is the difference between doing it all by yourself and by your ISP. The good part is that even if the DNS of your ISP fails on you, your DNS can still do it by itself.
Forwarding occurs only on those queries for which the server is not authori- tative and does not have the answer in its cache.
options {
directory "/var/named";
include "forward";
/*
* If there is a firewall between you and nameservers you want
* to talk to, you might need to uncomment the query-source
* directive below. Previous versions of BIND always asked
* questions using port 53, but BIND 8.1 uses an unprivileged
* port by default.
*/
// query-source address * port 53;
};
% /etc/init.d/bind9 start
Starting domain name service...: bind failed!
% tail /var/log/syslog
Jul 2 11:48:43 localhost named[21132]: starting BIND 9.3.4
Jul 2 11:48:43 localhost named[21132]: found 1 CPU, using 1 worker thread
Jul 2 11:48:43 localhost named[21132]: loading configuration from '/etc/bind/named.conf'
Jul 2 11:48:43 localhost named[21132]: /etc/bind/named.conf.options:2: change directory to '/var/cache/bind' failed: file not found
Jul 2 11:48:43 localhost named[21132]: /etc/bind/named.conf.options:2: parsing failed
Jul 2 11:48:43 localhost named[21132]: loading configuration: file not found
Jul 2 11:48:43 localhost named[21132]: exiting (due to fatal error)
$ head -2 /etc/bind/named.conf.options
options {
directory "/var/cache/bind";
mkdir /var/cache/bind
% /etc/init.d/bind9 start
Starting domain name service...: bind.
A caching only name server has no local zones; all the queries go to the root servers and the replies are accumulated in the local cache. The next time the query is performed the answer will be faster because the data is already in the server's cache. Since this type of server doesn't handle local zones, to resolve the names of the local hosts it will still be necessary to use the already known /etc/hosts file.
Since NetBSD supplies defaults for all the files needed by a caching only server, the configuration of this type of DNS is very easy, and can be performed with a few commands, without writing a single line in the configuration files.
Note: the number of the configuration files and their contents varies between versions of NetBSD.
The program which supplies the DNS server is the named daemon, which uses the named.conf configuration file for its setup. The default file supplied by NetBSD is located in the /etc/namedb directory, but the daemon looks for it in the /etc/ directory, so we start by creating a link:
# ln -s /etc/namedb/named.conf /etc/named.conf
The name server is ready for use! We can now tell to the system to use it adding the following line to the /etc/resolv.conf file:
nameserver 127.0.0.1
Now we can start named.
# named
Note: we have now started the name server manually. Once we have tested it and are confident that it works, we can launch it automatically at boot using the relevant option of the /etc/rc.conf file. 11.5.1. Testing the server
Now that the server is running we can test it using the nslookup program.
# nslookup Default server: localhost Address: 127.0.0.1
>
Let's try to resolve an host name, for example www.mclink.it (try a site near you.)
> www.mclink.it Server: localhost Address: 127.0.0.1
Name: www.mclink.it Address: 195.110.128.8
If you repeat the query a second time, the result is slightly different:
> www.mclink.it Server: localhost Address: 127.0.0.1
Non-authoritative answer: Name: www.mclink.it Address: 195.110.128.8
As you've probably noticed, the address is the same, but the message "Non-authoritative answer", has appeared. This message indicates that the answer is not coming from an authoritative server for the domain mclink.it but from the cache of our own server.
The results of this first test confirm that the server is working correctly.
We can also try the host command, which gives the following result.
# host www.mclink.it www.mclink.it has address 195.110.128.8
Newsgroups: comp.os.linux.networking Date: Wed, 22 Oct 2003 16:14:53 -0700
> I was trying to give an alias name to a foreign host. E.g., in my > /etc/hosts there are 2 entries. > > 127.0.0.1 test2 > google.com gg > > I hope that I can use "gg" as a short cut for google, in my caching > only name server environment. Thanks
/etc/hosts doesn't work that way:
IP_address canonical_hostname aliases
Consult the man page for further information.
ynotssor
> > I've successfully setup my local caching only name server for my dial up > > connection. Also, according to the faq, I add the forward section to the > > dns option section. It also works fine. > > > > However, I noticed that my local setting, which are in my /etc/hosts, > > are no longer valid. How to tell my DNS server to refer to my /etc/hosts > > first, then its cache, and last forward unknown host to my ISP's dns > > server? > > Hmm... to be more precisely: > > I was trying to give an alias name to a foreign host. E.g., in my > /etc/hosts there are 2 entries. > > 127.0.0.1 test2 > google.com gg > > I hope that I can use "gg" as a short cut for google, in my caching only > name server environment. Thanks
127.0.0.1 should always be localhost. If you want to assign your actual hostname to an IP, either use a LAN nic IP, or an extra loopback IP like 127.0.0.2 if you have no real interface that is always up. Your second line is invalid. See 'man hosts' for proper format.
While /etc/hosts may be used by programs that use gethostbyname(), it will not work for things that use DNS only (like nslookup or host command). If you wanted to set up such an alias for google you would need to add a properly configured zone for "gg" to work with your named (like gg. as CNAME for www.google.com. including trailing dots). See the DNS HOWTO. But do not expect something like that in a URL to work for name based virtual hosts, which serve different content based on Host header from browser.
David Efflandt
Newsgroups: gmane.linux.distributions.grml.user Date: Tue, 31 Oct 2006 18:48:39 -0500
On Tue, 31 Oct 2006 22:19:18 +0100, Michael Prokop wrote:
>> % /etc/init.d/bind9 restart >> Stopping domain name service...: bindrndc: connection to remote host closed >> This may indicate that the remote server is using an older version of >> the command protocol, this host is not authorized to connect, >> or the key is invalid. >> failed! >> Starting domain name service...: bind failed! > >> What could be wrong? > > Take a look at the syslog.
Oct 31 18:34:56 cxmr named[2554]: invalid command from 127.0.0.1#42763: bad auth
nothing else. Hmm… let's see:
There is still an old bind running:
bind 2554 1 0 Oct28 ? 00:00:00 /usr/sbin/named -u bind
Having killed it by 'kill 2554', I am able to start bind again, but with a little glitch:
% /etc/init.d/bind9 restart Stopping domain name service...: bindrndc: connect failed: connection refused failed! Starting domain name service...: bind.
bind 3146 1 0 18:38 ? 00:00:00 /usr/sbin/named -u bind
The syslog seems to be normal though:
Oct 31 18:38:30 cxmr named[3146]: starting BIND 9.3.2-P1 -u bind Oct 31 18:38:30 cxmr named[3146]: found 1 CPU, using 1 worker thread Oct 31 18:38:30 cxmr named[3146]: loading configuration from '/etc/bind/named.conf' Oct 31 18:38:30 cxmr modprobe: WARNING: Not loading blacklisted module ipv6 Oct 31 18:38:30 cxmr named[3146]: no IPv6 interfaces found Oct 31 18:38:30 cxmr named[3146]: listening on IPv4 interface lo, 127.0.0.1#53 Oct 31 18:38:30 cxmr named[3146]: listening on IPv4 interface eth0, 192.168.2.100#53 Oct 31 18:38:30 cxmr named[3146]: command channel listening on 127.0.0.1#953 Oct 31 18:38:30 cxmr named[3146]: zone 0.in-addr.arpa/IN: loaded serial 1 Oct 31 18:38:30 cxmr named[3146]: zone 127.in-addr.arpa/IN: loaded serial 1 Oct 31 18:38:30 cxmr named[3146]: zone 255.in-addr.arpa/IN: loaded serial 1 Oct 31 18:38:30 cxmr named[3146]: zone localhost/IN: loaded serial 1 Oct 31 18:38:30 cxmr named[3146]: running
If I restart it again, I get back the same error:
% /etc/init.d/bind9 restart Stopping domain name service...: bindrndc: connection to remote host closed This may indicate that the remote server is using an older version of the command protocol, this host is not authorized to connect, or the key is invalid. failed! Starting domain name service...: bind failed!
The syslog has the same message:
Oct 31 18:39:41 cxmr named[3146]: invalid command from 127.0.0.1#40741: bad auth
Ok, it is not that bad — my named can be started, but not restarted.
Any explanation?
> If I restart it again, I get back the same error: > > % /etc/init.d/bind9 restart > Stopping domain name service...: bindrndc: connection to remote host closed > This may indicate that the remote server is using an older version of > the command protocol, this host is not authorized to connect, > or the key is invalid. > failed! > Starting domain name service...: bind failed!
Ok, this meens, the key which rndc uses to stop the server is wrong.
> Any explanation?
To start the server, there is no key needed. If you stop it, a key is needed. So the rndc key is wrong.
I have also a solution, do an
,---- | mv /etc/bind/rndc.conf /etc/bind/rndc.conf.org `----
Btw. this is _not_ a bug in the debian package. The problem is imho, that grml ships that file.
Ulrich Dangel
Newsgroups: fa.netbsd.help Date: 2003-04-25 16:44:13 PST
I'm looking for a small caching DNS proxy suitable for dialup connections running on NetBSD 1.6 for i386. That means that the proxy may forward requests to the ISP's nameserver when the connection is up, but shall use the cache when the connection is down.
One idea was to run named, generate a new named.conf and send SIGHUP to named to force rereading of the configuration file. But I find named oversized for my single PC and difficult to configure.
Another idea was to use dnrd. The problem is, that I didn't succeed in compiling the sources, because they seem to use some missing Linux semaphore stuff. In addition I've read that dnrd's code isn't clean concerning buffer overflows.
Similiar with pdnsd. I think that would be my favorite caching DNS server, but compilation fails because of missing pthread stuff. The makefile wants to call gcc with a special phread option and phread.h. I've found a package mit-pthreads-1.60b6 but I'm not sure how to proceed. pdnsd's configure script ignores the installed phread headers, libraries and the gcc variant because all that isn't in the standard directories. Before I try to rewrite the makefile manually, I'd rather like to ask if I'm still on the track.
Maybe sombody knows an easy to use solution? Just another idea: if I don't succeed in compiling, can I use a Linux binary instead? I dispose also of Debian GNU/Linux 3.0 (Woody), but havn't yet set up any Linux emulation. I've heard, that only Read Hat and SuSE are supported. Is that true?
I don't want to manipulate /etc/resolv.conf dynamically, because the man page tells me, that the file is only read the first time a resolver function is called. That seems to me that a dynamic modification would not be noticed by the resolver.
Thomas
> One idea was to run named, generate a new named.conf and send SIGHUP > to named to force rereading of the configuration file. But I find > named oversized for my single PC and difficult to configure.
Federico's Guide explains setting up a caching name server in 263 words. What could be easier? You just have add the ability to turn recursion on and off, which looks from here like a little script to mv the right file into place and send a HUP.
That sure *seems* simpler than the other options you listed, but maybe I'm missing something?
James K. Lowden
> That sure *seems* simpler than the other options you listed, but maybe I'm > missing something?
Ack, it's quite simple. It's just that if there were ready to use NetBSD packages for dnrd or pdnsd, it could be *more* simple. And the latter ones have a much smaller footprint than bind (I think named is bind, isn't it?). I always try to get a smaller thing for my old, single PC at home, e.g. rather leafnode than inn.
In addition ipppd from isdn4linux offers an option ms-get-dns which implements the client side of RFC1877, i.e. let accept my ISP's suggestion of dns address. Is there something comparable in i4b? Then I could dynamically generate my forwarder option for named.conf.
Thomas
DNRD is a proxy name server. To clients on your home network, it looks just like a name server. In reality, it forwards every DNS query to the "real" DNS server, and forwards responses back to the client.
So, why would you want to use it? DNRD was designed for home networks where you might want to dial into more than one ISP (ie, your home ISP and a dialup connection to your office). The problem with multiple dialups is that you need to change /etc/resolv.conf for each one. With DNRD, this is no longer necessary.
Before DNRD, there was no easy way to change the default nameserver on a Linux system. You can play games with /etc/resolv.conf, such as copying other versions of this file in place depending on which ISP you're dialing into, but that is a pain. Instead, you can run DNRD on your dial-up machine. Whenever you dial into an ISP, run dnrd with the appropriate DNS server as an argument. Here's an example of how you would run it:
dnrd -s 1.2.3.4
http://dnrd.nevalabs.org/ The latest version of DNRD is 2.10.
/usr/share/doc/dnrd-2.10/INSTALL
The first thing you need to do is to make sure you're not running another name server like bind. Next, create the directory "/etc/dnrd". This directory does not need to have anything in it, but it does need to exist. Then, whenever you dial into an ISP, run dnrd with that ISP's nameserver as an argument:
dnrd -s 1.2.3.4
Also, you need to change /etc/resolv.conf to point to yourself. Of course, instead of running dnrd yourself each time you dial in, you can have it run automatically.
You can run dnrd with multiple, redundant servers as follows:
dnrd -s 1.1.1.1 -s 2.2.2.2 -s 3.3.3.3
If dnrd stops getting replies from the first server, it will time out and start forwarding all queries to the second server, etc.
/usr/share/doc/dnrd-2.10/README-cache
dnrd does now local caching if not turned off with the `—cache=off' command line switch. This is done by storing complete DNS server responses in a local cache area which expires from time to time.
Normal responses are held for at least 60 minutes but not longer than 6 hours. Negative responses (nslookup tells `Non existent host/domain') are stored for only five minutes. These settings are defined in cache.h
The cache knows also a high- and a lowwater mark. If after an expire the number of stored items is above the highwater mark (default 1000), cache items are removed until the lowwater mark (default 750) is reached. The values can be set with `—cache=[<low>:]high' on the command line.