KBTAG: kben10000110
URL: http://www.securityportal.com/lskb/10000100/kben10000110.html
Date created: 31/07/2000
Date modified: 25/08/2000
Date removed:
Authors(s): Kurt Seifried seifried@securityportal.com
Topic: Overview of DNS
Keywords: Network/DNS
DNS is an extremely important service for IP networks. I would not hesitate to say probably the MOST important network service (without it no one can find anything else). It also requires connections coming in from the outside world, and due to the nature and structure of DNS the information DNS servers claim to have may not be true. The main provider of DNS server software (named, the de facto standard) is currently looking at adding a form of DNS information authentication (basically using RSA to cryptographically sign the data, proving it is 'true'). If you plan to administer DNS servers I would say that OReilly and Associates DNS & BIND is required reading.
DNS clients must be told to use DNS, and what their DNS servers are. In Linux the following files are critical:
/etc/host.conf /etc/hosts /etc/resolv.conf
host.conf specifies the order in which DNS is resolved and some other items. The first line should be the order directive, this is usually set to "order hosts,bind" which means /etc/hosts will be checked first, and then DNS will be used. There is also a multi directive, which should be set on "multi on" as most machines have multiple IP addresses (127.0.0.1 and an Internet IP). There is a third useful option which is of limited use, "nospoof", this specifies that the server cannot send data to the network that is not labeled as from the server (i.e. it cannot impersonate other machines). There are ways for attackers to get around this, it is better to use firewalling rules, but specifying it won't hurt. The file should look like:
order hosts,bind multi on nospoof
The next important file is the hosts file, this is a simple mapping of names to IP addresses in the form "IP-Address fullname nickname", generally it only contains a few "critical" entries such as localhost, the local machine name and the gateway:
127.0.0.1 localhost.example.org localhost 10.0.0.1 gateway.example.org gateway mail 10.0.0.10 workstation.example.org workstation workbox
The last file is resolv.conf, which specifies DNS information, which nameserver(s) to use, what domains to search and which domain it belongs to. You can specify up to three DNS servers, generally speaking if all three fail you have larger problems to worry about then the workstation not being able to resolve names.
search example.org domain example.org nameserver 10.0.0.1 nameserver 10.0.0.2 nameserver 10.4.0.1
Most distributions are finally shipping bind 8.x, however none (to my knowledge) have shipped it setup for non-root, chrooted use by default. Making the switch is easy however:
-u
specifies which UID bind will switch to once it is bound to port
53 (I like to use a user called 'named' with no login
permissions, similar to 'nobody').
-g
specifies which GID bind will switch to once it is bound to port
53 (I like to use a group called 'named', similar to 'nobody').
-t
specifies the directory that bind will chroot itself to once
started. /home/named is a good bet, in this directory you should
place all the libraries and config files bind will require.
An even easier way of running bind chrooted is to download the bind-chroot package, available as a contrib package for most distributions, and install it. Before installation you will need a user and group called named (which is what the bind server changes it UID/GID to), simply use groupadd and useradd to create the user/group. Some packages uses holelogd to log bind information to /var/log/messages (as bind would normally do). If this isnt available you will have to install it by hand, which is a chore. In addition to this the default configuration file for bind is usually setup securely (i.e., you cannot query bind for the version information).
Another aspect of bind is the information it contains about your network(s). When a person queries a DNS server for information, they typically send a small request for one piece of information. For example what is the IP address for www.seifried.org? And there are domain transfers, where a DNS server requests all the information for say seifried.org, and grabs it and can then make it available to other (in the case of a secondary DNS server). This is potentially very dangerous, it can be as or more dangerous then shipping a company phone directory to anyone that calls up and asks for it. Bind version 4 didn't really have much security, you could limit transfers to certain server, but not selectively enough to be truly useful. This has changed in Bind 8, documentation is available at http://www.isc.org/bind.html. To make a long story short in Bind 8 there are global settings and most of these can also be applied on a per domain basis. You can easily restrict transfers AND queries, log queries, set maximum data sizes, and so on. Remember, when restricting zone queries you must secure ALL name servers (master and the secondaries), as you can transfer zones from a secondary just as easily as a master.
Here is a relatively secure named.conf file (stolen from the bind-chroot package at ftp://ftp.tux.org/):
options { // The following paths are necessary for this chroot directory "/var/named"; dump-file "/var/tmp/named_dump.db"; // _PATH_DUMPFILE pid-file "/var/run/named.pid"; // _PATH_PIDFILE statistics-file "/var/tmp/named.stats"; // _PATH_STATS memstatistics-file "/var/tmp/named.memstats"; // _PATH_MEMSTATS // End necessary chroot paths check-names master warn; /* default. */ datasize 20M; };
zone "localhost" { type master; file "master/localhost"; check-names fail; allow-update { none; }; allow-transfer { any; }; };
zone "0.0.127.in-addr.arpa" { type master; file "master/127.0.0"; allow-update { none; }; allow-transfer { any; }; };
// Deny and log queries for our version number except from localhost zone "bind" chaos { type master; file "master/bind"; allow-query { localhost; }; };
zone "." { type hint; file "named.zone"; };
zone "example.org" { type master; file "zones/example.org"; allow-transfer { 10.2.1.1; 10.3.1.1; }; };
DNS runs on port 53, using both udp and tcp, udp is used for normal domain queries (it's lightweight and fast), tcp is used for zone transfers and large queries (say dig www.microsoft.com). Thus firewalling tcp is relatively safe and will definitely stop any zone transfers, but the occasional DNS query might not work. It is better to use named.conf to control zone transfers.
ipfwadm -I -a accept -P tcp -S 10.0.0.0/8 -D 0.0.0.0/0 53 ipfwadm -I -a accept -P tcp -S some.trusted.host -D 0.0.0.0/0 53 ipfwadm -I -a deny -P tcp -S 0.0.0.0/0 -D 0.0.0.0/0 53
or
ipchains -A input -p tcp -j ACCEPT -s 10.0.0.0/8 -d 0.0.0.0/0 53 ipchains -A input -p tcp -j ACCEPT -s some.trusted.host -d 0.0.0.0/0 53 ipchains -A input -p tcp -j DENY -s 0.0.0.0/0 -d 0.0.0.0/0 53
would block zone transfers and large queries, the following would block normal queries (but not zone transfers, so if locking it down remember to use both sets of rules)
ipfwadm -I -a accept -P udp -S 10.0.0.0/8 -D 0.0.0.0/0 53 ipfwadm -I -a accept -P udp -S some.trusted.host -D 0.0.0.0/0 53 ipfwadm -I -a deny -P udp -S 0.0.0.0/0 -D 0.0.0.0/0 53
or
ipchains -A input -p udp -j ACCEPT -s 10.0.0.0/8 -d 0.0.0.0/0 53 ipchains -A input -p udp -j ACCEPT -s some.trusted.host -d 0.0.0.0/0 53 ipchains -A input -p udp -j DENY -s 0.0.0.0/0 -d 0.0.0.0/0 53
Chroot'ing DNS
http://www.etherboy.com/dns/chrootdns.html
Dents is a GPL DNS server, currently in testing stages (release 0.0.3). Dents is being written from the ground up with support for SQL backends, integration with SNMP, uses CORBA for its internals. All in all it should give Bind a serious run for the money, I plan to test and evaluate it, but until then youll just have to try it yourself. Dents is available at: http://www.dents.org/.
djbdns
djbdns is a small secure DNS server, the license is quite restrictive when it comes to redistribution (similar to Qmail). You can get it at: http://cr.yp.to/djbdns.html.