DNS for Dummies

return to index

Last updated on March 2nd 2001


Contents

Introduction
Goals for this Article
Important File Locations
Simple Name Resolution
Controlling Hostname Lookup Behavior
Defining Name Servers
Caching Only Name Server
Starting up BIND
DNS for Your Domain
Upgrading Your BIND
Securing Your Server
Books on DNS
Important Links

Introduction

DNS can be intimidating at first. What files do I modify? What do I put in them? How does it apply to Solaris, specifically? If you're used to another operating system, Solaris, like any new platform - might not be immediately obvious, as there are a few pecularities you should be aware of. This article will discuss DNS related issues under Solaris, using version 7 as the reference platform and the stock Sun version of BIND.

Further down, BIND v9.1.0 will be discussed as an upgrade to the stock version. You should definately consider upgrading this way, as there are several security holes that can compromise root on your box with the stock BIND v8.1.2 that ships with Solaris 7.

A few key terms to understand are needed before we dive in. BIND refers to the software that you will be interacting with. What it does is provide a domain name server (DNS) that translates hostnames into valid (hopefully) IP addresses. When it is running on your system, you will often see a process called named or in.named.

It's really quite simple to get going and keep DNS maintained. We won't be getting too involved in complex DNS setups, but will illustrate all the basics needed to get most jobs done and get you up and running in the least amount of time.

There are several ways to provide a name resolution to your local machine and it's users or to your entire office - or even the Internet in general. Among the possibilities are:

Depending on these needs determines how you will be setting up DNS and which files are to be modified and maintained. You should decide ahead of time what your needs are, but keep in mind that you can always modify this behavior at a later time quite readily.

Goals for this Article

Important File Locations

There are several key files that are involved in DNS operations. Here is a chart of where they are and what they do. Note that they are all basic text files and can be edited with any editor of your choice. Some modify system behavior immediately, while others require that you restart your named process using the system init scripts or sending the named process a "HUP" signal ("kill -HUP pid_of_in.named" at command line).

File location Function or purpose Restart named?
/etc/hosts Map of IP addresses to hostnames and aliases No
/etc/nsswitch.conf Controls how hostnames are resolved system-wide No
/etc/resolv.conf Specifies machines to use for name resolution No
/etc/named.conf Configuration file for BIND Yes
/var/named/* Various files as described below in the article Yes

Each of these files controls how your system works as far as the hostname to IP translation. Anything that relies on this functionality, like your Email, Web server or other similar services is affected by the changes you make. As such, you should practice the techniques presented here on a test machine first, before approaching your production boxen. If you modify files, always make a backup copy of it in case something goes wrong - you can always get your self out of a mess this way.

With that warning having been said, don't be intimidated by DNS. You can always reverse your changes with the backup file you'll be making (right?) and start your modifications from a known-working point.

Simple Name Resolution

Let's say you don't want to run a name server on your machine at all, as you just want a few local machines to be resolved from hostnames into IP addresses. When would you want this? Perhaps if you're running a small network at home, or have a few isolated test machines at work for testing. With a handful of machines and especially when they're not important to the Internet/outside world - this is the best way to handle things.

This can be accomplished under Solaris very easily, and without modifying more than one file. This file is /etc/hosts and contains a simple listing of IP addresses followed by the fully qualified hostname, followed by any aliases you wish to assign to that hostname. Here's a sample: 

# /etc/hosts
#

# localhost entry
#
127.0.0.1       localhost       

# machines on my network
#
192.168.0.1	router.mynetwork.com	router
192.168.0.2	server.mynetwork.com	server
192.168.0.3	desktop.mynetwork.com	desktop

Using this file alone, you can add entries for your machines. The domains do not need to actually exist (that is, be externally resolveable via DNS). It's best to keep the hostnames logically organized by network or purpose, and comment the entries so you're not guessing later on. In the example above, you'll see three machines listed - "router, server and desktop." These would represent three separate machines as determined by the differing IP addresses before the hostname. Following the fullly qualified hostname, you'll see an alias - which is merely the hostname itself, minus the domain information. This way, you could refer to those machines in commands or URLs simply by that name alone - and save yourself some typing.

If you're using the Apache Web server for instance, and you have virtual hosts set up - be careful here, as you must provide the aliases here in your httpd.conf file using the ServerAliases directive, or Apache might not behave as you expect. Other services might be similarly affected, so it's best to use fully qualified domain names wherever possible. Where these aliases come in handy the most is on the commandline when issuing commands, telnetting to them and so on.

With the above file, you could for example "telnet server" or "telnet server.mydomain.com" equally. These entries merely provide hostname translation on the particular machine it's on only. That is to say, the Internet or folks outside would not be able to resolve any of these hostnames into IP addresses. Therefore, you're not really providing any DNS service, but merely giving names to machines that you access locally. This may be all you want to accomplish, and in this case - you simply populate this file with all your machines with their appropriate hostnames and aliases. Ideally then, you would copy the contents of this file to each of the other machines to provide the same service and consistency.

As your network or needs grow, the obvious flaw with this technique becomes apparent. You must then modify each /etc/hosts file on each machine any time a change is required. While this works for a handful of machines in a lab or at home - it becomes overly tedious in a busy office or server environment. It also doesn't help people outside of your network find the necessary machines. If you don't need that, then a better solution would be to set up an internal DNS server. This is much like a normal DNS server setup, but using access controls, you can set it up so that only machines on your network can perform lookups against it, rather than the Internet at large. This would be the case if for example, you have a farm of back-end machines that the general public shouldn't know about or need to access anyway. The final step in the progression of providing DNS service is to run a full DNS server to the outside world. You could of course, also use NIS, NIS+ or even LDAP to do this, but this is outside the scope of this article and may be presented seperately at a later time.

Controlling Hostname Lookup Behavior

There is a file called /etc/nsswitch.conf which controls how Solaris performs it's hostname lookup functions. You can specify how a hostname is to be resolved for various services on the machine such as sendmail, users, networks and a slew of others. At the top of this file, you might typically see: 

# /etc/nsswitch.conf
#

passwd:     files
group:      files
hosts:      files dns
.
.
.

The line we're interested in is the "hosts:" line. This specifies how Solaris should perform the hostname resolution with which service and in what order to try them. In the example above, which is the most common scenario - is to look at "files" first (/etc/hosts) followed by trying to resolve the hostname via DNS.

In many out-of-the-box installs of Solaris, depending on how it was installed - you might only see a "files" entry. In this case, your machine will not try to resolve hostnames except by the contents of what's in the /etc/hosts file. This may be all you need, but it's very limited. What happens if you need access to an external machine that's out on the Internet somewhere? Without an entry in /etc/hosts or "dns" enabled in /etc/nsswitch.conf that hostname lookup will fail with "unknown host."

So, for the sake of this article, all you need to do is verify that the line for "hosts:" does indeed list "files dns" as in the above example. If "dns" is not there, add it now. This enables DNS lookups on your machine, and requires modifying another file as per below for /etc/resolv.conf.

Defining Name Servers

Once you've told Solaris how you want to resolve hostnames as above, you'll need to specify which machines to use as a name server. This is accomplished by listing them, along with a few other options in your /etc/resolv.conf file. A typical file might look something like this: 

# /etc/resolv.conf
#
domain mydomain.com
search mydomain.com myotherdomain.com
nameserver 127.0.0.1
nameserver w.x.y.z

With this example file, you'll notice that the first two lines specify options. The first is "domain" which identifies what domain you belong to. It should reflect the real thing, but you could always make up your own if you're at home or isolated from the Internet. The next line specifies domains which should be searched, and in what order - if you specify just a hostname, without the domain part. Remember the aliases you set up in /etc/hosts above?

If for example you try to telnet to your server with just "telnet server" then in the process of resolving the hostname "server" - depending on if you have an alias or not, will search for "server" in the domain listed for "search." Without an alias defined in /etc/hosts, Solaris will attempt to resolve the hostname via DNS. Otherwise, it will just use the /etc/hosts entry. This can be controlled via the "hosts:" line in the /etc/nsswitch.conf file. For example, if you wanted to try a real DNS lookup before looking up an alias you assigned, you could reverse the order so that it read "dns files" rather than "files dns."

The following two lines, prefaced with "nameserver" should have your local loopback IP of 127.0.0.1, followed by maybe another, outside name server or two. This latter name server may be provided by another machine on your network (in this example, the server) or your ISP. You normally specify three name server entries here, known as the primary, secondary and tertiary name servers. Why would you list more than one? What happens if the first machine listed goes down? So does your capability to do hostname resolution! With multiple entries, you provide a fallback mechanism in the event the previous entry drops offline. On a server and/or production environment, this is mandatory - or you're going to have issues.

If you specify only nameservers provided by your ISP or IT department for example, and do not include your loopback address, then you're basically done right here. You can now perform DNS lookups on hostnames. Try it - enter "/usr/sbin/nslookup everythingsolaris.org" at the command line, and you should be presented with something that looks like this: 

Server:  my.isp.dns.server
Address:  w.x.y.z

Non-authoritative answer:
Name:    everythingsolaris.org
Address:  24.186.183.249

Depending on what you entered as a "nameserver" entry in /etc/resolv.conf, that will be reflected in top top two lines of that output. This shows you which DNS server you're querying against. The following lines report back which IP address your hostname was resolved to. The statement, "Non-authoritative answer" means that this query was cached, and you did not query the master DNS server for that domain directly - which is known as the "authoritative server."

For now, you can get away with just the loopback IP address listed, as we'll be fussing with our configuration, and it's best not to confuse yourself by having outside lookups performed, possibly giving answers you don't expect yet.

Caching Only Name Server

With the above /etc/resolv.conf file, you can specify only an external name server, as perhaps supplied by your ISP or IT group (if you're not it) and not even set up a name server of your own. What this means is that you'll depend on that name server or servers only. This may be fine if you only need the occasional hostname resolution. But what if you run a Web server with hostname lookups enabled for your logging, or run sendmail to handle Email? For each hostname resolution, your machine would then have to go out onto the network (Internet or local) to do this. This adds overhead and slows down the process. What you would want to do then, is set up a local name server, but one that merely does a lookup for you (to an outside name server) and caches the result. This way, only the first hostname lookup would incur overhead as it contacted an outside server - thereafter, the resolution is cached locally. Perhaps you're just a power user and want extra speed from your machine - this is one way to do it. You could also do this "just because you can" and it's good for reducing network traffic, so you might as well!

To enable a basic, caching only name server on your machine becomes a little more complex than the previous modifications, as it now involves several files - including all of those above. Make the changes as shown in the demos above, modified to your environment (IP addresses and hostnames). Then, follow along below as we go through the various files that now need to be set up or modified.

First we'll set up a real basic configuration, to get up and running quickly. Later on we'll talk about security and restricting access to your name server. By default in Solaris, there is no file named /etc/named.conf and the named process is not started because of that. Once you create this file, upon startup the system init scripts will look for it and upon seeing it, start the named daemon for you. You could also start it up manually, so a reboot is not required. The first step then, is to create this file if it does not exist, or go over the configuration of it to set up a basic caching only name server. In it's simplest form, it should look something like this: 

# /etc/named.conf
#
options {
        directory "/var/named";    # Working directory
        pid-file "named.pid";      # Pid file in working dir
        /*
         * 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 askedquestions using port 53, but BIND
         * 8.1 uses an unprivileged port by default.
         */
        # query-source address * port 53;
};

zone "." {
        type hint;
        file "named.ca";
};

zone "0.0.127.in-addr.arpa" {
        type master;
        file "named.local";
        notify no;
};

It's fairly easy to follow near the top, as you're basically specifying the home directory for any files that follow via the "directory" line, and what to call the "pid-file" - which contains the process ID number of the named process that gets started for name resolution. If you're behind a firewall, you'll probably need to uncomment the line starting with "query-source" as it modifies BIND's behavior to deal with this. On an out-of-the-box install of Solaris, /var/named as a directory does not exist. You'll want to create this, as root, with the "mkdir /var/named" command, and then change the ownership with "chown root:sys /var/named" (as it's group is "other" by default).

The next two sections are where we do most of our magic. You'll notice that there are logical sections broken down into what are called "zones" and deal with one domain per section. Within that section you specify the type of zone it is (hint, master, slave, etc.) and what file to read in as that zone's configuration. Remember the "directory" directive near the top of this file - that is where these files will be expected. Within each zone section, you can specify a good number of other options, such as those for security and access control, but we won't get into that right now. For now, simple cut and paste what you see above into your /etc/named.conf file.

The first zone listed is the "root domain" as seen by the period (".") after the "zone" keyword. This applies to all domains from "/" (or root) on down - basically, every domain. The "type hint;" line means that this will be seeded by the root server file "named.ca" which we'll create down below. You'll want to include this as to provide the root name servers for the Internet to BIND, letting it know where to go for authoritative answers. This helps define a hierarchy that is DNS.

The next zone, or "0.0.127.in-addr.arpa" is merely for your loopback, or internal address. It's used by BIND to ground itself and should be included so that BIND knows just who and where "localhost" is.

The next step involves creating or modifying the two new files listed above - namely, /var/named/named.ca and /var/named/named.local. The first file is a list of the root domain servers for the Internet. It establishes the top level servers for all domains, and provides BIND a starting point to begin the hostname resolution part. For all BIND set ups, this is required and they're all the same - so this applies not only to a caching only name server, but also to a real name server set up, where you're providing DNS for your own domain(s). The file should look something like this: 

; /var/named/named.ca
;
.                        3600000  IN  NS    A.ROOT-SERVERS.NET.
A.ROOT-SERVERS.NET.      3600000      A     198.41.0.4
;
.                        3600000      NS    B.ROOT-SERVERS.NET.
B.ROOT-SERVERS.NET.      3600000      A     128.9.0.107
;
.                        3600000      NS    C.ROOT-SERVERS.NET.
C.ROOT-SERVERS.NET.      3600000      A     192.33.4.12
;
.                        3600000      NS    D.ROOT-SERVERS.NET.
D.ROOT-SERVERS.NET.      3600000      A     128.8.10.90
;
.                        3600000      NS    E.ROOT-SERVERS.NET.
E.ROOT-SERVERS.NET.      3600000      A     192.203.230.10
;
.                        3600000      NS    F.ROOT-SERVERS.NET.
F.ROOT-SERVERS.NET.      3600000      A     192.5.5.241
;
.                        3600000      NS    G.ROOT-SERVERS.NET.
G.ROOT-SERVERS.NET.      3600000      A     192.112.36.4
;
.                        3600000      NS    H.ROOT-SERVERS.NET.
H.ROOT-SERVERS.NET.      3600000      A     128.63.2.53
;
.                        3600000      NS    I.ROOT-SERVERS.NET.
I.ROOT-SERVERS.NET.      3600000      A     192.36.148.17
;
.                        3600000      NS    J.ROOT-SERVERS.NET.
J.ROOT-SERVERS.NET.      3600000      A     198.41.0.10
;
.                        3600000      NS    K.ROOT-SERVERS.NET.
K.ROOT-SERVERS.NET.      3600000      A     193.0.14.129 
;
.                        3600000      NS    L.ROOT-SERVERS.NET.
L.ROOT-SERVERS.NET.      3600000      A     198.32.64.12
;
.                        3600000      NS    M.ROOT-SERVERS.NET.
M.ROOT-SERVERS.NET.      3600000      A     202.12.27.33

In the example above, you'll notice a listing of servers and their IPs along with a few other pieces of data. We'll get into this more later on, but for now just cut and paste the example into your /var/named/named.ca file. This file can actually be dynamically generated through the use of the "dig" command, which does not come with Solaris. If you upgrade your BIND version, which you should, you'll get a copy of this command with the new BIND distribution. You could try just running "dig" on the command line - maybe you're lucky and someone installed it already. If it works, you'll be presented with output resembling the above, but perhaps in a longer version. This is basically the same thing as far as BIND cares. You can generate the /var/named/named.ca file with the line "dig > /var/named/named.ca" at the command prompt, as root.

The next file, /var/named/named.local is also more-or-less the same for every instance of BIND you're likely to encounter. Simply stuff the following into that file: 

; /var/named/named.local
;
@       IN      SOA     localhost. root.localhost.  (
                                      1997022700 ; Serial
                                      28800      ; Refresh
                                      14400      ; Retry
                                      3600000    ; Expire
                                      86400 )    ; Minimum
              IN      NS      localhost.

1       IN      PTR     localhost.

This basically just tells BIND what, who and where "localhost" is - your loopback interface. This is an internal interface that every Unix machine has. It simulates a network interface, but basically just "loops back" to itself. Mainly used for testing or specifying the local machine as a network target. When we set up actual domains below, you'll see what the individual lines mean and how they affect DNS.

If you also have the line "nameserver 127.0.0.1" in your /etc/resolv.conf file as above, DNS hostname resolution - should be working as it previously was, but now any hostname lookups you perform will also be cached locally. This will speed up redundant hostname resolution and reduce network traffic as your machine no longer needs to go out onto the network to resolve the same hostname until you restart BIND.

In order for these changes to take effect now, you'll need to restart your name server.

Starting up BIND

The named daemon under stock Solaris is /usr/sbin/in.named and is usually started upon system boot by the init scripts when the /etc/named.conf file is detected. If you're just setting up BIND and don't particularly want to reboot (and you shouldn't have to) then there are other methods to get it going.

The particular init script that is responsible for starting up named is /etc/init.d/inetsvc and basically does a file check to see if /etc/named.conf exists - and if so, start BIND. If it does not exist, named is simple ignored. You'll find many Solaris init scripts behave in this fashion - that is, looking for particular config files and if they exist, start the related service. It's a nice clean way to do it, but unless you know this it can be a little tricky when you're new to the platform. Under Linux for example, services are enabled by making the appropriate symbolic links within your /etc/rc.d/rc3.d directory to the responsible init script. This is really obvious as to what's being started, where and how - but requires modifying a lot of stuff. The Solaris approach is there when you need it, automatically.

To start or restart named (along with a few other services) you simply have to call the /etc/init.d/inetsvc script as root with the "stop" switch (to make sure we start fresh and kill processes currently running) followed by the "start" switch, which examines your new configuration and starts things up automatically - like named.

Note that you could also just run /usr/sbin/in.named at the command line as well. This is fine, but later on when we upgrade BIND to a later version, we'll need to specify options on the command line and doing it this way would be tedious. Instead, we'll modify the /etc/init.d/inetsvc script and let it do the dirty work for us.

Just stick with this procedure to start named under Solaris: 

# /etc/init.d/inetsvc stop
# /etc/init.d/inetsvc start
Setting netmask of hme0 to w.x.y.z
starting internet domain name server.
# _

You'll notice when you start things up, a line should hopefully appear as above, reading "starting internet domain name server." This means that your configuration files are in place and now, hopefully, named is running and ready to answer queries. You can verify this and also see if any errors came up when named started by looking at your /var/adm/messages log file. You should at least see something that looks like this: 

Mar  2 10:53:13 hostname named[20937]: starting.  in.named BIND
8.1.2 Tue Nov 10 1 8:16:24 PST 1998
Mar  2 10:53:13 hostname named[20938]: Ready to answer queries.

If that's the case, then you're aces and ready to move on. If there are any errors in formatting or syntax in your configuration files, you'll see them in the /var/adm/messages log file as well. The messages are usually pretty self-explanatory, so if you come across any you should be able to figure out what to do. Remember to restart named if you made changes to any configuration files and watch the log file output again until it's clean - or at least starts up with the "Ready to answer queries." entry.

If you're just updating files and named is already running, you could just send the named process a "HUP" signal, which would force named to re-read your configuration. This can be accomplished by running this at the command line, as root: 

kill -HUP `cat /var/named/named.pid`

DNS for Your Domain

The next logical progression of running your own DNS is if you own one or more domains, and your server is online and accessible to the Internet 24 hours per day, seven days per week, 365 days per year - or "24/7/365" as it's often referred to. Running your own domain name server is the ultimate level of control - and also responsibility. Should you decide to be the primary domain name server for your domain(s), you must ensure that you, or at the very least - your secondary domain name server(s) - stay up and running, online and accessible to the Internet at all times. You can't run DNS for a domain on a workstation that could be up or down at any given time, for example.

The way DNS works is that a server making an initial query to resolve a hostname performs a lookup. It does this by going up the chain of DNS servers until one of them has an answer. If none of the DNS servers along the way know the answer, it ultimately ends up at the primary domain server for that domain and asks it directly. From there, DNS servers along that route will most likely cache the result - if you're using a caching only nameserver then you yourself will have this cached locally. If the primary (and any secondary) nameservers for a domain are offline and unable to answer the DNS query - then your domain will not resolve, let alone any hosts within that domain. You will effectively "drop off the Net." The only way people can access your machines then is by using IP addresses, and this could hose up a lot of things, like Email, virtual hosts on your Webserver and so on. Not a good situation - so make sure that you also define at least one or more secondary name servers for your domain.

To further modify our Solaris configuration to handle DNS for a domain or domains requires simply that we add a zone section to /etc/named.conf file and add two new files under /var/named for each new domain. Once these things are accomplished, you'll need to restart your named process for the changes to take effect.

Let's make up a fictitious domain called "myfoobar.com" and set it up as if we're the primary domain name server for this domain. Hey, it could happen. Start off by modifying /etc/named.conf by adding a section that looks like this: 

zone "myfoobar.com" {
        type master;
        file "db.myfoobar.com";
};

This adds a zone for our domain, specifies that it is the "master" domain server for it and the file to look for information regarding this domain can be found in /var/named/db.myfoobar.com which we'll create in a moment. There's no security in this example, but we'll get into that later. For now just tell BIND that we're responsible for the new domain. Don't restart it yet, as we'll need to create the zone file for it first.

The zone file is much like the one we entered for "0.0.127.in-addr.arpa" and contains many of the same fields. However, this applies to an actual domain entry now and follows a slightly different format. This file will vary for every domain and must be customized for same to reflect IP addresses, aliases, Email addresses and a few other things such as the "TTL" or "Time To Live" value, expiration and refresh intervals, etc. This controls precisely how your domain is propogated throught the DNS hierarchy and luckily, you can follow a typical default setup for most cases. Here is what our /var/named/db.myfoobar.com zone file should contain: 

; /var/named/db.myfoobar.com - Created on 03/02/2001 by My Name
;

; REFRESH INTERVALS, ETC.
;
@     IN   SOA   myfoobar.com.  hostmaster.myfoobar.com. (
      2001030201 ; DB Serial Number
      10800      ; Secondary Refresh Interval
      3600       ; Secondary AXFR Retry Interval
      604800     ; Unref Secondary Expiry Interval
      86400 )    ; Minimum Time To Live

; NAME SERVICE
;
      IN  NS      my.host.name.here.
      IN  NS      a.secondary.server.here.
      IN  NS      b.secondary.server.here.

; MAIL
;
      IN  MX  10  myfoobar.com.
      IN  MX  20  backup.myfoobar.com.

; HOSTS WITH THIS DOMAIN NAME
;
myfoobar.com.   IN  A       w.x.y.z

www   IN  CNAME   myfoobar.com.
ftp   IN  CNAME   myfoobar.com.
mail  IN  CNAME   myfoobar.com.

In this exmaple, there are brief explanations as to what does, but let's get into the details a little more. In the first block, you'll see the "SOA record" which defines how domain will fit into the DNS hiearchy via timeouts, refresh intervals and who gets Email about it.

The first line establishes that this is an "SOA record" ("Start of Authority"), and you put in your domain name followed by something like "hostmaster.myfoobar.com" which specifies that the address "hostmaster@myfoobar.com" will receive Email regarding this domain as the primary name server. This is not related to who registered the domain, or who the administrative or technical contacts are. By and large the user is "hostmaster" but you can make this "root" if you wish. Leave it as something vague, and define an alias or forward in /etc/aliases if you wish to send it to multiple people or a regular user. In the case of Solaris, "hostmaster" isn't defined as an alias, so you may choose to use "root" but I usually prefer to define "hostmaster" as an alias that forwards mail to "root" or maybe also my own username. This way, if you choose to modify who gets these Emails, you simply change the alias and it's done. Otherwise, you'd have to edit the zone file and restart named and wait for your DNS changes to proogate to the world. A slow process at times and not very elegant.

On the next line, you specify a serial number which usually takes the format of "yyymmddnn" where "yyyy" is the year, "mm" is the month, "dd" is the day and "nn" is a number from 01 to 99. This lets you have up to 100 revisions of this particular file/domain on any given day. If you have more than that, you should really examine your DNS maintenance policies... Any time this file is modified, you must update this number! This tells other DNS servers if they have the current version or not when getting notified of changes.

On the following lines in the first block, you define a a period of time which is specified as a number of seconds. As the comments in our example indicate, these parameters control how often the secondary name servers are refreshed, what the retry interval is for zone transfers, when entries expire on secondaries and how long your DNS entry should remain alive via the "TTL" entry before other DNS servers start looking back to your server for validation. All of the values presented in the example above are good, generic values and should suffice in most cases.

In the next block as shown by the comment "; NAME SERVICE" you can list all the name servers that are involved with this domain. The first should be the primary, even if it's the current host. Follow that with any secondary name servers. It is important to note the period at the end of each line, or usually any time a hostname is given versus an IP address. If this period is missing, your BIND might startup, but you're going to have odd quirks happening. Likewise, each line must start with "IN NS."

The next block as shown by the comment "; MAIL" contains one or more entries for your "MX records" or "Mail eXchanger" hosts. These are machines that have (usually) sendmail running and ready to accept Email for the domain you're setting up. Often this will be the same machine, but not necessarily. You could do a little load balancing here by having one server for DNS, and another for sendmail. The value that follows the "IN MX" statement specifies the preference of that particular mail server. They are arbitrary numbers, but it's the order that's important - 20 is more than 10, just as 2 is more than 1. Often they're spread out a little (by ten or so) so that you can easily insert later on. The example shows two entries, meaning two separate mail servers - in the event the first is down, Email is sent to the second host listed. Once the first server is back online, normal order is restored.

The last section is where all your actual hosts are defined that reside within the domain. You must at least have the first line that specifies the IP address for your domain. In the example, this is the line that reads: 

myfoobar.com.   IN  A       w.x.y.z

You must specify your domain (in this case "myfoobar.com.") and what IP address it should resolve to which in this case "w.x.y.z" but should be replaced with your real IP address.

Following that line are several more which use the "IN CNAME" statement to define hosts within this domain. By using the "IN CNAME" statement, you're basically pointing these hosts back to whatever IP is listed for "myfoobar.com" If you wanted to have a separate machine for ftp and Web services, you could have different IP addresses instead and must use the "IN A" statement. It would look like this: 

www.myfoobar.com.   IN  A   a.b.c.d
ftp.myfoobar.com.   IN  A   e.f.g.h

By repeating the lines above, you can define any number of other hosts, such as workstations - that belong to your domain. For example, if your workstation is named "scooby" then you would add an entry as above with "scooby.myfoobar.com." followed by the IP address of your workstation. This would make "scooby.myfoobar.com" resolve to your IP address to the Internet at large. This is only the "forward lookup" part, and while it will do the job, you'll want to add another file here to do "reverse lookups" as well.

To finish up our task, we need add the aforementioned "reverse lookup" zone file. It's proper DNS etiquette to take this extra step, but it's not necessary to have your hosts resolve to the outside world. What it does is ensure that people can not only resolve your hostname to an IP address, but also to resolve your IP address back to your hostname. There are instances where this may be required for access or a number of other reasons - so it's best to do it the right way. To create this file, you must know the network that falls under your domain - and reverse it. In our case, that file would be called /var/named/db.w.x.y and the "z" octet of the IP address gets mapped to the individual hosts that fall under that network. This is done via the "PTR" or "pointer record." It would look similar to the following: 

y.x.w.in-addr.arpa. IN SOA myfoobar.com. hostmaster.myfoobar.com. (
        2001030201  ; DB Serial Number
        10800       ; Secondary Refresh Interval
        3600        ; Secondary AXFR Retry Interval
        604800      ; Unref Secondary Expiry Interval
        86400 )     ; Minimum Time To Live

; Name Service
;
y.x.w.in-addr.arpa. IN  NS        myfoobar.com.

; Hosts with this domain name
;

2       PTR         www.myfoobar.com.

This would define "w.x.y.2" as the reverse entry for "www.myfoobar.com" - again, note the trailing periods. Your values will of course vary from these examples, and you should certainly apply your own IP addresses and hostnames.

To make sure named reads this file in as well, don't forget to edit /etc/named.conf by adding lines similar to the following: 

zone "y.x.w.in-addr.arpa" {
        type master;
        file "db.w.x.y";
};

Finally! That's it. Your domain is all set now, and all you have to do is restart named for these changes to take effect! Keep in mind that if you use your own DNS server to resolve hostnames for your domain, the changes will be instantaneous as can be verified by the use of the nslookup command. However, to the outside world - this DNS propagation will take some time, ideally as specified by your "TTL" value in the zone file. In our example, this is set to 24 hours, or 86400 seconds. So it could take up to 24 hours (or slightly more) for DNS servers elsewhere in the world to know that you've made a change. Keep this in mind when making any changes to your domain's zone files. The updates are done automatically, so nothing further is required on your part.

Upgrading Your BIND

This section will be added at a later time, and will discuss the process of upgrading the stock Solaris 7 version of BIND, which is v8.1.2 - to the latest which is v9.1.0. This should be done by anyone running an Internet-accessible server providing DNS services. The version that comes with Solaris 7 has several severe security holes which will enable someone from the outside gaining root access to your server! The new version of BIND also adds more security features and takes advantage of symmetrical multi-processing (SMP) servers (with two or more CPUs) for faster name resolution on loaded servers.

When it starts and is working properly, you should see something like this: 

Mar 2 14:59:33 hostname /usr/local/sbin/named[7983]: starting
BIND 9.1.0 -c /etc/named.conf -n 2

Securing Your Server

Unless you're the very trusting type, you'd better secure your server some and control who has access to it. We can do this by controlling who can get information from it in the way of hostname lookups or "zone transfers" if you're running a primary and secondary domain name server setup. If for example you're running an internal name server for your office, you don't want just anyone on the Internet to be able to use you for DNS lookups. That would invite abuse and load your server unecessarily and in general, just bad policy.

You should definately consider upgrading your version of BIND first, as discussing security with the stock Solaris version of BIND would be moot. Many of the procedures below apply to this stock version, but some require features found only in the newer version of BIND. You can still control zone transfers and such, but what's the point if there's a hole in BIND that would let some cracker into your system as root? Upgrade. Do it now, then come back here.

Okay, all set? Here we go.

To control access, we use what is called an "ACL" or "Access Control List" that is defined within your /etc/named.conf file. A simple entry at the top of the file defines your groups: 

acl "allowDNS" { w.x.y.z/24; localhost; };
acl "bogusnets" { 0.0.0.0/8; 1.0.0.0/8; 2.0.0.0/8; 192.0.2.0/24;
                  224.0.0.0/3; 10.0.0.0/8; 172.16.0.0/12;
		  192.168.0.0/16; };

This sets up a group called "allowDNS" that contains the 192.168.0.4/24 network and the localhost. We'll use this to control who has access to the server to perform DNS queries. The second line adds The group "bogusnets" which contains network definitions of normally non-legitimate IP address ranges. These are often used when spoofing IP addresses or for various internal "test networks" as defined in RFCs. We'll use this group to "blackhole" or drop requests from these types of hosts. In the options section of /etc/named.conf, we must add these lines: 

allow-query { "allowDNS"; };              # Block access via ACL
blackhole { "bogusnets"; };               # Block spoofing

Then, just restart named as usual for the changes to take effect. Now you should have a name server that at least only answers queries from trusted hosts and not the Internet at large.

Books on DNS
DNS/BIND

This is the essential reference book on DNS/BIND, by O'Reilly. If you do a lot of work with DNS/BIND then you should definitely check this one out. Currently in it's third edition and rated as "five star!"

Important Links
BIND Website
BIND history
BIND mailing lists
BIND Freshmeat entry
Other BIND and DNS resources
Solaris DNS FAQ and Tip Sheet
Solaris Naming Administration Guide

Content and images are copyright 2001 by Michael Holve