Print-friendly Version

Description

You never know when the set up for a trade show, demo, lab, or other project might come to a loggerhead because someone needs a robust internet domain name server (DNS). The function of the DNS is to act as the server that client applications contact to resolve an IP address from the host name. The IP address is then used by network routers to send data packets to the remote server.

In reverse mode, the DNS can also resolve host names when given an IP address. Many UNIX applications use this method to perform security checks, Address Resolution Protocol (ARP), or Reverse Address Resolution Protocol (RARP) to verify that the host name data and IP address do indeed match. For example, if you try to Telnet or FTP to a Solaris host from a renegade laptop using a valid but unresolvable IP address on the LAN, you may notice that it can take up to 60 seconds to receive the login prompt. You can fix this delay by simply adding an entry for host name and IP address into the maps on the primary network DNS.

Setting up a DNS from scratch can be complicated. Although you can read the man pages and generate valid map files from scratch, it is not very efficient. A better way is to follow an example template provided in the next section.

Back to Top

Solution

Installation

You should have at least a basic understanding of how DNS works and be proficient with a text editor like vi or Emacs.

Unpacking Instructions

Download this template to a work directory, such as /var. To unpack the file, at the command line type:

    zcat name.tar.Z | tar xvf -

Fast Installation Overview

For quick installation, do the following:

1. Determine what type of DNS you want and what support information you need from your network provider, such as global caching DNS.

2. Edit the named.* files you need. For releases prior to Solaris 7, use named.boot, named.local, named.cache, named.mydomain, and named.mydomain.rev. For Solaris 7 and Solaris 8, the map files are the same, but edit the named.conf instead of named.boot.

3. Edit the /etc/resolv.conf file. It should look like the following:

       domain mydomain.com
       nameserver 127.0.0.1     ;if DNS server runs on this host
       nameserver 129.200.9.1   ;if this is a remote client

4. Create a symbolic link in /etc/ to either the named.boot or named.conf file and start the DNS (/usr/sbin/in.named).

5. You can verify the DNS is working properly by running some queries to test forward and reverse resolution.

Back to Top

Detailed Installation

1. Determine what kind of DNS you need.

   If you are at a trade show and without Internet access, you need to be a primary.

   If you are at a trade show and have Internet access, find the ISP and ask whether they have (a) a world resolvable caching DNS and (b) a primary for the show floor. If they have (a) but not (b), you will need to be a primary for this subnet. Any reputable ISP will have at least (a). If they have both (a) and (b), but are unreliable for (b), you should be a secondary. If (b) does not have a complete map or maps, you may need to create your own primary for that subnet.

   If you are just starting a new subnet (e.g. you are at a startup company and the person who knows anything about network administration is the IT person), then you probably want to be your own primary for the subnet. You should talk it over with your ISP. If your ISP is responsive and reliable, and doesn't mind that you constantly re-assign IP addresses and hosts, you should use them as your primary. Otherwise, if you are planning to do some very complicated DHCP, IP address sharing, NAT, or network customization, you probably should be your own primary. In other words, if you want your network to be resolvable and routable outside of your network, you may want to arrange with your ISP to give you primary domain DNS control for your subnet and have the ISP act as a "secondary" to your subnet domain. This configuration is common at many large universities. For example, each department or college group manages its own subnet within a large Class A or B network. The institution's top level DNS is actually a secondary for the various smaller subnet primaries.

   If you need to resolve Internet host names outside of the corporate network, but have an inadequate primary DNS on your network, you should become a secondary DNS for your local subnet. You can also add a forwarders entry to the corporate top-level gateway DNS so that you can resolve IP addresses outside of the corporate network. Other people can then configure their hosts to use your DNS as their default to use these features.

2. If you are running Solaris 7 or Solaris 8, examine the named.conf file. If you are running releases prior to Solaris 7, see the named.boot file. Each file is self explanatory and you can copy the /etc/hosts file and add Authoritative records (A) and pointer records (PTR) to your maps.

   Note: For Solaris 7 users who are familiar with BIND8 (old) format named.boot files and want to convert them to the new BIND9 format named.conf files, you can run the /usr/sbin/named-bootconf -i infile -o outfile utility.

   Edit all the files you need, usually:

   Mandatory files
   named.boot or named.conf (depending on OS version)
   named.cache
named.local
   
   

   Optional files (for primary DNS)
   named.mydomain
named.mydomain.rev
   [other reverse or forward maps]

   You may have multiple forward and reverse maps because this DNS may be supporting multiple domain names and subnets.

3. Edit the /etc/resolv.conf file. It should look like the following:

       domain mydomain.com
       nameserver 127.0.0.1     ;if DNS server runs on this host
       nameserver 129.200.9.1   ;if this is a remote client

   You can have multiple DNS entries in the resolv.conf file. Each entry is searched in top-to-bottom order until the server responds, or times out. Therefore, you should put the server that is the most robust and responds the fastest at the top of the list. When a DNS is successfully queried, it is general practice for the client to use only that server for querying, even if the DNS responds that there are no entries. If the DNS you configured to use on the client is not resolving all of the hosts you know exist, you should contact the administrator for that DNS or simply change to a server that can resolve all the names. If a DNS server is down, you may experience a long wait before the client application fails and switches to use the next DNS. This can vary from 15 to 60 seconds per DNS entry in the resolv.conf file. If you are experiencing DNS resolution delays repeatedly and have access to another server, you should change the resolv.conf file to use another DNS.

4. Create a symbolic link in /etc/ to either the named.boot or named.conf file. For example, if you unpacked the file in /var/named on a Solaris 2.6 system, type at the command line:

       ln -s /var/named/named.boot /etc/named.boot

   Start the DNS server by typing:

       /usr/sbin/in.named

5. Test the DNS by running some queries to test forward and reverse resolution. You can use the following forward test:

       /usr/sbin/nslookup myhost

   A sample response looks like:

       Server: localhost
       Address: 127.0.0.1
    
       Name: myhost.mydomain.com
       Address: 129.200.9.1

   You should repeat your test using an IP address instead:

       /usr/sbin/nslookup 129.200.9.2

   A sample response looks like:

       Server: localhost
       Address: 127.0.0.1
    
       Name: myhost2.mydomain.com
       Address: 129.200.9.2

   If the DNS is set up to resolve Internet addresses, you can test this by typing:

       /usr/sbin/nslookup nuc.berkeley.edu

   A sample response looks like:

       Server: localhost
       Address: 127.0.0.1
    
       Non-authoritative answer:
   
       Name: nuc.berkeley.edu
       Address: 128.32.142.96

Disclaimer

This template is supplied "AS IS" without support or warranties.

Back to Top