Volume Number: 23 (2007)
Issue Number: 07
Column Tag: Networking
by Ben Greisler
To paraphrase Steve Ballmer, "DNS! DNS! DNS!"
What is the "DNS" and why is it so danged important? DNS stands for Domain Name Service and it is the method of translating domain names to IP addresses. Almost every aspect of network usage involves some level of name services and without it problems will pop up, sometimes in ugly ways.
In this article, we will assume that you know that you need to provide DNS services for your network. There are a number of ways you can do this including using OS X Server which has BIND (Berkeley Internet Name Domain) built in, but say you don't want to spend the $500 to $1000 that OS X Server will cost? Is there a lower cost way of doing this? If you have a spare OS X client machine hanging around, the answer is yes. With just a little bit of time and some low-key effort, you can get BIND running on almost any OS X client machine.
A common scenario is that you just bought a shiny new Xserve and in the process of setting it up you turn on DNS services and pop in a few machines that you need records for. Nice and simple. Apple has done a reasonable job of giving administrators an easy method to get DNS up and running. Some people will argue that it is too simple and basic, but it is enough for Open Directory to be happy if you are setting up an OD master and clients trying to authenticate against it. An issue comes up when you realize that best practice states that you should have two DNS servers to provide some redundancy.
The basic steps we will take are to provide a method of starting up the BIND DNS server already in OS X, provide it with the proper configuration and give it some records to work with. There are a number of files involved:
/System/Library/StartupItems/BIND/BIND /System/Library/StartupItems/BIND/StartupParameters.plist /etc/rndc.key /etc/named.conf /etc/hostconfig /var/named/named.local /var/named/named.ca /var/named/localhost.zone /var/named/db.192.168.254 (this is an example) /var/named/greisler.org.zone (this is an example)
Some of these files exist and will need modification; others will need to be built from scratch. None of it is hard, and following the steps below will get you a running DNS server faster and easier than you would expect.
In this article, we will be using a machine with OS X 10.4.9 installed on it. The test domain is greisler.org. Since OS X client has BIND already installed, all we need to do is get it running; it is really straightforward. The following steps will allow BIND to start every time the machine starts using a StartupItem. We will then provide a way to control the server.
Creating the StartupItem
Open up Terminal or ssh into the machine. I know some people will be unhappy with this, but I find that logging in as root makes things a bit easier while setting up the DNS server.
Create a folder named BIND within /System/Library/StartupItems and navigate to it:
mkdir /System/Library/StartupItems/BIND cd /System/Library/StartupItems/BIND
Create two files within the BIND folder:
touch BIND touch StartupParameters.plist
Open up the BIND file in your favorite editor and drop in the following text:
#!/bin/sh
. /etc/rc.common
if [ "${DNSSERVER}" = "-YES-" ]; then
ConsoleMessage "Starting Cheap BIND DNS Server"
/usr/sbin/named
fi
Make BIND executable:
chmod +x BIND
Open up the StartupParameters.plist file in your favorite editor and drop in the following text:
{
Description = "Cheap DNS Server";
Provides = ("DNS Server");
OrderPreference = "None";
Messages =
{
start = "Starting Cheap BIND DNS Server";
stop = "Stopping Cheap BIND DNS Server";
};
}
Allow BIND to be controlled:
We now need to make the RNDC (Remote Name Daemon Controller) configuration files:
rndc-confgen -a
Letting OS X know that we want a DNS server to run:
Open up /etc/hostconfig in your favorite editor and drop in the following text:
DNSSERVER=-YES-
With those steps, we have made ourselves a functional DNS server all ready to go, but now we need to give it some information on what to serve. If you have access to OS X Server, it is an easy job of setting up your configurations and copying over the various zone files. If you don't, you can use the following examples as a template and just modify them with the appropriate data for your environment. In this article, we are using greisler.org in the 192.168.254.x range as the example.
In a nutshell, we need to build a forward zone file that converts names to IP addresses, a reverse zone file that converts IP addresses to names and then we need to tell the named.conf file that they exist for usage.
Forward Zone File:
To build the forward zone file, navigate to /var/named and make a file that will contain the forward zone information:
cd /var/named touch greisler.org.zone
Inside the file build out the zone information you need, such as:
$TTL 86400
greisler.org. IN SOA nameserver.greisler.org. admin.greisler.org. (
2007010201
3h
1h
1w
1h )
greisler.org. IN NS nameserver.greisler.org.
greisler.org. IN A 192.168.254.240
nameserver.greisler.org. IN A 192.168.254.240
test.greisler.org. IN A 192.168.254.22
dnsiscool.greisler.org. IN A 192.168.254.23
bubba.greisler.org. IN A 192.168.254.24
Reverse Zone File:
To build the reverse zone file, navigate to /var/named and make a file that will contain the forward zone information:
cd /var/named touch db.192.168.254
Inside the file build out the zone information you need, such as:
$TTL 86400
254.168.192.in-addr.arpa. IN SOA nameserver.greisler.org. admin.greisler.org. (
2007010203
3h
1h
1w
1h )
254.168.192.in-addr.arpa. IN NS nameserver.greisler.org.
240.254.168.192.in-addr.arpa. IN PTR nameserver.greisler.org.
22.254.168.192.in-addr.arpa. IN PTR test.greisler.org.
23.254.168.192.in-addr.arpa. IN PTR dnsiscool.greisler.org.
24.254.168.192.in-addr.arpa. IN PTR bubba.greisler.org.
Modifying named.conf
To allow the DNS to recognize those zones, we need to tell /etc/named.conf about the zone files by editing /etc/named.conf and placing the following text within it:
zone "greisler.org" {
type master;
file "/var/named/greisler.org.zone";
};
zone "254.168.192.in-addr.arpa" IN {
file "db.192.168.254";
type master;
};
Testing the DNS Server:
Restart the computer and test the DNS server:
nameserver:~ backup$ host -a dnsiscool Trying "dnsiscool.greisler.org" ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32764 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1 ;; QUESTION SECTION: ;dnsiscool.greisler.org. IN ANY ;; ANSWER SECTION: dnsiscool.greisler.org. 86400 IN A 192.168.254.23 ;; AUTHORITY SECTION: greisler.org. 86400 IN NS nameserver.greisler.org. ;; ADDITIONAL SECTION: nameserver.greisler.org.86400 IN A 192.168.254.240 Received 97 bytes from 192.168.254.240#53 in 18 ms
We can see from this example we have asked for the A records for dnsiscool.greisler.org and it returned in the answer section that its IP address is 192.168.254.23, which is what we expected. We can try this for the PTR or reverse look up records:
nameserver:~ backup$ host -a 192.168.254.23 Trying "23.254.168.192.in-addr.arpa" ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21546 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1 ;; QUESTION SECTION: ;23.254.168.192.in-addr.arpa. IN PTR ;; ANSWER SECTION: 23.254.168.192.in-addr.arpa. 86400 IN PTR dnsiscool.greisler.org. ;; AUTHORITY SECTION: 254.168.192.in-addr.arpa. 86400 IN NS nameserver.greisler.org. ;; ADDITIONAL SECTION: nameserver.greisler.org. 86400 IN A 192.168.254.240 Received 122 bytes from 192.168.254.240#53 in 2 ms
We asked for the PTR record for 192.168.254.23 and it returned in the answer section, dnsiscool.greisler.org. Success!
There are many good references on how to build a zone file, but I find that the easiest way to get started is to look at an existing file and to understand what is in it. We have the sample zone files earlier in the article, so let's dissect them and see what we find.
Forward Zone:
A forward DNS record is called an "A" record. This is the type of record that might get used when you enter a URL into a browser and the DNS system needs to find its associated IP address. Our sample forward zone file is located in /var/named and looks like this:
$TTL 86400
greisler.org. IN SOA nameserver.greisler.org. admin.greisler.org. (
2007010201 ; serial
3h ; refresh
1h ; retry
1w ; expiry
1h ) ; minimum
greisler.org. IN NS nameserver.greisler.org.
greisler.org. IN A 192.168.254.240
nameserver.greisler.org. IN A 192.168.254.240
test.greisler.org. IN A 192.168.254.22
dnsiscool.greisler.org. IN A 192.168.254.23 bubba.greisler.org. IN A 192.168.254.24
The first line gives us the TTL or Time To Live. This is how long cached data will live on your DNS server.
The second line includes the SOA or Start Of Authority. This tells us that this 'nameserver' is authoritative for this domain. The portion that has admin.greisler.org declares the email address of the zone contact. Notice it doesn't use the standard email format we are normally used to (admin@greisler.org); It simply replaces "@" with a dot.
The following section is slightly modified from the earlier examples as I have added notations for the definitions of each line. The data in this section is mostly for use with slave DNS servers and doesn't impact us at the moment. The serial number is exactly that; it allows us to serialize the zone file for whatever usage we may want. In this case, it is the date the zone was made.
The 8th line tells us which DNS server is authoritative for the zone. We only have one listed in this example, but we typically would list two or more depending on the size of the environment.
The following lines include the actual information regarding the records we want to resolve. For example if the server "bubba.greisler.org" had the IP of 192.168.254.24, we write it out as:
bubba.greisler.org. IN A 192.168.254.24
Note that there is a trailing dot after the server name. Be careful with your dots and make sure they are in the right places. FYI: "IN" means Internet and is the class of record. The "A" means address.
Reverse Zone:
The reverse zone allows the DNS server to resolve IP addresses into host names. In the OS X server world, without reverse lookups many things will fail badly, such as a login to Open Directory. A reverse record is known as a pointer record or PTR. Let's look at our example:
$TTL 86400
254.168.192.in-addr.arpa. IN SOA nameserver.greisler.org. admin.greisler.org. (
2007010203
3h
1h
1w
1h )
254.168.192.in-addr.arpa. IN NS nameserver.greisler.org.
240.254.168.192.in-addr.arpa. IN PTR nameserver.greisler.org.
22.254.168.192.in-addr.arpa. IN PTR test.greisler.org.
23.254.168.192.in-addr.arpa. IN PTR dnsiscool.greisler.org.
24.254.168.192.in-addr.arpa. IN PTR bubba.greisler.org.
Most of the information from the forward zone is the same or similar to the reverse zone except that we define the IP address first. You might have noticed that the IP addresses are listed in reverse order and have ".in-addr.arpa." tagged onto them; this is the correct formatting. Also, note the trailing dot after each host name.
The /etc/named.conf file:
The /etc/named.conf file contains the configuration information for the 'named' daemon. What was important to us was to enter the information for the new zones, forward and reverse, that we made and make 'named' aware of them. In the example below you will see the entries that begin with "zone" and how they point at the "zone file" files in /var/named.
You will see zone file entries for named.ca, localhost.zone and named.local. The named.ca file holds the DNS root server information. These are the official top-level DNS servers of the hierarchical DNS search process. The other two files provide local information, which is consistent on all machines. Basically, it defines what "localhost" and "127.0.0.1" are.
The file also contains information regarding what gets logged and where it gets logged. This may be important if you have a non-standard place you like to have the logs located. You can choose different levels of logging including: info, debug, notice, warning, error, critical, alert and emerg.
//
// Include keys file
//
include "/etc/rndc.key";
// Declares control channels to be used by the rndc utility.
//
// It is recommended that 127.0.0.1 be the only address used.
// This also allows non-privileged users on the local host to manage
// your name server.
//
// Default controls
//
controls {
inet 127.0.0.1 port 54 allow {any;}
keys { "rndc-key"; };
};
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
//
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; };
};
zone "greisler.org" {
type master;
file "/var/named/greisler.org.zone";
};
zone "254.168.192.in-addr.arpa" IN {
file "db.192.168.254";
type master;
};
logging {
category default {
_default_log;
};
channel _default_log {
file "/Library/Logs/named.log";
severity info;
print-time yes;
};
};
There is much more to utilizing DNS itself, but we have given you the tools to build a DNS server. You can now use this server as a spare, a test bed for configurations or anything else you can think of.
A common use of DNS within a network is to refer to devices specific to our network, such as file servers. We can also put in entries for IP printers, individual workstations or anything that has an IP address. It is a lot easier to remember "3rdfloorprinter" than "172.16.23.192." It is also handy to have people hitting your email server by its internal address rather than having to go outside the network only for it to come back in.
There are many references to use when dealing with DNS. The standard reference seems to be the Liu and Albitz book, DNS and BIND. It is a great book that requires some effort to get through, but seems to do its best answering specific questions. It isn't something that you would sit down and read from front page to back at one shot, but it's content is top notch.
When doing web searches for information on BIND, it is good to know what version you are running. The latest version of OS X at the time this article was written was 9.3.2. You can check yours by typing in command line "named -v" and it will return the version:
nameserver:~ backup$ named -v BIND 9.3.2 Make sure you peruse the man pages for the following: named named.conf rndc rndc.conf rndc-confgen
Gather your resources and newly minted DNS server and have at it. DNS server management is a skill that is rewarded with smoothly running systems.
Ben has been everything from a Mac user to CTO of one of the leading Macintosh professional services firms. Besides writing an occasional article for MacTech, you can find him presenting at Macworld (including a session called "DNS: Demystified, co-presented with Doug Hanley) or consulting with clients around the world. You can reach him at ben@greisler.org.
