Dec 2007
For most the domain name system appears to be a magical device which takes the name www.knucklebone.com and translates it to a machine address split across four (soon to be infinite) set of encoded octets . . . for some of us; there is no magic. Indeed the domain name system has rules, methods and models that can be rigorous to maintain, however, the payoff is a powerful centralized address translation system that works. In this series: an overview of the domain name system (DNS), a simple DNS setup and finally off to more elaborate configurations.
NOTE: Only the Berkeley Internet Name Daemon (BIND) on UNIX systems are in the examples, no other vendor or derived implementation of DNS services will be discussed.
In the absolute shortest sense, the domain name system takes a set of strings broken up by periods to determine:
In truth, it is a system of address resolution delegation. A computer that is attached to the local, wide or inter network has an Internet Address. This text will not get into the details of the addresses themselves suffice to say that what the domain name service does is takes a name like systhread.net and maps it to an IP address, the host command performs a lookup:
[21:44:43 jrf@vela:~]$ host systhread.net systhread.net has address 72.41.96.95
Of course the path to where the address is resolved varies by what network is being used . . . which is what makes DNS so great - no matter where you are . . . there it is. if it were only that simple, DNS is a distributed yet multi-platform system which makes it hard to grasp. In short; DNS leaves a lot up to faith even from a sysadmin point of view.
DNS breaks up strings using periods, quite the simple method but proven. It uses a syntax of:
hostpart.subdomain(s).domain.top-level-domain
The TLD or Top Level Domain is the last grouping. TLDs used to be confined
to com, net, org, edu and gov - now however there are many more TLDs.
The DNS address space works via delegation , for instance:
net TLD | systhread Domain | | alpha www Nodes
An address space can be further divided into subdomains, each reporting up and down their respective Zone of Authority or Primary Zone (in the example - systhread.net):
net TLD
|
systhread Domain
| | |
www alpha dmz
| | |
monitor logger vpngw
In example one there are three Unix hosts, one will act as the domain name server, a second is a web server and third a file storage system of some type. Here are the example IP addresses:
172.30.0.10 dns1 172.30.0.11 webserv1 172.30.0.12 stor1
In this first simple example; all 3 hosts need to be able to use dns1 for resolving addresses on the local network only. The domain name is foo.net.
For the first configuration; the only files needed are:
Each file has a specific format which looks like:
1. $TTL 86400 2. @ IN SOA foo.net. postmaster.foo.net. ( 3. 20071120 4. 3600 5. 300 6. 172800 7. 43200 ) 8. NS dns1 9. IN NS foo.net. 10. localhost A 127.0.0.1 ...
Of course since there is not a slave or secondary server yet; most of the entries are arbitrary. In this example; the location of the files will be:
/etc/named.conf /var/named/foo.net /var/named/172.30 /var/named/localhost /var/named/named.root
The named.conf file contains configuration data which manages how the local
DNS server works. There is a great deal that can be managed and configured
within the named.conf file; for the time being only the example is covered
while more topics are addressed in subsequent texts.
In this context things are pretty simple:
zone "." {
type hint;
file "named.root";
};
zone "0.0.127.IN-ADDR.ARPA" {
type master;
file "localhost";
};
zone "172.30" {
type master;
file "/var/named/172.30";
};
zone "foo.net" {
type master;
file "/var/named/foo.net";
};
As is obvious, the named.conf file's basic job is to define where the
data regarding zones is kept and what type of zone it is. In the example
all zones are master zones because there is only one DNS server. Note the
named.root file where data about other DNS servers on the internet is
kept - this file usually will be installed by your package manager.
Now it is time to set up the example zonefiles. Since the purpose of the top portion of the zone files was covered already, the only thing worth mentioning here is the format. Take careful note of trailing periods and how comments can be utilized; the example files below are very liberal with comments to save explanation.
localhost
$TTL 86400
@ IN SOA @ root (
42 ; serial
3H ; refresh
15M ; retry
1W ; expiry
1D ) ; minimum
IN NS @
IN A 127.0.0.1 ; the local reverse lookup address
foo.net
$TTL 86400 ; 1 day
foo.net IN SOA foo.net. postmaster.foo.net. (
20071120 ; serial
3600 ; refresh (1 hour)
300 ; retry (5 minutes)
172800 ; expire (2 days)
43200 ; minimum (12 hours)
)
NS dns1.foo.net. ; the nameserver itself for this zone
dns1 IN A 172.30.0.10 ; the nameserver
webserv1 IN A 172.30.0.11 ; our coolio webserver
stor1 IN A 172.30.1.12 ; the big ole storage boxen
172.30
$TTL 86400 ; 1 day
30.172.in-addr.arpa IN SOA foo.net. root.foo.net. (
20071120 ; serial
3600 ; refresh (1 hour)
300 ; retry (5 minutes)
172800 ; expire (2 days)
43200 ; minimum (12 hours)
)
NS dns1.foo.net.
10 IN PTR dns1.foo.net.
11 IN PTR webserv1.foo.net.
12 IN PTR stor1.foo.net.
The named.root file does not need to be shown; suffice to
say it is a standard file that can be grabbed with bindutils
or (as is often the case) ships with the pre-packaged bind
software.
Setting up a single simple DNS server is none too difficult other than
understanding some of the syntax of the zonefiles and named.conf
file. In the next part; setting secondary or slave servers,
a caching only server and other topics.
(based on last 2 months log reports)
