OPENBSD NOTES: Bind on OpenBSD AUG 2005
REFERENCE: Identify the key files:
text config files
/etc/resolv.conf <- dns server resolution
Local DNS configuration
Place the DNS server information in /etc/resolv.conf
nameserver 64.21.192.4 nameserver 10.10.0.13 lookup file bind
bind
bind listens on TCP port 53 and UDP port 53 for queries from DNS clients or other servers. OpenBSD bind is installed in a chroot jail ( /var/named ) by default.
Contents:
dev/ etc/ master/ slave/ standard/
The bind configuration file:
/var/named/etc/named.conf
bind 9 cannot be started by rndc but can be controlled by it.
starting bind manually and testing
Start bind specifing the non-priv user 'named' in the chroot jail at debug level three.
named -t /var/named -u named -d 3
Information and errors will appear in the system log also:
cat /var/log/messages
configure bind to start up on system start
Edit the /etc/rc.conf file, adding the following line:
named_flags="-t /var/named -u named"
using rndc to perform tasks such as zone reloading
reload config file and all zones
rndc reload
reload a specific dns zone file for a domain
rndc reload domainname.com
check the status of the dns server
rndc status
checking the syntax of master zone file
The command named-checkzone will help troubleshoot syntax errors in your domain zone files.
named-zonecheck domain.com /var/named/master/db.domain.com
BELOW: Introduction to DNS guide by Peter Matulis (MORE DETAILED INFO)
Introduction to DNS
- including caching nameserver -
tutorial updated: Friday, July 22, 2005
operating system: OpenBSD 3.7 stable (July 15, 2005)
preamble
A caching DNS server is one way of improving one's internet browsing when you
have a slow link to an ISP. This tutorial will therefore be of most use to
those with a dial-up (regular modem) connection.
In general, what any DNS server does is resolves names to numbers. A name goes
in and a number, an IP address, comes out (there is also reverse resolving).
However simple this sounds, due to the complexity of the internet, the DNS
system can become surprisingly confusing.
There are several types of DNS servers. A caching type is one that does not
contain a raw mapping of names to addresses (such a type is called an
authoritative server which can be further subdivided into master [also called
a primary], slave, and stealth types) but acts as an intermediary between a
DNS client (or resolver) and another DNS server. A caching server is also
called a recursive server. Any type of DNS server can be given the title of
nameserver.
The key here is that when the caching server eventually finds the name/address
mapping and sends it to the requesting client it will remember the resolution
and store it inside itself. The next time the client makes the same request
the caching server will respond back immediately thereby saving a non-trivial
amount of time (you can think of it as a forward DNS proxy server). The slower
your connection to the internet the more benefit you will derive from such a
server. In order to maintain accuracy, there is a configurable expiration time
(time to live, TTL) on the server's data that forces it to periodically return
to the internet for updates.
Different operating systems will differ slightly in a DNS server's
implementation. I will be working with OpenBSD 3.4. Without too much trouble
you should be able to adjust to your environment.
Here is the breakdown:
1. introduction to DNS on OpenBSD
2. named.conf
3. the three standard zone files
4. starting and testing the server
5. rndc
6. debugging and query logging
7. forwarders
8. last words
9. resources
introduction to DNS on OpenBSD
In this section I will introduce some terms, concepts, and how OpenBSD
implements a DNS server.
First off, the actual software that runs the DNS service on most systems is
called bind. The main component in this software is a daemon called named
(prounounced "name-dee"). This daemon "listens" on TCP port 53 and UDP port 53
for queries from DNS clients or other servers.
OpenBSD now installs bind by default in a chroot environment. This limits the
amount of access any malicious individual could gain by exploiting
vulnerabilities in bind. In order to take advantage of this chroot jail bind
must run as a non-privileged user (such as user named). The jail is located at
/var/named. The contents of this directory will appear to be /, the root
directory. Nothing outside this directory will be accessible to it.
Here is the jail:
# ls -l /var/named
total 1044
drwxr-xr-x 2 root named 512 Sep 17 04:56 dev
drwxr-x--- 2 root named 512 Jan 10 00:18 etc
drwxr-xr-x 2 root named 512 Sep 17 04:56 master
drwxrwxr-x 2 root named 512 Sep 17 04:56 slave
drwxr-xr-x 2 root named 512 Jan 9 23:31 standard
The named configuration file named.conf is found under the etc directory.
Three other files which every kind of DNS server must have are found here
under the standard directory:
# ls -l standard/
total 40
-rw-r--r-- 1 root named 255 Sep 17 04:56 localhost
-rw-r--r-- 1 root named 258 Sep 17 04:56 loopback
-rw-r--r-- 1 root named 2560 Sep 17 04:56 root.hint
Version 9 of bind (the version we'll be using) can be controlled (but not
started) by the rndc utility. Its config file is /etc/rndc.conf.
So that's five files we'll be looking at.
A few things to keep in mind:
1. Other operating systems may call all the files we've seen so far by
different names.
2. OpenBSD is the only operating system I have seen that defines the
localhost domain.
named.conf
This is the main configuration file. All you should modify at this point is
the description of clients that will be connecting to the nameserver.
Currently it is set to answer queries from the 192.168.1.0 network. There are
also three zones set up. These are required for any nameserver. We will take a
look at them in the next section.
// $OpenBSD: named-simple.conf,v 1.4 2003/02/27 14:44:04 todd Exp $
//
acl clients {
192.168.1.0/24;
::1;
};
options {
version ""; // remove this to allow version queries
listen-on { any; };
allow-recursion { clients; };
};
// Standard zones
//
zone "." {
type hint;
file "standard/root.hint";
};
zone "localhost" {
type master;
file "standard/localhost";
allow-transfer { localhost; };
};
zone "127.in-addr.arpa" {
type master;
file "standard/loopback";
allow-transfer { localhost; };
};
the three standard zone files
As we saw already, the three standard zone files are:
1. root.hint
2. localhost
3. loopback
I will provide an explanation of each. These files are static and should never
have to be modified (although root.hint may be updated).
root.hint
The purpose of this file is to allow the server to contact a single root
server in order to download an authoritative list of root servers. So that's
why this zone is of type hint. It provides a clue on where to get info instead
of using its own data directly. This download occurs during server startup
after which this file is never used again.
When a nameserver is unable to answer a query it will contact one of the root
servers on this downloaded list which will return the address of another
server that can help. Your server will then contact this second server which
will reply with another server to question. This continues until your server
questions a server that knows the answer (to the original query).
This is where your server's cache comes into play. Each time it receives a
reply from any server along the way it will store (or cache) this information.
So a cache is built up not solely from the original query/answer. This is
important to understand.
I mentioned earlier that this file is required for any installation. Based on
what we now know, this file is not necessary if the server is servicing an
internal network. And even if you are connected to the internet, if the file
is missing bind has access to a list that was compiled in when the software
was created.
; formerly NS.INTERNIC.NET
;
. 3600000 IN NS A.ROOT-SERVERS.NET.
A.ROOT-SERVERS.NET. 3600000 A 198.41.0.4
;
; formerly NS1.ISI.EDU
;
. 3600000 NS B.ROOT-SERVERS.NET.
B.ROOT-SERVERS.NET. 3600000 A 128.9.0.107
;
; formerly C.PSI.NET
;
. 3600000 NS C.ROOT-SERVERS.NET.
C.ROOT-SERVERS.NET. 3600000 A 192.33.4.12
;
; formerly TERP.UMD.EDU
;
. 3600000 NS D.ROOT-SERVERS.NET.
D.ROOT-SERVERS.NET. 3600000 A 128.8.10.90
;
; formerly NS.NASA.GOV
;
. 3600000 NS E.ROOT-SERVERS.NET.
E.ROOT-SERVERS.NET. 3600000 A 192.203.230.10
;
; formerly NS.ISC.ORG
;
. 3600000 NS F.ROOT-SERVERS.NET.
F.ROOT-SERVERS.NET. 3600000 A 192.5.5.241
;
; formerly NS.NIC.DDN.MIL
;
. 3600000 NS G.ROOT-SERVERS.NET.
G.ROOT-SERVERS.NET. 3600000 A 192.112.36.4
;
; formerly AOS.ARL.ARMY.MIL
;
. 3600000 NS H.ROOT-SERVERS.NET.
H.ROOT-SERVERS.NET. 3600000 A 128.63.2.53
;
; formerly NIC.NORDU.NET
;
. 3600000 NS I.ROOT-SERVERS.NET.
I.ROOT-SERVERS.NET. 3600000 A 192.36.148.17
;
; operated by VeriSign, Inc.
;
. 3600000 NS J.ROOT-SERVERS.NET.
J.ROOT-SERVERS.NET. 3600000 A 192.58.128.30
;
; housed in LINX, operated by RIPE NCC
;
. 3600000 NS K.ROOT-SERVERS.NET.
K.ROOT-SERVERS.NET. 3600000 A 193.0.14.129
;
; operated by IANA
;
. 3600000 NS L.ROOT-SERVERS.NET.
L.ROOT-SERVERS.NET. 3600000 A 198.32.64.12
;
; housed in Japan, operated by WIDE
;
. 3600000 NS M.ROOT-SERVERS.NET.
M.ROOT-SERVERS.NET. 3600000 A 202.12.27.33
; End of File
Visit www.root-servers.org for more info on the root servers.
localhost
On OpenBSD we have our first forward name resolution zone. It resolves the
host name localhost to the loopback address 127.0.0.1.
; $OpenBSD: db.localhost,v 1.1 2003/01/20 22:30:13 jakob Exp $
$ORIGIN localhost.
$TTL 6h
@ IN SOA localhost. root.localhost. (
1 ; serial
1h ; refresh
30m ; retry
7d ; expiration
1h ) ; minimum
NS localhost.
A 127.0.0.1
AAAA ::1
loopback
Every nameserver is the master of its own loopback domain. The whole point of
creating the loopback interface is to reduce network traffic. Sending domain
queries about the loopback address across the network would defeat that
purpose.
The loopback domain is a reverse domain. It is used to map the loopback
address 127.0.0.1 to the host name localhost.
; $OpenBSD: db.loopback,v 1.1 2003/01/20 22:30:13 jakob Exp $
$ORIGIN 127.in-addr.arpa.
$TTL 6h
@ IN SOA localhost. root.localhost. (
1 ; serial
1h ; refresh
30m ; retry
7d ; expiration
1h ) ; minimum
NS localhost.
1.0.0 PTR localhost.
starting and testing the server
Let's start this beast:
# named -t /var/named -u named -d 3
So we've specified the chroot environment and the non-privileged user as well
as a debug level of three.
Let's look at our system's logs:
# tail /var/log/messages
Jan 11 00:51:54 apriori named[9146]: starting BIND 9.2.2 -t /var/named -u
named -d 3
Yeah! Good stuff.
Onto testing now. On the server, use tcpdump to see what's happening on the
wire:
# tcpdump -i tun0 -ttt -n not '(port 22 or 80 or 110)' { your mileage may
# vary }
Now find yourself a client (I'm using a Windows 2000 machine) and tell it to
use our OpenBSD box as its nameserver. Once that's done, open a web browser
and go somewhere. Check the tcpdump output. You should get many lines with
port 53 involved. This proves the server is working.
As explained in the preamble, the purpose of setting up a caching nameserver
is to take advantage of its cache. Therefore only stop or restart the server
when necessary for the cache is emptied when you do this.
rndc
The rndc utility, or the Remote Name Daemon Control program, provides some
control over the nameserver. It doesn't work out of the box. As a security
measure, it requires setting up before named will allow itself to be
controlled. That's what we'll look at now.
This tool does pretty much the same as ndc does in Bind 8. Here are its main
features:
* Reload a zone
* Stop the server
* View the server's status
* Turn on (or off) log querying
* Dump the server's cache to a file
* Flush the server's cache
* Change debugging levels
In order for this to work, the rndc and named configuration files, rndc.conf
and named.conf respectively, must be in agreement. We can use the rndc-confgen
tool to generate an appropriate configuration:
# rndc-confgen | tee /etc/rndc.conf
This yields:
# Start of rndc.conf
key "rndc-key" {
algorithm hmac-md5;
secret "OCC0vk4pyIkYMjeeHNSZ2A==";
};
options {
default-key "rndc-key";
default-server 127.0.0.1;
default-port 953;
};
# End of rndc.conf
# Use with the following in named.conf, adjusting the allow list as needed:
# key "rndc-key" {
# algorithm hmac-md5;
# secret "OCC0vk4pyIkYMjeeHNSZ2A==";
# };
#
# controls {
# inet 127.0.0.1 port 953
# allow { 127.0.0.1; } keys { "rndc-key"; };
# };
# End of named.conf
Due to the way I invoked the utility, the above configuration now resides in
/etc/rndc.conf. Cut out (or copy) the bottom portion and paste it into
named.conf.
The first chunk (for both files) specifies our secret key and the second chunk
(for both files; although slightly different for named.conf) specifies the
address and port of the nameserver to be controlled (otherwise known as a
channel).
Stop the server, start it, and then give rndc a dry run:
# kill `cat /var/run/named.pid`
# /usr/sbin/named -t /var/named -u named -d 3
# rndc status
number of zones: 3
debug level: 3
xfers running: 0
xfers deferred: 0
soa queries in progress: 0
query logging is OFF
server is up and running
Restarting named with its modified config file should of generated something
similar to the following in your system's log file:
Jan 11 19:18:13 apriori named[26221]: starting BIND 9.2.2 -t /var/named -u
named -d 3
Jan 11 19:18:13 apriori named[26221]: command channel listening on
127.0.0.1#953
To look at the cache's contents you must first dump it to file:
# rndc dumpdb
It is an ASCII text file and is, by default, named named_dump.db. It ends up
in the root of your chroot jail (probably /var/named).
One way to see that the cache is working is to dump the cache to file, perform
a grep for an element of some domain you have never been to, surf to that
domain, dump the cache again, and issue the same grep command:
# rndc dumpdb
# grep altamira named_dump.db
# rndc dumpdb
# grep altamira named_dump.db
{ then surf to, say, www.altamira.com }
Whereas before I got no output from grep I now get this:
altamira.com. 14 NS ns.uunet.ca.
www.altamira.com. 14 A 205.150.151.22
altamira.stockgroup.com. 1796 A 199.175.179.160
You can stop the server via rndc but you cannot start (or restart) it. We will
make more use of rndc in the next section.
debugging and query logging
Debugging is simply the logging of messages that are sent to your system's log
files (usually /var/log/messages). With the rndc tool we can change its level
to produce more or less information. Using the options trace, trace <some
level>, and notrace we can, respectively, increase the level, specify the
level, or turn off debugging. Below we specify a level of 2:
# rndc trace 2
The capture of communications related to name resolution is known as query
logging. In order to achieve this another adjustment must be made to
named.conf. Insert the following block of text:
logging {
channel query_info {
file "named_query.log" versions 3 size 10m;
severity info;
print-category yes;
print-time yes;
};
category queries { query_info; };
category resolver { query_info; };
};
{ the name of the channel }
{ the log filename, keep three rotated logs, rotate the log every 10 MB }
{ the "debug" level }
{ print the type of communication occuring for each message }
{ print the date and time for each message }
{ use the query_info channel for queries }
{ use the query_info channel for internet resolutions }
To remove the possibility for query logging (whether "queries" or "resolver")
replace the channel name ("query_info") with "null". To toggle such logging on
the fly use the rndc tool:
# rndc querylog
So with query logging activated issue the following command:
# tail -f /var/named/named_query.log
All name queries and internet resolutions should now be appended.
forwarders
So far we have been using our nameserver to scour the internet on its own in
search of name/address mappings. It talks to one server which will get an
answer on who to talk to next and so on. This is slow and inefficient.
Instead, the normal thing to do is to have it talk solely with the DNS servers
belonging to your ISP. Our server will then offload queries to one or two
servers which will handle the rest. Your ISP's nameservers also have huge
caches of their own that we can dip into directly. When we point our
nameserver to another nameserver like this we call this target nameserver a
forwarder.
An issue that arises when you're disconnected from the net is when you try
(for some reason) to resolve an external domain name. Your server will forward
the request along but will naturally be unable to connect. But then it will
try to contact the root servers as per our original config. It can take quite
a while for this to time out. To avoid this, we stipulate to only use the
forwarders (and not the root servers). There are other ways around this (see
here).
Implement all this by adding the next two lines to the options statement of
named.conf:
forward only;
forwarders { <your ISP DNS1>; <your ISP DNS2>; };
Reload your new configuration with rndc and test again with tcpdump. You
should see the server talking to your forwarder and there should also be far
less activity (less output). This indicates a more efficient setup.
Your final named.conf file should now look very similar to this:
// $OpenBSD: named-simple.conf,v 1.4 2003/02/27 14:44:04 todd Exp $
//
acl clients {
192.168.1.0/24;
::1;
};
options {
forward only;
forwarders { 198.235.216.114; 206.47.244.104; };
version ""; // remove this to allow version queries
listen-on { any; };
allow-recursion { clients; };
};
key "rndc-key" {
algorithm hmac-md5;
secret "sOiIv9PpNGDzWx2FAPlFGg==";
};
controls {
inet 127.0.0.1 port 953
allow { 127.0.0.1; } keys { "rndc-key"; };
};
logging {
channel query_info {
file "named_query.log" versions 3 size 10m;
severity debug;
print-category yes;
print-time yes;
};
category queries { query_info; };
category resolver { query_info; };
//category queries { null; };
//category lame-servers { null; };
};
// Standard zones
//
zone "." {
type hint;
file "standard/root.hint";
};
zone "localhost" {
type master;
file "standard/localhost";
allow-transfer { localhost; };
};
zone "127.in-addr.arpa" {
type master;
file "standard/loopback";
allow-transfer { localhost; };
};
last words
On OpenBSD, in order to start the bind daemon when the computer starts we edit
the /etc/rc.conf file. Make sure a similar line exists and is not commented
out:
named_flags="-t /var/named -u named"
and
named_enable=YES
Add whatever options you want but the ones shown above are the minimum.
Reboot and test.
If you get any "permission denied" errors in /var/log/messages you may need to
kill and restart named. Just reloading the configuration with rndc will not
rectify these errors.
I hope you enjoyed this tutorial. Hopefully your dial-up connection is now a
little faster. If you want to improve it some more the next step is to install
a web proxy server (which caches web page content instead of name/address
mappings).