DNS Server

DNS Introduction

DNS acronymn has many descriptions. To be perfectly honest, I am not sure which meaning is the correct one. There is domain name system, domain naming system, domain name server, domain name service. It doesn't really matter which one you pick because they all relate to the same basic function. Resolving domain names. If you are reading this your are probably already aware what general functions/service DNS provides. What you might not be aware of is the two different types of DNS.

DNS is broken down into two parts. The first part being providing answers to client workstation queries. The other part is providing answers to server DNS queries. While it is not important to know all the dirty little details you must be aware that depending on your requirements you may need two IP's for you DNS query. Don't panic yet though because you don't necessarily need two external IP's.

In this tutorial we will not be covering BIND. BIND is buggy, insecure, ugly, nasty, and is basically just a legacy service. We are going to be using something a little more modern and easy to use. We will be discussing the installation and configuration of DJBDNS. You will learn to love it.

Let's get the tutorial started.

Preparation:

Before we begin installing the DNS server we will need to make some decisions. As mentioned before there are actually two functions to DNS. There is a server query side and a client queury side. The server query is where you will actually setup a nameserver to have other DNS client side queries connect to in order to resolve a client request. In DJBDNS the application is called tinydns. On the other side of the coin is a client side query application and in DJBDNS the application is called dnscache. If you are confused, don't worry, it will all become clear soon.

In this tutorial we are going to setup our network to provide DNS server requests on on external ip address and internal dns client queries on our internal ip address. Let's break this down a little more. In our imaginary network we have several workstation behind our server firewall in the 192.168.0.255 subnet. Our firewall has an external ip address of 1.2.3.4. We would like to run our own nameserver so we can manage our own registered domains. The domain is mydomain.com. We would also like to use our own server for client DNS requests so our clients don't need to go outside of our own network for requests and we do not want everbody on the interenet to be able to see or use our client DNS server. Here are the ip's in our example network.

Internal Network: 192.168.0-253
Internal DNS: 192.168.0.254
External IP/DNS: 1.2.3.4

In this network all client workstations and our server will be using 192.168.0.254 as their DNS server. In our registered domain we will have 1.2.3.4 listed as our primary dns server. You can even just use the external DNS for your own local network (you may not want fred.mydomain.com to resolve externally but you do internally). Figure out what IP's you will need to use in order to match up best with your network.

NOTE: You can not have both tinydns and dnscache running on the same ip.

Install DJBDNS:

In order to run DJBDNS successfully we will need to install three ports: ucspi-tcp, daemontools, and djbdns.

# cd /usr/ports/sysutils/ucspi-tcp/; make all install clean
# cd /usr/ports/sysutils/daemontools/; make all install clean
# cd /usr/ports/net/djbdns; make all install clean
# mkdir /usr/local/dns

We need to install ucspi-tcp in order to allow axfrdns to run from from the tcpserver application. Daemontools is installed so we can monitor and restart djbdns in case it fails for some reason. DJBDNS is the application that is going to make all of this work so of course we need to install it.

Once all of the ports have been installed we will need to configure djbdns to match our network requirements.
| 2 | 20020729104339 | 2 | 20020729104339 |
| 94 | 4 | 20 | Configuring DJBDNS |The first thing to do is configure daemontools to montior the /service directory for services that we will need to be running and monitoring. We first need to create the directory.
# mkdir /service
Now that the directory is ready we need to create a shell script that will start up daemontools and monitor that directory. The following script was written by Matt Simerson at http://matt.simerson.net/

# fetch -o /usr/local/etc/rc.d/services.sh http://matt.simerson.net/computing/mail/toaster/services.txt
# chmod 755 /usr/local/etc/rc.d/services.sh
# ln -s /usr/local/etc/rc.d/services.sh /usr/local/sbin/services
# rehash
# services start

Now we have daemontools monitoring the /services directory and will start up and services that it finds in that directory automatically.

The next step is to configure our internal dns server using dnscache. Because we want all of our clients to be able to resolve DNS queries using our local server we need to assign the server to monitor all requests on 192.168.0.254 interface. By default dnscache will only answer requests from the local server (127.0.0.1) so we will also need to tell dnscache to listen to our entire 192.168.0.255 subnet. We will also need to tell our server to use 192.168.0.254 as it's nameserver.

# dnscache-conf bind bin /usr/local/dns/dnscache 192.168.0.254
# ln -s /usr/local/dns/dnscache /service/dnscache
# touch /service/dnscache/root/ip/192.168.0
# echo nameserver 192.168.0.254 > /etc/resolv.conf

Now you can test your local server to make sure that you can actually resolve domain name requests and ensure it is all up and running. One suggestion that I will make right now is that you don't, under any circumstances, use nslookup. I won't get into all the details but basically it won't give you the results you require. Use some of the applications provided by djbdns such as dnsip, dnsname, dnsq, dnsqr, etc.

Depending on the size of your network, your server, etc you may want to modify the cache size of dnscache. See the man pages for details.

The final step is to configure tinydns (and axfrdns for some special requests) to run as our DNS server on our external ip address 1.2.3.4. First let's get axfrdns configured.

# axfrdns-conf bind bin /usr/local/dns/axfrdns /usr/local/dns/tinydns 1.2.3.4
# vi /usr/local/dns/axfrdns/tcp; (and add the following line above the :deny statement)
:allow,AXFR=""
# cd /usr/local/dns/axfrdns
# make
# cd $owd

Now configure tinydns

# tinydns-conf bind bin /usr/local/dns/tinydns 1.2.3.4

Now let's put them in the /service directory to be managed by daemontools

# ln -s /usr/local/dns/tinydns /service/
# ln -s /usr/local/dns/axfrdns /service/

The next article will give you information on configuring tinydns data that you will serve

Managing DNS Data for Tinydns:

The first thing that you will need to know is that all information we will be creating for our DNS to server will be saved in /service/tinydns/root/data. Whenever we make changes to the data file we must run make in that folder to recreat the data.cdb database. To do this simply: cd /service/tinydns/root/; make

As you can/will see there are several scripts available to you in /service/tinydns/root. I do not recommend using these scripts as you can only add information to data and you can not manage it easily. Personally, I like to create my own file and add all sorts of helpful information and keep all the various domain information grouped together. Feel free to use the scripts as examples of how to add entries but I suspect you will end up ediditing the data file manually.

Alright, now that that is out of the way let's start learning about tinydns data file and how to manage it. Please remember to always run make after changing any of the information in data as mentioned above. If you don't run make then any changes you do make will be discarded.

For this example we will list three machines for names, one alias, one mail server, and one additional name server. Here is the information we have gathered for our imaginary network.

server.mydomain.com 1.2.3.4
fred.mydomain.com 1.2.3.10
ns1.mydomain.com 1.2.3.11

Mail Server: server.mydomain.com
Additional Name Server: ns1.mydomain.com

Now here is the information that we would enter into our data file:

####################################################
# SITE: mydomain.com
# ADMIN: Bob Smith
# EMAIL: bsmith@mydomain.com
# REGISTRAR: networksolutions.com
####################################################
=server.mydomain.com:1.2.3.4:86400
=fred.mydomain.com:1.2.3.10:86400
=ns1.mydomain.com:1.2.3.11:86400
+www.mydomain.com:1.2.3.4:86400
@mydomain.com:1.2.3.1:a::86400
.mydomain.com:1.2.3.11:a:259200
# You could also use this as the nameserver
# .mydomain.com::ns1.mydomain.com
.3.2.1.in-addr.arpa:1.2.3.11:a:259200

Basically it is fairly easy to follow. All of the numbers at the end are simply timeouts for DNS cache listings (when they should expire in a dns cache). The 'a' listed in some of the entries simply differenciates between various records using the same domain (you may have two mail servers and use one as a backup for example). Let's break it down:
# Comment Entry

I recommend you use comments as much as possible

=machine.domainname.com:1.2.3.4:86400

This entry is for standard cname ip assignments. Simply list the machine name and domain with the ip address assigned to it and a timeout expiration for how long this entry should be saved in DNS cache.

+alias.domainname.com:1.2.3.4:86400

Enter in an alias for a particular ip address. You can also use *.domainname.com to forward all requests to a particular ip.

@domainname.com:1.2.3.4:a::86400

This entry is for MX records that will forward mail requests to the appropriate ip address. The 'a' differenciates the various mail servers for one domain. This is in case you have a backup mail server to save messages to.

.domainname.com:1.2.3.4:a:259200

This entry is for nameservers. If you have another nameserver for this domain you may list that entry here.

.3.2.1.in-addr.arpa:1.2.3.4:a:259200

This is the reverse lookup information for our 1.2.3.4 system. Mostly just used for DNS server queuries.

Regions

If you had various regions you would like to support it is simple enough to add that information to the nameserver. An example of a regious would be having different records for a DNS supporting your internal network and supply information externally. In the simplest scenario you would have your internal 192.168.0 subnet in a region and all other requests in another region:

%IN:192.168.0
%EX:

Now you would simply add the region at the end of the line to separate the entries.

%IN:192.168.0
%EX:
####################################################
# SITE: mydomain.com
# ADMIN: Bob Smith
# EMAIL: bsmith@mydomain.com
# REGISTRAR: networksolutions.com
####################################################
=server.mydomain.com:1.2.3.4:86400::EX
=server.mydomain.com:192.168.0.4:86400::IN
=fred.mydomain.com:1.2.3.10:86400::EX
=fred.mydomain.com:192.168.0.10:86400::IN
=ns1.mydomain.com:1.2.3.11:86400::EX
=ns1.mydomain.com:192.168.0.11:86400::IN
+www.mydomain.com:1.2.3.4:86400::EX
+www.mydomain.com:192.168.0.4:86400::IN
@mydomain.com:1.2.3.1:a::86400::EX
@mydomain.com:192.168.0.1:a::86400::IN
.mydomain.com:1.2.3.11:a:259200::EX
.mydomain.com:192.168.0.11:a:259200::IN
.3.2.1.in-addr.arpa:1.2.3.11:a:259200::EX
.0.168.192.in-addr.arpa:192.168.0.11:a:259200::IN

For more information on the tinydns data format see the man pages for tinydns-data.

Note: DO NOT FORGET TO RUN MAKE