Make your own free website on Tripod.com

SETTING UP YOUR OWN DNS

 

All hosts on the Internet, or any TCP/IP network for that matter, have an assigned 32-bit IP address. Most hosts have a name, as well, since host names are easier to remember than host addresses. The Domain Name System (DNS) is the distributed database that contains the names and addresses of all reachable hosts on a TCP/IP subnet, including the Internet.

Most, but not all, Internet service providers (ISPs) will set up and maintain the DNS information for their customers. There are several reasons, however, that a customer may want to operate their own DNS. This article will describe Internet domain names and the structure of the DNS, followed by a brief tutorial about creating and maintaining the DNS information.

INTERNET DOMAIN NAMES AND STRUCTURE

Internet host names use a hierarchical address structure comprising a top-level domain, subdomain, and host name. Top-level domain names and IP network addresses are assigned and maintained by the Internet Assigned Numbers Authority (IANA), which is responsible for the overall coordination and management of the DNS. Domain administrators are responsible for host name and address assignment within their domain.

                            "root"

                              .

                              |

  -----------------------------------------------------------...

  |       |       |      |     |     |     |    |    |    |

 com     edu     gov    mil   org   net    us   fr   ca   jp

  |       |       |                        |              |

  |    --------   |                     -------           ac

  |    |      |   |                     |     |           |

  |   uvm   smcvt |                     vt    ca         keio

  |               |                     |                 |

  -------      ---------              state              inst

  |     |      |       |                |                 |

 hill  mfi   ntia  whitehouse          dps               myo

  |

golem

FIGURE 1. Domain name tree.

 

The Internet naming hierarchy is best understood if a host name is read from right-to-left. All host names end with a top-level domain name (Figure 1). Generic top-level domains (although generally limited to the U.S.) include com (commercial organizations), edu (educational institutions, primarily 4-year colleges and universities), gov (U.S. government agencies), mil (U.S. military), org (non-profit organizations), net (network providers), and int (international treaty organizations).

The host name smcvax.smcvt.edu, for example, is assigned to a VAX computer (smcvax) within the St. Michael's College (Colchester, VT) subdomain (smcvt), which is within the educational top-level domain (edu). The name golem.hill.com refers to a host (golem) in the Hill Associates subdomain (hill) within the commercial top-level domain (com).

Other top-level domain names use international two-letter country codes, such as au (Australia), ca (Canada), de (Germany), es (Spain), fr (France), jp (Japan), mx (Mexico), and us (United States).

Each country determines for themselves how the country-based subdomains, and the associated DNS database, will be organized. The US domain, for example, is mostly organized on the basis of geography, usually using a name of the form organization.city.state.US; the format may be slightly different for special names, such as those for state government or K-12 and 2-year educational institutions. The address cnri.reston.va.us, for example, refers to the Corporation for National Research Initiatives located in Reston, Virginia. The ca subdomain within the us high-level domain does not cause a conflict with the ca high-level domain; the former refers to California and the latter to Canada. The host name myo.inst.keio.ac.jp refers to a system at the Science and Technology Department of Keio University in Yokohama, Japan; note that the ac subdomain within jp refers to academic institutions.

THE NAMING PROBLEM

As mentioned above, host names are easier to remember than IP addresses. Use of host names, then, is a convenience for the humans who use the network. The network has to provide some sort of name-address translation, however, for the network to operate.

The HOSTS.TXT file was used in the ARPANET prior to the definition of the DNS. This file contained the IP address, name, and alias(es) of every host on the ARPA network. This was a suitable scheme during the days when the network had only a few hundred systems and the network not very dynamic, but is wholly unsuited for the Internet with almost ten million hosts (as of January 1996) and 10% growth per month!

HOSTS.TXT files are still used, however. Their main function today is to contain the names of local systems so that one machine on a LAN (or other local network) can find other local systems without having to perform a DNS lookup. When TCP/IP software is configured on a host, the location of the HOSTS.TXT file must be provided if the file is used by a given system.

Domain: foo.com

IP address: 192.168.210.0



mail.foo.com       dns.foo.com       router.foo.com

192.168.210.4      192.168.210.2     192.168.210.1

---------------    --------------    ----------

| Mail server |    | DNS server |    | Router |===== Internet

---------------    --------------    ----------

      |                |                |

=============================================== LAN

     |               |                    |

-----------     -----------      -------------------

| User #1 |     | System  |      | WWW/FTP server; |

-----------     | Manager |      | backup DNS/mail |

pc1.foo.com     -----------      -------------------

192.168.210.5   pc2.foo.com      mail2.foo.com

                192.168.210.6    dns2.foo.com

                Alias:           192.168.210.3

                sysman.foo.com   Aliases:

                                 www.foo.com, ftp.foo.com,

FIGURE 2. Sample network for this article.

 
TABLE 1. Sample HOSTS.TXT file for the foo.com domain.
192.168.210.1   router.foo.com     router

192.168.210.2   dns.foo.com        dns

192.168.210.3   mail2.foo.com      www ftp mail2 dns2

192.168.210.4   mail.foo.com       mail

192.168.210.5   pc1.foo.com        pc1

192.168.210.6   pc2.foo.com        pc2 sysman
 

A sample HOSTS.TXT file is shown in Table 1 for the fictitous FOO.COM domain shown in Figure 2. Each line contains three fields: the IP address, host name, and (optionally) any aliases the system might use. As an example, a system on the local LAN that is trying to make an ftp connection to the local ftp server may attempt to open a connection to 192.168.210.3, ftp.foo.com, ftp, www, mail2, or dns2.

THE DOMAIN NAME SYSTEM

The DNS is a distributed database that contains the names and/or addresses of every host that is accessible via the Internet. The DNS was one of the key developments that allowed the Internet to grow as it has. Unlike the HOSTS.TXT files, which have to be individually maintained at every host on the network and be synchronized to ensure their correctness, DNS files are maintained by thousands of hosts on the network, each responsible for a portion of the name space (called a zone). The DNS provides a mechanism so that backup databases can be identified in case the first one becomes unavailable. DNS databases are updated automatically so that information on one name server does not remain out-of-date for long.

When TCP/IP software is installed on a host, the address (not the name!) of one or more (usually no more than three) name server(s) is one of the configured parameters. When the host attempts to establish a connection to another IP host, it will first check its local HOSTS.TXT file (if there is one) for the name of the remote host. If the remote host is not in the HOSTS.TXT file, the host will send a query to the primary DNS name server. The primary name server may well not contain the information about the particular destination host; in that case, the query must be forwarded to another name server that is higher up on the domain name hierarchy.

Consider the following example. Suppose a user on a system at Baz University (domain baz.edu) wishes to initiate a connection to the WWW server at Foo Corp. (www.foo.com). The following name resolution steps would occur:

  1. The Baz host will check its HOSTS.TXT file. In this example, Foo's WWW server is not found.
  2. The Baz host will then check its primary DNS name server. Since the Baz DNS server probably only covers the baz.edu zone, it will not contain Foo's WWW server's address; instead it will forward the query.
  3. The query is passed to a name server higher up in the DNS hierarchy. A database exists for every top-level domain and it contains the name of every subdomain within that top-level domain, and its assigned name server(s). When the higher-level name server checks the com DNS file, it will find an entry for foo.com and the address of its DNS server(s). This information is returned to the Baz DNS server.
  4. The query is forwarded to one of the name servers for foo.com, which returns the IP address of the WWW server (198.168.210.3).
The DNS can be examined with a number of common TCP/IP tools. The most common DNS lookup utilities are NSLOOKUP and Host. If you turn off the recursive option, you can see these steps in more detail.

The DNS database contains different types of information on resource records (RRs). The most common RRs are:

DNS SERVER SOFTWARE

DNS server software may be found by a variety of names depending on the operatng system; Windows NT simply refers to DNS while UNIX will have named or BIND (Berkeley Internet Name Daemon). When the DNS process is launched, the name of a boot file must be provided; this file contains the names of the database files containing the DNS information. A sample boot file, which might be called named.boot, is shown in Table 2.

TABLE 2. Sample named/BIND boot file.
; FILE: named.boot

directory /usr/local/named



;Type     Domain                    Data file

primary   foo.com                   foo.com.zone

primary   210.168.192.in-addr.arpa  foo.com.rev

primary   localhost                 localhost.zone

primary   0.0.127.in-addr.arpa      localhost.rev

primary   0.in-addr.arpa            all-zero.zone

primary   255.in-addr.arpa          all-one.zone

cache     .                         named.cache
 

The first record in the boot file contains directory information and points to the directory where the DNS program files reside. The remaining records each contain three fields which describe a DNS database file: the type of DNS information, the domain defined in the file, and the filename. There are six records that refer to DNS databases for which this DNS server has primary responsibility. The six domains defined here are:

The final record defines where the DNS cache information for the root domain (".") can be found. This is not a "cache," as in short-term memory, but is a set of fixed pointers to the higher-level DNS databases. In this example, the cache information is maintained in the file named.cache.

DNS RECORD FORMATS AND DATABASE FILES

All of the DNS resource records have a similar format. Although there are many shortcut notations and abbreviations that may be found in DNS files, these examples use the simplest nomenclature to eliminate confusion and/or ambiguity.

The first field in any DNS record is always either an IP address or a host name. If it is missing, then the name/address from the previous record is implied. Note that all names and addresses end with a trailing "dot" (.). This signifies that the name or address is an absolute name/address rather than a relative name/address. Absolute addresses, also called fully qualified domain names, are relative to the root, while relative addresses are relative to a default domain (which may or may not be the root). This field may, optionally, be followed by a Time-to-Live (TTL) value, which indicates the length of time that the information in this field should be considered valid.

The second field indicates the address type. In today's DNS databases, the string "IN" is most likely to be found to indicate an Internet address. This field is present for historical purposes and compatibility with older systems.

The third field is a string that indicates the type of resource record. This field is followed by optional parameters that are specific to the RR.

TABLE 3. Sample foo.com.zone file.
; Start of Authority (SOA) record

foo.com.   IN SOA  dns.foo.com.  dnsowner.foo.com.  (

                    19960105   ; serial # (date format)

                       10800   ; refresh (3 hours)

                        3600   ; retry (1 hour)

                      604800   ; expire (1 week)

                       86400)  ; TTL (1 day)



; Name Server (NS) records.

foo.com.   IN NS   dns.foo.com.

           IN NS   dns2.foo.com.



; Mail Exchange (MX) records.

foo.com.   IN MX   20  mail.foo.com.

           IN MX   40  mail2.foo.com.



; Address (A) records.

localhost.foo.com.  IN A      127.0.0.1



router.foo.com.     IN A      192.168.210.1

dns.foo.com.        IN A      192.168.210.2

mail2.foo.com.      IN A      192.168.210.3

dns2.foo.com.       IN A      192.168.210.3

mail.foo.com.       IN A      192.168.210.4

pc1.foo.com.        IN A      192.168.210.5

pc2.foo.com.        IN A      192.168.210.6



; Aliases in Canonical Name (CNAME) records...

ftp.foo.com.        IN CNAME  mail2.foo.com.

www.foo.com.        IN CNAME  mail2.foo.com.

sysman.foo.com.     IN CNAME  pc2.foo.com.
 

The foo.com.zone file (Table 3) contains information about the foo.com domain, including name lookup, mail exchange, and name server information. Specific resource records of note include:

 
TABLE 4. Sample foo.com.rev file.
; Start of Authority (SOA) record

210.168.192.in-addr.arpa. IN SOA dns.foo.com. dnsowner.foo.com.

                         (19960105   ; serial # (date format)

                             10800   ; refresh (3 hours)

                              3600   ; retry (1 hour)

                            604800   ; expire (1 week)

                             86400)  ; minimum TTL (1 day)



; Name Server (NS) records.

210.168.192.in-addr.arpa.  IN NS   dns.foo.com.

                           IN NS   dns2.foo.com.



; Addresses point to canonical names (PTR) for reverse lookups

1.210.168.192.in-addr.arpa.    IN PTR    router.foo.com.

2.210.168.192.in-addr.arpa.    IN PTR    dns.foo.com.

3.210.168.192.in-addr.arpa.    IN PTR    mail2.foo.com.

4.210.168.192.in-addr.arpa.    IN PTR    mail.foo.com.

5.210.168.192.in-addr.arpa.    IN PTR    pc1.foo.com.

6.210.168.192.in-addr.arpa.    IN PTR    pc2.foo.com.
 

Reverse lookups are handled by the database file for the IP address domain. The records and their formats are essentially the same as above, except that PTR records are used instead of A records. PTR records contain a host name to associate with the IP address that is in the first field of the record. The foo.com.rev file that corresponds to the FOO.COM network is listed in Table 4.

TABLE 5. Sample localhost.zone file.
localhost.              IN SOA  dns.foo.com.  dnsowner.foo.com. (

                        19950910   ; serial # (date format)

                           10800   ; refresh (3 hours)

                            3600   ; retry (1 hour)

                          604800   ; expire (1 week)

                           86400)  ; minimum TTL (1 day)



localhost.                IN NS   dns.foo.com.

                          IN NS   dns2.foo.com.



localhost.                IN A    127.0.0.1
 
TABLE 6. Sample localhost.rev file.
; Start of Authority (SOA) record

0.0.127.in-addr.arpa.  IN SOA dns.foo.com. dnsowner.foo.com. (

                        19951106   ; serial # (date format)

                           10800   ; refresh (3 hours)

                            3600   ; retry (1 hour)

                          604800   ; expire (1 week)

                           86400)  ; minimum TTL (1 day)



; Name Server (NS) records.

0.0.127.in-addr.arpa.     IN NS   dns.foo.com.

                          IN NS   dns2.foo.com.



; Only one PTR record

1.0.0.127.in-addr.arpa.   IN PTR   localhost.
 

Tables 5 and 6 show sample localhost.zone and localhost.rev files, respectively, providing forward and reverse address lookups for the loopback address. Tables 7 and 8 show sample files for the all zeros and all ones addresses. As mentioned above, these files are provided only for completeness and security.

TABLE 7. Sample all-zero.zone file.
0.in-addr.arpa.         IN SOA dns.foo.com. dnsowner.foo.com. (

                        19950910   ; serial # (date format)

                           10800   ; refresh (3 hours)

                            3600   ; retry (1 hour)

                          604800   ; expire (1 week)

                           86400)  ; minimum TTL (1 day)



0.in-addr.arpa.           IN NS   dns.foo.com.

                          IN NS   dns2.foo.com.
 
TABLE 8. Sample all-one.zone file.
255.in-addr.arpa.       IN SOA dns.foo.com. dnsowner.foo.com. (

                        19950910   ; serial # (date format)

                           10800   ; refresh (3 hours)

                            3600   ; retry (1 hour)

                          604800   ; expire (1 week)

                           86400)  ; minimum TTL (1 day)



255.in-addr.arpa.         IN NS   dns.foo.com.

                          IN NS   dns2.foo.com.
 

Finally, if a name cannot be resolved by the local name server, the query will be forwarded to a name server higher up on the domain name tree. The named.cache file contains the addresses of the top-level DNS servers. This actual file should be downloaded periodically from the Internet Network Information Center (InterNIC) at ftp://rs.internic.net/domain/named.cache; note that this file is also called named.root and named.ca. Table 9 shows an abbreviated version of the current named.cache file (most comments have been removed in the interest of space). The single "." indicates the root domain, while the "3600000" is the TTL value, indicating that these entries should expire after about 6 weeks (3.6 million seconds).

TABLE 9. The November, 1995 named.cache file.
;       last update:    Nov 8, 1995

;       related version of root zone:   1995110800

.                        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

; End of File
WHY MAINTAIN YOUR OWN DNS

Since most ISPs will maintain a DNS for you, why should a network manager consider operating their own? The most obvious and pressing reason is that not all ISPs will do this for you so, in some cases, you will have to do this yourself.

However, a site may want to run their own DNS anyway, primarily for better control and to ensure the database's accuracy. If your site is constantly moving systems around, changing host names, and/or changing IP addresses, your ISP may not be able to keep the DNS as up-to-date as you would like -- or need. Another issue is reverse name mapping; some ISPs keep reverse name information only for servers but not the individual host systems. In this case, users may not be able to connect to FTP or other information servers that attempt to reconcile the user's host name with the IP address. Furthermore, as your site grows in size and complexity, your ISP may be unable or unwilling to continue to meet your needs.

How To Configure
 
 

                      The file /etc/named.boot tells the named software on your system where to find its
                      configuration tables. On Maxx, I chose to place this data under /usr/local/bind to
                      distinguish it from system data that would be replaced in an OS update or re-install. The
                      named.boot file on my system looks like this:

                      1  directory       /usr/local/bind
                      2  primary         maxx.net                    maxx.net.hosts
                      3  primary         0.0.127.in-addr.arpa        named.local
                      4  primary         17.251.204.in-addr.arpa     maxx.net.revhosts
                      5  cache           .                           named.ca
 

                      The line numbers are shown for reference; don't enter them. Line 1 tells named where to
                      find the files, and also saves you having to type the fully qualified path names. You're free
                      to place your database files anywhere, but I recommend you use a file system on your
                      primary (boot) drive. If a secondary drive fails or gets unmounted, you can keep your
                      name server running.

                      Line 2 starts with the key word primary , indicating that the database file contains
                      primary server data. A primary server maintains all its databases locally. A secondary
                      server loads DNS data from another server (primary or secondary). To keep these
                      examples simple, we'll stick with definitions for a primary server.

                      The line 2 entry, maxx.net tells named which domain the file (here, maxx.net.hosts )
                      defines. You may define multiple domains with one invocation of named . Just create a
                      database file for each domain you wish to define. Here are the contents of the primary
                      host database for the domain maxx.net:

                      ;
                      ;   Addresses for the local domain

                      maxx.net.   IN      SOA     maxx.maxx.net. tyager.max
                      x.maxx.net. (
                                                  9602171         ; Serial
                                                  36000           ; Refresh every 10 hours
                                                  3600            ; Retry after 1 hour
                                                  360000          ; Expire after 100 hours
                                                  36000           ; Minimum TTL is 10 hours
                                                  )

                      ;   Define name servers
                      ;
                      maxx.net.   IN      NS      maxx.maxx.net.
                      maxx.net.   IN      A       204.251.17.241

                      ;   Define localhost
                      ;
                      localhost   IN  A           127.0.0.1

                      ;   Set up hosts
                      ;
                      maxx        IN  A           204.251.17.241
                                  IN  MX      5   maxx.maxx.net.

                      maxx.net.   IN  MX      5   maxx.maxx.net.
                      ;
                      ;   All mail for net delivered to maxx
                      ;
                      ;*          IN  MX      10  maxx.maxx.net.
                      www         IN  CNAME       maxx.maxx.net.
                      ftp         IN  CNAME       maxx.maxx.net.
                      news        IN  CNAME       maxx.maxx.net.
                      mail        IN  CNAME       maxx.maxx.net.
                      ns          IN  CNAME       maxx.maxx.net.
                      loghost     IN  CNAME
                             maxx.maxx.net.
                      lucy        IN  A           204.251.17.242
                      linux       IN  CNAME       lucy.maxx.net.
                      lucy        IN  MX      10  lucy.maxx.net.
                      messdos     IN  A           204.251.17.243
                      messdos     IN  MX      10  messdos.maxx.net.
                      pentium     IN  CNAME       messdos.maxx.net.
                      solaris     IN  A           204.251.17.244
                      solaris     IN  MX      10  solaris.maxx.net.
                      maxx4       IN  CNAME       solaris.maxx.net.
                      maxx5       IN  A           204.251.17.245
                      maxx5       IN  MX      10  maxx5.maxx.net.
                      maxx6       IN  A           204.251.17.246
                      maxx6       IN  MX      10  maxx6.maxx.net.
 

                      Most database file entries are known as DNS resource records. Generally, the resource
                      records are shown ordered: SOA, NS, followed by the other types, but this ordering isn't
                      required. The data in each entry may be entered in upper-, lower-, or mixed case. All
                      entries in the database file must start at the beginning of the line. Blank lines as well as
                      any text following a semicolon is ignored.

                      SOA stands for S tart of Authority. This self-impressed acronym clues named that
                      operational parameters follow. By far the most important is the Serial field. Every time
                      you make a change to a database file, you must increment its serial number. Only by
                      doing this will secondary servers know they need to reach into your system and pull out
                      new name server data, a procedure known as a ``zone transfer.'' Many DNS
                      administrators use a date-time stamp for this field, like 9602171 for the first version on
                      February 17, 1996.

                      First, let's focus on the SOA section:

                      maxx.net.   IN      SOA     maxx.maxx.net. tyager.maxx.maxx.net. (
 

                      The ``maxx.net.'' field tells named the domain defined by this file. The name server will
                      automatically append it to any host name that appears in the file. The trailing dot is not a
                      typo: it keeps named from trying to tack on your domain name. Without it, the resolver
                      would be confused by named 's expansion of my domain name to ``maxx.net.maxx.net.''

                      The IN stands for the ``Internet'' class of data. Even though other classes exist, they
                      aren't in common usage. The ``maxx.maxx.net'' field is the host on which these database
                      files reside. Finally, ``tyager.maxx.maxx.net'' represents the e-mail address of the DNS
                      administrator, where the first dot (between tyager and maxx) would be replaced by the
                      at-sign ( @ ) to create a valid address. (The at-sign can't be used here because it has a
                      reserved meaning in DNS database files.)

                      The open parenthesis at the end of the line lets you to split the SOA record across
                      physical lines for readability:

                                                  9602171     ; Serial

                                                  36000       ; Refresh every 10 hours
                                                  3600        ; Retry after 1 hour
                                                  360000      ; Expire after 100 hours
                                                  36000       ; Minimum TTL is 10 hours
                                                  )
 

                      We discussed the ``serial'' field above. The remaining four fields specify various time
                      intervals (all values in seconds) used by the secondary name server:

                     There are several types of resource records, identified by the key word in field three of
                      each record. You may present records in any order, but try to organize them for clarity
                      (whatever that suggests to you). The NS (name server) record tells the hosts that query
                      your server where the name servers for this domain can be found:

                      maxx.net.   IN      NS      maxx.maxx.net.
 

                      The address of the host maxx.maxx.net isn't defined until later, but it doesn't matter. It
                      gets used in the SOA record as well, so I relax my backward-reference ban in this case.
                      You may list multiple name servers for your domain. In fact, your domain should have at
                      least two name servers. As I said, your Internet service provider will probably allow you
                      to use their name server as a secondary for your domain. Don't forget the trailing dots!

                      The first A record, which resolves a fully-qualified host name to an IP address, is a
                      special one. It defines an IP address for unqualified queries, that is, queries for the host
                      maxx.net. It's easy for my small network, which only has one host that offers any
                      services to the outside world. Users can access it with a few saved keystrokes, and my
                      users have the luxury of simplified e-mail addresses (for instance, tyager@maxx.net ).

                      Other A records like this one:

                      lucy        IN  A       204.251.17.242
 

                      provide name-to-address mapping for a specific named host. The domain defined in this
                      file (maxx.net) is appended to the host name you show in the first field.

                      The CNAME records create aliases for existing hosts. These examples illustrate a few
                      common uses:

                      www         IN  CNAME   maxx.maxx.net.
                      ftp         IN  CNAME   maxx.maxx.net.
 

                      You may give a host any alias you like, and as many aliases as you like. The host needn't
                      answer to that name, that is, the alias doesn't need to be t he host's true name as reported
                      by hostname or uname .

                      The other vital type of record is MX . This tells SMTP e-mail software where to send mail
                      for each named host:

                      lucy        IN  MX      10 lucy.maxx.net.
 

                      When a remote host's mail delivery program sees an e-mail address in your domain, it will
                      query your name server for its applicable MX record or records. This is wonderfully
                      versatile. Every user on your LAN can receive e-mail, even if not every host is running its
                      own e-mail software. The MX record for lucy, for instance, could easily redirect e-mail to
                      another host on the LAN.

                      The number (10 in this case) in the fourth field represents a preference value. If you
                      define multiple MX records for a host, delivery is attempted to lower-preference value
                      hosts first. The actual value isn't important, only its relationship to other preference values.

                      On larger LANs it's a good idea to create backup e-mail server s. Smaller LANs, like
                      mine, can simply rely on the fact that most SMTP mailers will retry deliveries to my site
                      for three days before returning a message to its sender.

                      The line--shown commented out here--would arrange to redirect e-mail for all hosts in this
                      domain to a single machine:

                      ;
                      ; All mail for net delivered to maxx
                      ;
                      ;*          IN  MX      10 maxx.maxx.net.
 

                      This is an exceedingly good idea for company LANs that benefit from a central e-mail
                      repository.

                      Address-to-name mapping

                      Reverse-mapping files let resolvers post queries armed with only the IP address. This
                      reverse mapping is used, for example, by Internet server software that prefers to log host
                      names rather than less informative IP addresses.

                      Your host will require at least two reverse-mapping files. The first, defined on line two of
                      the sample named.boot file, sets up the reverse mapping of the localhost entry:

                      ;
                      ; Addresses in the local domain
                      ;
                      @
                                 IN  SOA     maxx.maxx.net tyager.maxx.maxx.net. (
                                              9602171 ; Serial
                                              36000   ; Refresh every 100 hours
                                              3600    ; Retry after 1 hour
                                              3600000 ; Expire after 1000 hours
                                              36000   ; Minimum TTL is 100 hours
                                              )

                      maxx.net.   IN  NS      maxx.maxx.net.
                      1           IN  PTR     localhost.
 

                      There's only one host in this database. The at-sign in the first column of the SOA record
                      is shorthand for ``insert my domain here.'' The domain, as defined by this database file's
                      entry in the named.boot file, is 0.0.127.in- addr.arpa. As discussed in my previous
                      column , this domain is recognized as special. Among its special qualities is that the
                      network address identified in the domain (127.0.0 in this case) is reversed before it is is
                      processed. Therefore, the PTR entry in the above example uses one ( 1 ) as the suffix to
                      the IP address given in named.boot , creating the IP address 127.0.0.1.

                      The reverse-mapping database for the rest of the domain, set up in line four of the sample
                      named.boot , looks like this:

                      ;
                      ;   Reverse addressing for the local domain
                      ;
                      @           IN      SOA     maxx.maxx.net. tyager.maxx.maxx.net. (
                                                  9602171     ; Serial
                                                  36000       ; Refresh every 10 hours
                                                  3600        ; Retry after 1 hour
                                                  360000      ; Expire after 100 hours
                                                  36000       ; Minimum TTL is 10 hours
                                                  )
                      ;
                      ;   Define name server
                      ;
                                  IN      NS      maxx.maxx.net.

                      ;
                      ;   Addresses point to canonical names:
                      ;

                      241         IN      PTR     maxx.maxx.net.
                      242         IN      PTR     lucy.maxx.net.
                      243         IN      PTR     messdos.maxx.net.
                      244         IN      PTR     solaris.maxx.net.
                      245         I
                      N      PTR     maxx5.maxx.net.
                      246         IN      PTR     maxx6.maxx.net.
 

                      If you leave field one blank (as in the NS record for this example) named will use
                      previous record's field-one entry. In this case, the at-sign gets replaced by the domain
                      name from line four of named.boot .

                      DNS FAQ

                    1.0 What is the size of the Serial number?
                          32 unsigned integer.
                    2.0 What would happen if the Serial number is zero.
                          The Secondary servers would be forced to refresh themselves.
                    3.0 Can we have MX record pointing to IP address.
                          No, MX record should always point to the FQDN.
                    4.0 How to configure Multiple Domains per single IP address.
                          Go to http://members.tripod.com/~aviion/DNS1.html
                    5.0