faq

早期freebsd实现

but would not be exported to other nameservers.  In the newer Sun one, they
are left in the cache and are mostly ignored once named is up and running.
This isn't a bad solution, its just not a good one.

Decel is the main machine in our domain.  It has the IP number 130.95.4.2
and that is what this next line shows.  It also has a HINFO entry.  HINFO
is Host Info which is meant to be some sort of an indication of what the
machine is and what it runs.  The values are two white space seperated
values.  First being the hardware and second being the software.  HINFO is
not compulsory, its just nice to have sometimes.  We also have some MX
records so that mail destined for decel has some other avenues before it
bounces back to the sender if undeliverable.

It is a good idea to give all machines capable of handling mail an MX
record because this can be cached on remote machines and will help to
reduce the load on the network.

gopher.ecel.uwa.edu.au is the gopher server in our division.  Now because
we are cheapskates and don't want to go and splurge on a seperate machine
just for handling gopher requests we have made it a CNAME to our main
machine.  While it may seem pointless it does have one main advantage.
When we discover that our placing terrabytes of popular quicktime movies
on our gopher server (no we haven't and we don't intend to) causes an
unbearable load on our main machine, we can quickly move the CNAME to
point at a new machine by changing the name mentioned in the CNAME.  Then
the slime of the world can continue to get their essential movies with a
minimal interuption to the network.  Other good CNAMEs to maintain are
things like ftp, mailhost, netfind, archie, whois, and even dns (though the
most obvious use for this fails).  It also makes it easier for people to
find these services in your domain.

We should probably start using WKS records for things like gopher and whois
rather than making DNS names for them.  The tools are not in wide
circulation for this to work though.  (Plus all those comments in many DNS
implementation of "Not implemented" next to the WKS record)

Finally we have a macintosh which belongs to my boss.  All it needs is an
IP number, and we have included the HINFO so that you can see that it is in
fact a macII running a Mac System.  To get the list of preferred values,
you should get a copy of RFC 1340.  It lists lots of useful information
such as /etc/services values, ethernet manufacturer hardware addresses,
HINFO defualts and many others.  I will include the list as it stands at
the moment, but if any RFC superceeds 1340, then it will have a more
complete list.  See Appendix B for that list.

NOTE:  If Chris had a very high profile and wanted his mac to appear like a
fully connected unix machine as far as internet services were concerned, he
could simply place an MX record such as 

	IN	MX	100  decel

after his machine and any mail sent to [e-mail]
would be automatically rerouted to decel.

The Reverse Mapping File

The reverse name lookup is handled in a most bizarre fashion.  Well it all
makes sense, but it is not immediately obvious.

All of the reverse name lookups are done by finding the PTR record
associated with the name w.x.y.z.in-addr.arpa.  So to find the name
associated with the IP number 1.2.3.4, we look for information stored in
the DNS under the name 4.3.2.1.in-addr.arpa.  They are organised this way
so that when you are allocated a B class subnet for example, you get all of
the IP numbers in the domain 130.95.  Now to turn that into a reverse name
lookup domain, you have to invert the numbers or your registered domains
will be spread all over the place.  It is a mess and you need not understand
the finer points of it all.  All you need to know is that you put the
reverse name lookup files back to front.

Here is the sample reverse name lookup files to go with our example.

0.0.127.in-addr.arpa
--
;  Reverse mapping of domain names 0.0.127.in-addr.arpa
;  Nobody pays attention to this, it is only so 127.0.0.1 -> localhost.
@		IN	SOA decel.ecel.uwa.edu.au. postmaster.ecel.uwa.edu.au. (
				91061801	; Serial (yymmddxx)
				10800		; Refresh 3 hours
				3600		; Retry   1 hour
				3600000 	; Expire  1000 hours
				86400 )		; Minimum 24 hours
;
1		IN	PTR	    localhost.ecel.uwa.edu.au.
--

4.95.130.in-addr.arpa
--
;	reverse mapping of domain names 4.95.130.in-addr.arpa
;
@		IN	SOA decel.ecel.uwa.edu.au. postmaster.ecel.uwa.edu.au. (
				92050300	; Serial (yymmddxx format)
				10800		; Refresh	3hHours
				3600		; Retry		1 hour
				3600000		; Expire	1000 hours
				86400 )		; Minimum	24 hours
2		IN	PTR	decel.ecel.uwa.edu.au.
3		IN	PTR	accfin.ecel.uwa.edu.au.
5		IN	PTR	chris-mac.ecel.uwa.edu.au.
--

It is important to remember that you must have a second start of authority
record for the reverse name lookups.  Each reverse name lookup file must
have its own SOA record.  The reverse name lookup on the 127 domain is
debatable seeing as there is likely to be only one number in the file and
it is blatantly obvious what it is going to map to.

The SOA details are the same as in the forward mapping.

Each of the numbers listed down the left hand side indicates that the line
contains information for that number of the subnet.  Each of the subnets
must be the more significant digits.  eg the 130.95.4 of an IP number
130.95.4.2 is implicit for all numbers mentioned in the file.

The PTR must point to a machine that can be found in the DNS.  If the name
is not in the DNS, some versions of named just bomb out at this point.

Reverse name lookups are not compulsory, but nice to have.  It means that
when people log into machines, they get names indicating where they are
logged in from.  It makes it easier for you to spot things that are wrong
and it is far less cryptic than having lots of numbers everywhere.  Also if
you do not have a name for your machine, some brain dead protocols such as
talk will not allow you to connect.

Since I had this I had one suggestion of an alternative way to do the
localhost entry.  I think it is a matter of personal opinion so I'll
include it here in case anyone things that this is a more appropriate
method.

The following is courtesy of [e-mail] (JEP de Bie)

  The way I did it was:

  1) add in /etc/named.boot:

     primary   .                             localhost
     primary   127.in-addr.ARPA.             IP127

(Craig: It has been suggested by Mark Andrews that this is a bad practice
 particularly if you have upgraded to Bind 4.9.  You also run the risk of
 polluting the root name servers.  This comes down to a battle of idealogy
 and practicality.  Think twice before declaring yourself authorative for
 the root domain.)

  So I not only declare myself (falsely? - probably, but nobody is going to
  listen anyway most likely [CPR]:-) athorative in the 127.in-addr.ARPA domain
  but also in the . (root) domain.

  2) the file localhost has:

     $ORIGIN .
     localhost       IN      A       127.0.0.1

  3) and the file IP127:

     $ORIGIN 127.in-addr.ARPA.
     1.0.0   IN      PTR     localhost.

  4) and I have in my own domain file (convex.nl) the line:

     $ORIGIN convex.nl.
     localhost       IN      CNAME   localhost.

  The advantage (elegancy?) is that a query (A) of localhost. gives the
  reverse of the query of 1.0.0.127.in-addr.ARPA. And it also shows that
  localhost.convex.nl is only a nickname to something more absolute.
  (While the notion of localhost is of course relative :-)).

  And I also think there is a subtle difference between the lines

    primary   127.in-addr.ARPA.             IP127
      and
    primary   0.0.127.in-addr.ARPA.         4.95.130.domain
                                        =============
                                         JEP de Bie
                                        [e-mail]
                                        =============



Delegating authority for domains within your domain:

When you start having a very big domain that can be broken into logical and
seperate entities that can look after their own DNS information, you will
probably want to do this.  Maintain a central area for the things that
everyone needs to see and delegate the authority for the other parts of the
organisation so that they can manage themselves.

Another essential piece of information is that every domain that exists
must have it NS records associated with it.  These NS records denote the
name servers that are queried for information about that zone.  For your
zone to be recognised by the outside world, the server responsible for the
zone above you must have created a NS record for your machine in your
domain.  For example, putting the computer club onto the network and giving
them control over their own part of the domain space we have the following.

The machine authorative for gu.uwa.edu.au is mackerel and the machine
authorative for ucc.gu.uwa.edu.au is marlin.

in mackerel's data for gu.uwa.edu.au we have the following

@		IN	SOA ...
		IN	A	130.95.100.3
		IN	MX	mackerel.gu.uwa.edu.au.
		IN	MX	uniwa.uwa.edu.au.

marlin		IN	A	130.95.100.4

ucc		IN	NS	marlin.gu.uwa.edu.au.
		IN	NS	mackerel.gu.uwa.edu.au.

Marlin is also given an IP in our domain as a convenience.  If they blow up
their name serving there is less that can go wrong because people can still
see that machine which is a start.  You could place "marlin.ucc" in the
first column and leave the machine totally inside the ucc domain as well.

The second NS line is because mackerel will be acting as secondary name
server for the ucc.gu domain.  Do not include this line if you are not
authorative for the information included in the sub-domain.


Troubleshooting your named:

Named doesn't work!  What is wrong?

Step 1:  Run nslookup and see what nameserver it tries to connect you to.
If nslookup connects you to the wrong nameserver, create a /etc/resolv.conf
file that points your machine at the correct nameserver.  If there is no
resolv.conf file, the the resolver uses the nameserver on the local
machine.

Step 2:  Make sure that named is actually running.

Step 3:  Restart named and see if you get any error messages on the
console and in also check /usr/adm/messages.

Step 4:  If named is running, nslookup connects to the appropriate
nameserver and nslookup can answer simple questions, but other programs
such as 'ping' do not work with names, then you need to install resolv+
most likely.


I changed my named database and my local machine has noticed, but nobody
else has the new information?

Change the serial number in the SOA for any domains that you modified and
restart named.  Wait an hour and check again.  The information propogates
out.  It won't change immediately.


My local machine knows about all the name server information, but no other
sites know about me?

Find an upstream nameserver (one that has an SOA for something in your
domain) and ask them to be a secondary name server for you.  eg if you are
ecel.uwa.edu.au, ask someone who has an SOA for the domain uwa.edu.au.
Get NS records (and glue) added to your parent zone for your zone. This is
called delegating. It should be done formally like this or you will get
inconsistant answers out of the DNS.  ALL NAMSERVERS FOR YOUR ZONE SHOULD
BE LISTED IN THIS MANNER.


My forward domain names work, but the backward names do not?

Make sure the numbers are back to front and have the in-addr.arpa on the
end.
Make sure you reverse zone is registered. For Class C nets this can be done
by mailing to [e-mail]. For class A & B nets make sure that
you are registeres with the primary for your net and that the net itself
is registered with [e-mail].


How to get useful information from nslookup:

Nslookup is a very useful program but I'm sure there are less than 20
people worldwide who know how to use it to its full usefulness.  I'm most
certainly not one of them.  If you don't like using nslookup, there is at
least one other program called dig, that has most/all(?) of the
functionality of nslookup and is a hell of a lot easier to use.

I won't go into dig much here except to say that it is a lot easier to get
this information out of.  I won't bother because nslookup ships with almost
all machines that come with network software.

To run nslookup, you usually just type nslookup.  It will tell you the
server it connects to.  You can specify a different server if you want.
This is useful when you want to tell if your named information is
consistent with other servers.

Getting name to number mappings.

Type the name of the machine.  Typing 'decel' is enough if the machine is
local.

(Once you have run nslookup successfully)
> decel
Server:  ecel.uwa.edu.au
Address:  130.95.4.2

Name:    decel.ecel.uwa.edu.au
Address:  130.95.4.2

>

One curious quirk of some name resolvers is that if you type a
machine name, they will try a number of permutations.  For example if my
machine is in the domain ecel.uwa.edu.au and I try to find a machine
called fred, the resolver will try the following.

  fred.ecel.uwa.edu.au.
  fred.uwa.edu.au.
  fred.edu.au.
  fred.au.
  fred.

This can be useful, but more often than not, you would simply prefer a good
way to make aliases for machines that are commonly referenced.  If you are
running resolv+, you should just be able to put common machines into the
host file.

DIG: dig <machine name>

Getting number to name mappings.

Nslookup defaults to finding you the Address of the name specified.  For
reverse lookups you already have the address and you want to find the
name that goes with it.  If you read and understood the bit above where it
describes how to create the number to name mapping file, you would guess
that you need to find the PTR record instead of the A record.  So you do
the following.

> set type=ptr
> 2.4.95.130.in-addr.arpa
Server:  decel.ecel.uwa.edu.au
Address:  130.95.4.2

2.4.95.130.in-addr.arpa host name = decel.ecel.uwa.edu.au
>

nslookup tells you that the ptr for the machine name
2.4.95.130.in-addr.arpa points to the host decel.ecel.uwa.edu.au.

DIG: dig -x <machine number>

Finding where mail goes when a machine has no IP number.

When a machine is not IP connected, it needs to specify to the world, where
to send the mail so that it can dial up and collect it every now and then.
This is accomplished by setting up an MX record for the site and not giving
it an IP number.  To get the information out of nslookup as to where the
mail goes, do the following.

> set type=mx
> dialix.oz.au
Server:  decel.ecel.uwa.oz.au
Address:  130.95.4.2

Non-authoritative answer:
dialix.oz.au    preference = 100, mail exchanger = uniwa.uwa.OZ.AU
dialix.oz.au    preference = 200, mail exchanger = munnari.OZ.AU
Authoritative answers can be found from:
uniwa.uwa.OZ.AU inet address = 130.95.128.1
munnari.OZ.AU   inet address = 128.250.1.21
munnari.OZ.AU   inet address = 192.43.207.1
mulga.cs.mu.OZ.AU       inet address = 128.250.35.21
mulga.cs.mu.OZ.AU       inet address = 192.43.207.2
dmssyd.syd.dms.CSIRO.AU inet address = 130.155.16.1
ns.UU.NET       inet address = 137.39.1.3