dns-setup.doc

早期freebsd实现

   The first RR defines the Start-Of-Authority for the root domain (.).
   The SOA RR has the following general syntax:

   domain IN SOA sdom mbox (Serial Refresh 
                            Retry Expire Minimum)

   with
   domain   is the name of the domain the SOA record is for
   IN SOA   defines the record as a SOA record of class IN
   sdom     full domainname of the host that holds the zone data
   mbox     mailbox of the person responsible for the nameserver
            (The @ in the common syntax user@domain is replaced
            by a period here since @ has a special meaning to the 
            RRs.) The "mbox" field is not use by the nameserver itself.
            It is reserved for humans to use.
   Serial   Serial number of the datafile. This field should be updated
            whenever the datafile is changed. "Serial" is used to tell
            the secondary nameservers that zone data has changed and 
            should be transfered off the primary inspite of the 
            "Refresh" time not having expired.
   Refresh  Tells the secondaries how often (in seconds) to check for
            the accuracy of their zone data if not notified of changes 
            before.
   Retry    Tells the secondaries what time to wait for getting the 
            zone data off the primary after "Refresh" has expired and 
            they couldn't contact the primary than.
   Expire   Tells the secondaries time after which they should consider
            their zone data invalid when "Refresh" has expired and
            they were unable to contact the primary. After "Expire"
            has expired the secondaries will stop to answers queries
            concerning the zone. 
   Minimum  Time-to-live value for all RRs in the datafile that have
            a blank "ttl" field. This TTL is supplied with answers to 
            queries to tell other nameservers how long the data can be
            considered valid (if they want to cache it)

   All time values are given in seconds. 

   Now let's have a look at our SOA record for the root domain.
   The sole period in the "domain" field tells that this is the SOA for the 
   root domain. "host.dep.secdom.topdom." in the "sdom" field says that
   this host holds the domain data. All the zone data we need for root
   is included in this file (root.cache) for our purpose. The next
   field indicates that mail concerning the nameserver should be send to
   [e-mail]. The "Serial" consists of the date
   (YYMMDD) of the last change and a three digit sequence number.
   The "Refresh" period is about 8 hours, the "Retry" is 2 hours and
   the secondaries should expire their data after about 16790 hours.
   The default TTL for all the RRs in this file is about 2 days.

   
   The next record is a *nameserver* record. This record (NS) defines a
   nameserver for a given domain. The record has the following syntax:

   domain  ttl IN NS domainname-of-the-nameserver-host

   with
   domain   name of the domain the nameserver is for
   ttl      optional ttl field. If blank the "Minimum" in the SOA record
            is used.
   IN NS    defines the record to be a "nameserver" record of class IN
   domainname-of-the-nameserver-host 
            the full domainname (starting with the hostname and ending
            with a period) of the host that is running the nameserver.


   In our example there are three NS records.
   The first defines host.dep.secdom.topdom. to be the primary nameserver
   for the root domain. The second makes the same host a primary for
   the local domain (secdom.topdom) and third record makes it a primary
   for the corresponding IN-ADDR.ARPA.-domain. These two records are used
   for delegation of the two domains. Normally those records would have to 
   be in the zone data of the "topdom"- and the "IN-ADDR.ARPA"- servers.
   Since there are no such servers in our net we delegate directly
   in root.cache.

   For named to find the nameserver host it has to have an "address"
   record which has the general syntax:
   
   domainname. ttl IN A ip-address-of-domainname

   with
   domainname.  is the full domainname of the object the record is for.
                I use the term "object" instead of "host" here since
                "domainname." need not be a host. It is recommended to use
                full domainnames whenever possible since certain 
                applications (i.e. sendmail) could otherwise run into problems.
   ttl      optional ttl field. If blank the "Minimum" in the SOA record
            is used.
   IN A     says that this is an address record for the class IN
   ip-address-of-domainname
            gives the ip address to be associated with the given 
            domainname in dotted notation (a.b.c.d)

   In our example file host.dep.secdom.topdom. is associated with the
   ip address a.b.c.d.

   For sendmail we need MX records telling it where to deliver mail that
   is addressed to users in the root domain and in die topdom-domain (= our
   toplevel domain). The MX record has the general appearence:
   
   domain. ttl IN MX preference mailhost

   with
   domain.  is the domainname of the object the MX record is for.
   ttl      optional ttl field. If blank the "Minimum" in the SOA record
            is used.
   IN MX    define the record as "mailexchanger" record of class IN.
   preference  tells at which preference the record should be used. There
               can be more than one MX RR of "domain.". Then "preference"
               tells which record to prefere. "preference" is an integer 
               between 0 and 65535. The record with the *lowest* preference
               value (numerical) is considered the *best*.
   mailhost    full domainname of the host the mail for "domain." should
               be send to.


   In our example mail addressed to the root- and the topdom-domain is sent
   to host.dep.secdom.topdom. Since there is only one MX RR for each
   domain the preference value doesn't matter here.

   Now we have setup our internal root nameserver. We are now ready to 
   setup the nameserver for our domain. Before doing this we shall 
   have a look at "The internet name space" and "What a nameserver does".


The internet name space
=======================

Unlike the ip address space which is flat the "internet name space" has a
hierarchical organization. It looks like a tree helt upside down. 
It starts with a root indicated by a period (.). Then there are 
several levels of domains in this tree. The level immediately following
the root is named
    toplevel domains
and used to group universities, companies, ... into larger organizations
or countries. The toplevel domains are either named according to the 
business of the institutions that  belong to them or according to the 
ISO country codes. So names are COM, EDU, NET, MIL, DE, UK, US, etc.

The toplevel domains include so called second-level domains which 
represent institutions like universities and companies (i.e. "fh-nuernberg").
In the second-level domains there can be one or more levels of subdomains.
It is not recommended to created too much levels of subdomains since
the internet domain names are used for email addressing and it is 
somewhat trying to have all those subdomains in the email address.

An internet domain name consists of several "labels" that are 
separated by periods (.). The "labels" are the names of the domains
in the tree: 

   host.subdX.,,,.subd2.subd1.second-level-domain.toplevel-domain  

where subdN is part of subd(N-1) for N between 1 and X.

! The labels are given (from left to right) in the order local -->
! remote with the *farest* (root) at the end (right) of the name.
! In the zone data files of the nameserver where we have a mechanism
! to state a default domain (given in /etc/named.boot or with the 
! $ORIGIN directive in the zone data files) we can use a period (.)
! at the *end* of a domain name to mark it fully qualified. When we
! put the period at the end of a domain name in a zone file we tell
! the nameserver *not* to append the default domain to this name.

! The first label of a domain name may be a hostname (host) or 
! a subdomain name (subdX). I don't want to tell here that a 
! domain name *must* begin with a hostname but it *can* begin with 
! a hostname.

What a nameserver does
======================

An internet name server maps 
   names to addresses
The internet (ip) addresses are given in numbers of the form a.b.c.d
which for a human are difficult to remember. So the internet namespace
was created to provide *names* that can be used instead of numbers.
These names have to be mapped to the numbers which the computers can use 
better. 

For a unix system there are two means to do this mapping:
* /etc/hosts
* DNS (domain name service), i.e. named

For an institution with many hosts (each must have an ip address for 
communication with the other hosts) the /etc/hosts file will grow
very large and due to frequent changes will get quite unmaintainable.
So they have to use a *nameserver* to manage the mapping for their 
institution. 

Well, the mapping of names to addresses is only one half. What about
mapping addresses to names? To do this a special domain was created
     IN-ADDR.ARPA.

It would be quite unmanageable to maintain all those mappings around 
the world in only one nameserver. Therefore the namespace is split 
into parts that are called *zones*. For each zone there is an
institution that is given the authority to maintain the data for this
zone. This is called *delegation*. The institution which is
authoritative for a zone runs the primary master nameserver for this
zone. I.e. The zone data for fh-nuernberg (zone!) is maintain in 
the computer center of this institution.

  Setting up a primary nameserver for a local domain
  ==================================================

In "Setting up a primary master nameserver for a non-internet host"
we made a file /etc/named.boot which told named to be a primary for
* the root domain (--> 3.)
* the local domain (--> 4.)
* the reverse-mapping-domains for the local domain and "localhost" (--> 5.)

In 3. we made a datafile for the root domain. Now we have to build the
datafile for our local domain. We will name this file 
       named.hosts
in /confdir. That file (as all the others mentioned here too)
is owned be the root account.

4. named.hosts has the following RR types in it:
   SOA, A, MX, HINFO and CNAME.
   Only for the last two types I didn't give a description yet.
   
   domain.  IN HINFO CPU OS
  
   with
   domain. is the domainname the record is for.
   IN HINFO  This is a "host info" record of class IN.
   CPU       gives the type of host, i.e. PC-486.
   OS        gives the operating system the host is running, i.e. MS-DOS.


   domain. IN CNAME aliased-name.

   with
   domain. is the domainname the record is for.
   IN CNAME  This is an "alias" record of class IN.
   aliased-name. gives the name that should be used instead of "domain."
                 when searching for records associated with the object.

   Note: There *must not* be other records containing "domain." in their
         domain field if there is a CNAME record for it.

   We can use CNAME RRs for hosts that should have more than one hostname.
   Again it is recommended to use full domainnames.

   Caution!!!!  We *must not* use CNAME records to define an alias
                for a whole domain or subdomain!!! CNAME records *may only*
                be used to define aliases for hosts (leaf objects in the 
                namespace tree). 

   Now what RRs does or datafile contain? First it *must* contain one
   (and only one) SOA record for our domain. This record looks similar
   to that described in 3. for the root domain. The domain field now
   contains a @ or the full name of our domain (secdom.topdom).
   Note: @ in the domain field tells named to use the "current origin"
         here. Be sure that it is setup correct otherwise better take the