faq

早期freebsd实现

Path: vixie!decwrl!sdd.hp.com!network.ucsd.edu!munnari.oz.au!uniwa!craig
From: [e-mail] (Craig Richmond - division)
Newsgroups: comp.protocols.tcp-ip.domains
Subject: FAQ: Setting up a basic DNS server for a domain
Date: 3 Aug 1993 10:53:51 GMT
Organization: The University of Western Australia
Lines: 1088
Distribution: inet
Message-ID: <23lg3v$[e-mail]>
NNTP-Posting-Host: decel.ecel.uwa.edu.au
Summary: Step by Step implementation of a DNS server
Keywords: FAQ DNS setup


                Setting up a basic DNS server for a domain
                            Revision 1.1.1

                            Craig Richmond
                         [e-mail]
                            3rd August 1993


About this document

I have written this file because it seems that the same questions seem to
pop up time and time again and when I had to install DNS from scratch the
first time, we found very little to help us.

This document covers setting up a Domain Name Server with authority over
your domain and using a few of the more useful but less well known
(hopefully this document will take care of that) features of nslookup to
get information about the DNS and to work out why yours isn't working.

If you are using a Sun Workstation and you want to make NIS interact with
the DNS, then this is not the FAQ for you (but it may well be when you try
to set up the DNS).  Mark J. McIntosh <[e-mail]> points
out that it is included in the comp.sys.sun.admin FAQ and for the benefit
of those of you who can't get that (it is posted in comp.sys.sun.admin,
comp.sys.sun.misc, comp.unix.solaris, comp.answers and news.answers) I have
included the relevant parts at the bottom in appendix C.

Contents:

   Contents
   An Overview of the DNS
   Installing the DNS
    *The Boot File
    *The Cache File
    *The Forward Mapping File
    *The Reverse Mapping File
   Delegating authority for domains within your domain
   Troubleshooting your named
    *Named doesn't work!  What is wrong?
    *I changed my named database and my local machine has noticed,
     but nobody else has the new information?
    *My local machine knows about all the name server information,
     but no other sites know about me?
    *My forward domain names work, but the backward names do not?
   How to get useful information from nslookup
    *Getting number to name mappings.
    *Finding where mail goes when a machine has no IP number.
    *Getting a list of machines in a domain from nslookup.
   Appendicies
    *Appendix A  sample root.cache file
    *Appendix B  Excerpt from RFC 1340 - Assigned Numbers - July 1992
    *Appendix C  Installing DNS on a Sun when running NIS


An Overview of the DNS:

The Domain Name System is the software that lets you have name to number
mappings on your computers.  The name decel.ecel.uwa.edu.au is the number
130.95.4.2 and vice versa.  This is achieved through the DNS.  The DNS is a
heirarchy.  There are a small number of root domain name servers that are
responsible for tracking the top level domains and who is under them.  The
root domain servers between them know about all the people who have name
servers that are authoritive for domains under the root.

Being authoritive means that if a server is asked about something in that
domain, it can say with no ambiguity whether or not a given piece of
information is true.  For example.  We have domains x.z and y.z.  There are
by definition authoritive name servers for both of these domains and we
shall assume that the name server in both of these cases is a machine
called nic.x.z and nic.y.z but that really makes no difference.

If someone asks nic.x.z whether there is a machine called a.x.z, then
nic.x.z can authoritively say, yes or no because it is the authoritive name
server for that domain.  If someone asks nic.x.z whether there is a machine
called a.y.z then nic.x.z asks nic.y.z whether such a machine exists (and
caches this for future requests).  It asks nic.y.z because nic.y.z is the
authoritive name server for the domain y.z.  The information about
authoritive name servers is stored in the DNS itself and as long as you
have a pointer to a name server who is more knowledgable than yourself then
you are set.

When a change is made, it propogates slowly out through the internet to
eventually reach all machines.  The following was supplied by Mark Andrews
[e-mail].

        If both the primary and all secondaries are up and talking when
        a zone update occurs and for the refresh period after the
        update the old data will live for max(refresh + mininum)
        average (refresh/2 +mininum) for the zone. New information will
        be available from all servers after refresh.

So with a refresh of 3 hours and a minimum of a day, you can expect
everything to be working a day after it is changed.  If you have a longer
minimum, it may take a couple of days before things return to normal.

There is also a difference between a zone and a domain.  The domain is the
entire set of machines that are contained within an organisational domain
name.  For example, the domain uwa.edu.au contains all the machines at the
University of Western Australia.  A Zone is the area of the DNS for which a
server is responsible.  The University of Western Australia is a large
organisation and trying to track all changes to machines at a central
location would be difficult.  The authoritive name server for the zone
uwa.edu.au delegates the authority for the zone ecel.uwa.edu.au to
decel.ecel.uwa.edu.au.  Machine foo.ecel.uwa.edu.au is in the zone that
decel is authoritive for.  Machine bar.uwa.edu.au is in the zone that
uniwa.uwa.edu.au is authoritive for.

Installing the DNS:

First I'll assume you already have a copy of the Domain Name Server
software.  It is probably called named or in.named depending on your
flavour of unix.  I never had to get a copy, but if anyone thinks that
information should be here then by all means tell me and I'll put it in.
If you intend on using the package called Bind, then you should be sure
that you get version 4.9, which is the most recent version at this point in
time.

The Boot File:

First step is to create the file named.boot.  This describes to named
(we'll dispense with the in.named.  Take them to be the same) where the
information that it requires can be found.  This file is normally found in
/etc/named.boot and I personally tend to leave it there because then I know
where to find it.  If you don't want to leave it there but place it in a
directory with the rest of your named files, then there is usually an
option on named to specify the location of the boot file.

Your typical boot file will look like this if you are an unimportant leaf
node and there are other name servers at your site.

directory	/etc/namedfiles

cache		.	       				root.cache
primary		ecel.uwa.edu.au				ecel.uwa.domain
primary		0.0.127.in-addr.arpa			0.0.127.domain
primary		4.95.130.in-addr.arpa			4.95.130.domain
forwarders      130.95.128.1

Here is an alternative layout used by Christophe Wolfhugel
<[e-mail]>  He finds this easier because of
the large number of domains he has.  The structure is essentially the same,
but the file names use the domain name rather than the IP subnet to
describe the contents.

directory       /usr/local/etc/bind
cache     .                      p/root
forwarders      134.214.100.1 192.93.2.4
;
; Primary servers
;
primary   fr.net                        p/fr.net
primary   frmug.fr.net                  p/frmug.fr.net
primary   127.in-addr.arpa              p/127
;
; Secondary servers
;
secondary ensta.fr                 147.250.1.1     s/ensta.fr
secondary gatelink.fr.net          134.214.100.1   s/gatelink.fr.net
secondary insa-lyon.fr             134.214.100.1   s/insa-lyon.fr
secondary loesje.org               145.18.226.21   s/loesje.org
secondary nl.loesje.org            145.18.226.21   s/nl.loesje.org
secondary pcl.ac.uk                161.74.160.5    s/pcl.ac.uk
secondary univ-lyon1.fr            134.214.100.1   s/univ-lyon1.fr
secondary wmin.ac.uk               161.74.160.5    s/wmin.ac.uk
secondary westminster.ac.uk        161.74.160.5    s/westminster.ac.uk
;
;
; Secondary for addresses
;
secondary 74.161.in-addr.arpa      161.74.160.5    s/161.74
secondary 214.134.in-addr.arpa     134.214.100.1   s/134.214
secondary 250.147.in-addr.arpa     147.250.1.1     s/147.250
;
; Classes C
;
secondary 56.44.192.in-addr.arpa   147.250.1.1     s/192.44.56
secondary 57.44.192.in-addr.arpa   147.250.1.1     s/192.44.57

The lines in the named.boot file have the following meanings.

directory

This is the path that named will place in front of all file names
referenced from here on.  If no directory is specified, it looks for files
relative to /etc.

cache

This is the information that named uses to get started.  Named must know
the IP number of some other name servers at least to get started.
Information in the cache is treated differently depending on your version
of named.  Some versions of named use the information included in the cache
permenantly and others retain but ignore the cache information once up and
running.

primary

This is one of the domains for which this machine is authorative for.  You
put the entire domain name in.  You need forwards and reverse lookups.  The
first value is the domain to append to every name included in that file.
(There are some exceptions, but they will be explained later)  The name at
the end of the line is the name of the file (relative to /etc of the
directory if you specified one).  The filename can have slashes in it to
refer to subdirectories so if you have a lot of domains you may want to
split it up.

BE VERY CAREFUL TO PUT THE NUMBERS BACK TO FRONT FOR THE REVERSE LOOK UP
FILE.  The example given above is for the subnet ecel.uwa.edu.au whose IP
address is 130.95.4.*.  The reverse name must be 4.95.130.in-addr.arpa.
It must be backwards and it must end with .in-addr.arpa.  If your reverse
name lookups don't work, check this.  If they still don't work, check this
again.

forwarders

This is a list of IP numbers for forward requests for sites about which we
are unsure.  A good choice here is the name server which is authoritive for
the zone above you.

secondary (This line is not in the example, but is worth mentioning.)

A secondary line indicates that you wish to be a secondary name server for
this domain.  You do not need to do this usually.  All it does is help make
the DNS more robust.  You should have at least one secondary server for
your site, but you do not need to be a secondary server for anyone else.
You can by all means, but you don't need to be.  If you want to be a
secondary server for another domain, then place the line

secondary         gu.uwa.edu.au   130.95.100.3 130.95.128.1

in your named.boot.  This will make your named try the servers on both of
the machines specified to see if it can obtain the information about those
domains.  You can specify a number of IP addresses for the machines to
query that probably depends on your machine.  Your copy of named will upon
startup go and query all the information it can get about the domain in
question and remember it and act as though it were authoritive for that
domain.

Next you will want to start creating the data files that contain the name
definitions.

The cache file:

You can get a copy of the cache file from FTP.RS.INTERNIC.NET.  The current
copy can be found in Appendix A.

The Forward Mapping file:
The file ecel.uwa.edu.au. will be used for the example with a couple of
machines left in for the purpose of the exercise.  Here is a copy of what
the file looks like with explanations following.

; Authoritative data for ecel.uwa.edu.au
;
@		IN	SOA decel.ecel.uwa.edu.au. postmaster.ecel.uwa.edu.au. (
				93071200	; Serial (yymmddxx)
				10800		; Refresh 3 hours
				3600		; Retry   1 hour
				3600000 	; Expire  1000 hours
				86400 )		; Minimum 24 hours
		IN	A		130.95.4.2
		IN	MX	100  	decel
		IN	MX	150	uniwa.uwa.edu.au.
		IN	MX	200	relay1.uu.net.
		IN	MX	200	relay2.uu.net.

localhost	IN	A		127.0.0.1

decel		IN	A		130.95.4.2
		IN	HINFO	SUN4/110	 UNIX
		IN	MX	100	decel
		IN	MX	150	uniwa.uwa.edu.au.
		IN	MX	200	relay1.uu.net
		IN	MX	200	relay2.uu.net

gopher		IN	CNAME		decel.ecel.uwa.edu.au.

accfin		IN	A		130.95.4.3
		IN	HINFO	SUN4/110	 UNIX
		IN	MX	100	decel
		IN	MX	150	uniwa.uwa.edu.au.
		IN	MX	200	relay1.uu.net
		IN	MX	200	relay2.uu.net

chris-mac	IN	A		130.95.4.5
		IN	HINFO	MAC-II	MACOS

The comment character is ';' so the first two lines are just comments
indicating the contents of the file.

All values from here on have IN in them.  This indicates that the value is
an InterNet record.  There are a couple of other types, but all you need
concern yourself with is internet ones.

The SOA record is the Start Of Authority record.  It contains the
information that other nameservers will learn about this domain and how to
treat the information they are given about it.  The '@' as the first
character in the line indicates that you wish to define things about the
domain for which this file is responsible.  The domain name is found in the
named.boot file in the corresponding line to this filename.  All
information listed refers to the most recent machine/domain name so all
records from the '@' until 'localhost' refer to the '@'.  The SOA record
has 5 magic numbers.  First magic number is the serial number.  If you
change the file, change the serial number.  If you don't, no other name
servers will update their information.  The old information will sit around
for a very long time.

Refresh is the time between refreshing information about the SOA (correct
me if I am wrong).  Retry is the frequency of retrying if an authorative
server cannot be contacted.  Expire is how long a secondary name server
will keep information about a zone without successfully updating it or
confirming that the data is up to date.  This is to help the information
withstand fairly lengthy downtimes of machines or connections in the
network without having to recollect all the information.  Minimum is the
default time to live value handed out by a nameserver for all records in
a zone without an explicit TTL value. This is how long the data will live
after being handed out.  The two pieces of information before the 5 magic
numbers are the machine that is considered the origin of all of this
information.  Generally the machine that is running your named is a good
one for here.  The second is an email address for someone who can fix any
problems that may occur with the DNS.  Good ones here are postmaster,
hostmaster or root.  NOTE: You use dots and not '@' for the email address.

eg  root.decel.ecel.uwa.edu.au is correct
     and
    [e-mail] is incorrect.

We now have an address to map ecel.uwa.edu.au to.  The address is
130.95.4.2 which happens to be decel, our main machine.  If you try to find
an IP number for the domain ecel.uwa.edu.au it will get you the machine
decel.ecel.uwa.edu.au's IP number.  This is a nicety which means that
people who have non-MX record mailers can still mail [e-mail]
and don't have to find the name of a machine name under the domain to mail.

Now we have a couple of MX records for the domain itself.  The MX records
specify where to send mail destined for the machine/domain that the MX
record is for.  In this case we would prefer if all mail for
[e-mail] is sent to decel.ecel.uwa.edu.au.  If that does not
work, we would like it to go to uniwa.uwa.edu.au because there are a number
of machines that might have no idea how to get to us, but may be able to get
to uniwa.  And failing that, try the site relay1.uu.net.  A small number
indicates that this site should be tried first.  The larget the number the
further down the list of sites to try the site is.  NOTE: Not all machines
have mailers that pay attention to MX records.  Some only pay attention to
IP numbers, which is really stupid.  All machines are required to have
MX-capable Mail Transfer Agents (MTA) as there are many addresses that can
only be reached via this means.

There is an entry for localhost now.  Note that this is somewhat of a
kludge and should probably be handled far more elegantly.  By placing
localhost here, a machine comes into existance called
localhost.ecel.uwa.edu.au.  If you finger it, or telnet to it, you get your
own machine, because the name lookup returns 127.0.0.1 which is the special
case for your own machine.  I have used a couple of different DNS packages.
The old BSD one let you put things into the cache which would always work,