path: root/contrib/bind/doc/misc/dns-setup

                Setting up a basic DNS server for a domain
                            Revision 1.1.1

                            Craig Richmond
                         craig@ecel.uwa.edu.au
                           15th 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 <Mark.McIntosh@engr.UVic.CA> 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
Mark.Andrews@syd.dms.csiro.au.

        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
<Christophe.Wolfhugel@grasp.insa-lyon.fr>  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
;
; 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
    root@decel.ecel.uwa.edu.au 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 fred@ecel.uwa.edu.au
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
fred@ecel.uwa.edu.au 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,
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 chris@chris-mac.ecel.uwa.edu.au
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 jep@convex.nl (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
                                        jep@convex.nl
                                        =============



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 hostmaster@internic.net. 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 hostmaster@internic.net.


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

You tell nslookup that you want to search for mx records and then you give
it the name of the machine.  It tells you the preference for the mail
(small means more preferable), and who the mail should be sent to.  It also
includes sites that are authorative (have this name in their named database
files) for this MX record.  There are multiple sites as a backup.  As can
be seen, our local public internet access company dialix would like all of
their mail to be sent to uniwa, where they collect it from.  If uniwa is
not up, send it to munnari and munnari will get it to uniwa eventually.

NOTE: For historical reasons Australia used to be .oz which was changed to
.oz.au to move to the ISO standard extensions upon the advent of IP.  We
are now moving to a more normal heirarchy which is where the .edu.au comes
from.  Pity, I liked having oz.

DIG: dig <zone> mx

Getting a list of machines in a domain from nslookup.

Find a server that is authorative for the domain or just generally all
knowing.  To find a good server, find all the soa records for a given
domain.  To do this, you set type=soa and enter the domain just like in the
two previous examples.

Once you have a server type 

> ls gu.uwa.edu.au.
[uniwa.uwa.edu.au]
Host or domain name            Internet address
 gu                             server = mackerel.gu.uwa.edu.au
 gu                             server = uniwa.uwa.edu.au
 gu                             130.95.100.3
 snuffle-upagus                 130.95.100.131
 mullet                         130.95.100.2
 mackerel                       130.95.100.3
 marlin                         130.95.100.4
 gugate                         130.95.100.1
 gugate                         130.95.100.129
 helpdesk                       130.95.100.180
 lan                            130.95.100.0
 big-bird                       130.95.100.130

To get a list of all the machines in the domain.

If you wanted to find a list of all of the MX records for the domain, you
can put a -m flag in the ls command.

> ls -m gu.uwa.edu.au.
[uniwa.uwa.edu.au]
Host or domain name            Metric Host
 gu                             100  mackerel.gu.uwa.edu.au
 gu                             200  uniwa.uwa.edu.au

This only works for a limited selection of the different types.

DIG: dig axfr <zone> @<server>



Appendix A


;
;       This file holds the information on root name servers needed to
;       initialize cache of Internet domain name servers
;       (e.g. reference this file in the "cache  .  <file>"
;       configuration file of BIND domain name servers).
;
;       This file is made available by InterNIC registration services
;       under anonymous FTP as
;           file                /domain/named.root
;           on server           FTP.RS.INTERNIC.NET
;       -OR- under Gopher at RS.INTERNIC.NET
;           under menu          InterNIC Registration Services (NSI)
;              submenu          InterNIC Registration Archives
;           file                named.root
;
;       last update:    April 21, 1993
;       related version of root zone:   930421
;
.                        99999999 IN  NS    NS.INTERNIC.NET.
NS.INTERNIC.NET.         99999999     A     198.41.0.4
.                        99999999     NS    KAVA.NISC.SRI.COM.
KAVA.NISC.SRI.COM.       99999999     A     192.33.33.24
.                        99999999     NS    C.NYSER.NET.
C.NYSER.NET.             99999999     A     192.33.4.12
.                        99999999     NS    TERP.UMD.EDU.
TERP.UMD.EDU.            99999999     A     128.8.10.90
.                        99999999     NS    NS.NASA.GOV.
NS.NASA.GOV.             99999999     A     128.102.16.10
                         99999999     A     192.52.195.10
.                        99999999     NS    NS.NIC.DDN.MIL.
NS.NIC.DDN.MIL.          99999999     A     192.112.36.4
.                        99999999     NS    AOS.ARL.ARMY.MIL.
AOS.ARL.ARMY.MIL.        99999999     A     128.63.4.82
                         99999999     A     192.5.25.82
.                        99999999     NS    NIC.NORDU.NET.
NIC.NORDU.NET.           99999999     A     192.36.148.17
; End of File


Appendix B

An Excerpt from
RFC 1340		    Assigned Numbers		       July 1992


			       MACHINE NAMES

   These are the Official Machine Names	as they	appear in the Domain Name
   System HINFO	records	and the	NIC Host Table.	 Their use is described	in
   RFC-952 [53].

   A machine name or CPU type may be up	to 40 characters taken from the
   set of uppercase letters, digits, and the two punctuation characters
   hyphen and slash.  It must start with a letter, and end with	a letter
   or digit.

      ALTO				    DEC-1080
      ALTOS-6800			    DEC-1090
      AMDAHL-V7				    DEC-1090B
      APOLLO				    DEC-1090T
      ATARI-104ST			    DEC-2020T
      ATT-3B1				    DEC-2040
      ATT-3B2				    DEC-2040T
      ATT-3B20				    DEC-2050T
      ATT-7300				    DEC-2060
      BBN-C/60				    DEC-2060T
      BURROUGHS-B/29			    DEC-2065
      BURROUGHS-B/4800			    DEC-FALCON
      BUTTERFLY				    DEC-KS10
      C/30				    DEC-VAX-11730
      C/70				    DORADO
      CADLINC				    DPS8/70M
      CADR				    ELXSI-6400
      CDC-170				    EVEREX-386
      CDC-170/750			    FOONLY-F2
      CDC-173				    FOONLY-F3
      CELERITY-1200			    FOONLY-F4
      CLUB-386				    GOULD
      COMPAQ-386/20			    GOULD-6050
      COMTEN-3690			    GOULD-6080
      CP8040				    GOULD-9050
      CRAY-1				    GOULD-9080
      CRAY-X/MP				    H-316
      CRAY-2				    H-60/68
      CTIWS-117				    H-68
      DANDELION				    H-68/80
      DEC-10				    H-89
      DEC-1050				    HONEYWELL-DPS-6
      DEC-1077				    HONEYWELL-DPS-8/70
      HP3000				    ONYX-Z8000
      HP3000/64				    PDP-11
      IBM-158				    PDP-11/3
      IBM-360/67			    PDP-11/23
      IBM-370/3033			    PDP-11/24
      IBM-3081				    PDP-11/34
      IBM-3084QX			    PDP-11/40
      IBM-3101				    PDP-11/44
      IBM-4331				    PDP-11/45
      IBM-4341				    PDP-11/50
      IBM-4361				    PDP-11/70
      IBM-4381				    PDP-11/73
      IBM-4956				    PE-7/32
      IBM-6152				    PE-3205
      IBM-PC				    PERQ
      IBM-PC/AT				    PLEXUS-P/60
      IBM-PC/RT				    PLI
      IBM-PC/XT				    PLURIBUS
      IBM-SERIES/1			    PRIME-2350
      IMAGEN				    PRIME-2450
      IMAGEN-8/300			    PRIME-2755
      IMSAI				    PRIME-9655
      INTEGRATED-SOLUTIONS		    PRIME-9755
      INTEGRATED-SOLUTIONS-68K		    PRIME-9955II
      INTEGRATED-SOLUTIONS-CREATOR	    PRIME-2250
      INTEGRATED-SOLUTIONS-CREATOR-8	    PRIME-2655
      INTEL-386				    PRIME-9955
      INTEL-IPSC			    PRIME-9950
      IS-1				    PRIME-9650
      IS-68010				    PRIME-9750
      LMI				    PRIME-2250
      LSI-11				    PRIME-750
      LSI-11/2				    PRIME-850
      LSI-11/23				    PRIME-550II
      LSI-11/73				    PYRAMID-90
      M68000				    PYRAMID-90MX
      MAC-II				    PYRAMID-90X
      MASSCOMP				    RIDGE
      MC500				    RIDGE-32
      MC68000				    RIDGE-32C
      MICROPORT				    ROLM-1666
      MICROVAX				    S1-MKIIA
      MICROVAX-I			    SMI
      MV/8000				    SEQUENT-BALANCE-8000
      NAS3-5				    SIEMENS
      NCR-COMTEN-3690			    SILICON-GRAPHICS
      NEXT/N1000-316			    SILICON-GRAPHICS-IRIS
      NOW				    SGI-IRIS-2400
      SGI-IRIS-2500			    SUN-3/50
      SGI-IRIS-3010			    SUN-3/60
      SGI-IRIS-3020			    SUN-3/75
      SGI-IRIS-3030			    SUN-3/80
      SGI-IRIS-3110			    SUN-3/110
      SGI-IRIS-3115			    SUN-3/140
      SGI-IRIS-3120			    SUN-3/150
      SGI-IRIS-3130			    SUN-3/160
      SGI-IRIS-4D/20			    SUN-3/180
      SGI-IRIS-4D/20G			    SUN-3/200
      SGI-IRIS-4D/25			    SUN-3/260
      SGI-IRIS-4D/25G			    SUN-3/280
      SGI-IRIS-4D/25S			    SUN-3/470
      SGI-IRIS-4D/50			    SUN-3/480
      SGI-IRIS-4D/50G			    SUN-4/60
      SGI-IRIS-4D/50GT			    SUN-4/110
      SGI-IRIS-4D/60			    SUN-4/150
      SGI-IRIS-4D/60G			    SUN-4/200
      SGI-IRIS-4D/60T			    SUN-4/260
      SGI-IRIS-4D/60GT			    SUN-4/280
      SGI-IRIS-4D/70			    SUN-4/330
      SGI-IRIS-4D/70G			    SUN-4/370
      SGI-IRIS-4D/70GT			    SUN-4/390
      SGI-IRIS-4D/80GT			    SUN-50
      SGI-IRIS-4D/80S			    SUN-100
      SGI-IRIS-4D/120GTX		    SUN-120
      SGI-IRIS-4D/120S			    SUN-130
      SGI-IRIS-4D/210GTX		    SUN-150
      SGI-IRIS-4D/210S			    SUN-170
      SGI-IRIS-4D/220GTX		    SUN-386i/250
      SGI-IRIS-4D/220S			    SUN-68000
      SGI-IRIS-4D/240GTX		    SYMBOLICS-3600
      SGI-IRIS-4D/240S			    SYMBOLICS-3670
      SGI-IRIS-4D/280GTX		    SYMMETRIC-375
      SGI-IRIS-4D/280S			    SYMULT
      SGI-IRIS-CS/12			    TANDEM-TXP
      SGI-IRIS-4SERVER-8		    TANDY-6000
      SPERRY-DCP/10			    TEK-6130
      SUN				    TI-EXPLORER
      SUN-2				    TP-4000
      SUN-2/50				    TRS-80
      SUN-2/100				    UNIVAC-1100
      SUN-2/120				    UNIVAC-1100/60
      SUN-2/130				    UNIVAC-1100/62
      SUN-2/140				    UNIVAC-1100/63
      SUN-2/150				    UNIVAC-1100/64
      SUN-2/160				    UNIVAC-1100/70
      SUN-2/170				    UNIVAC-1160
      UNKNOWN
      VAX-11/725
      VAX-11/730
      VAX-11/750
      VAX-11/780
      VAX-11/785
      VAX-11/790
      VAX-11/8600
      VAX-8600
      WANG-PC002
      WANG-VS100
      WANG-VS400
      WYSE-386
      XEROX-1108
      XEROX-8010
      ZENITH-148

			       SYSTEM NAMES

   These are the Official System Names as they appear in the Domain Name
   System HINFO	records	and the	NIC Host Table.	 Their use is described
   in RFC-952 [53].

   A system name may be	up to 40 characters taken from the set of upper-
   case	letters, digits, and the three punctuation characters hyphen,
   period, and slash.  It must start with a letter, and	end with a
   letter or digit.

   AEGIS		     LISP		       SUN OS 3.5
   APOLLO		     LISPM		       SUN OS 4.0
   AIX/370		     LOCUS		       SWIFT
   AIX-PS/2		     MACOS		       TAC
   BS-2000		     MINOS		       TANDEM
   CEDAR		     MOS		       TENEX
   CGW			     MPE5		       TOPS10
   CHORUS		     MSDOS		       TOPS20
   CHRYSALIS		     MULTICS		       TOS
   CMOS			     MUSIC		       TP3010
   CMS			     MUSIC/SP		       TRSDOS
   COS			     MVS		       ULTRIX
   CPIX			     MVS/SP		       UNIX
   CTOS			     NEXUS		       UNIX-BSD
   CTSS			     NMS		       UNIX-V1AT
   DCN			     NONSTOP		       UNIX-V
   DDNOS		     NOS-2		       UNIX-V.1
   DOMAIN		     NTOS		       UNIX-V.2
   DOS			     OS/DDP		       UNIX-V.3
   EDX			     OS/2		       UNIX-PC
   ELF			     OS4		       UNKNOWN
   EMBOS		     OS86		       UT2D
   EMMOS		     OSX		       V
   EPOS			     PCDOS		       VM
   FOONEX		     PERQ/OS		       VM/370
   FUZZ			     PLI		       VM/CMS
   GCOS			     PSDOS/MIT		       VM/SP
   GPOS			     PRIMOS		       VMS
   HDOS			     RMX/RDOS		       VMS/EUNICE
   IMAGEN		     ROS		       VRTX
   INTERCOM		     RSX11M		       WAITS
   IMPRESS		     RTE-A		       WANG
   INTERLISP		     SATOPS		       WIN32
   IOS			     SCO-XENIX/386	       X11R3
   IRIX			     SCS		       XDE
   ISI-68020		     SIMP		       XENIX
   ITS			     SUN



Appendix C     Installing DNS on a Sun when running NIS

====================
 2)     How to get DNS to be used when running NIS ?

        First setup the appropriate /etc/resolv.conf file.
        Something like this should do the "trick".

        ;
        ; Data file for a client.
        ;
        domain          local domain
        nameserver      address of primary domain nameserver
        nameserver      address of secondary domain nameserver

        where:  "local domain" is the domain part of the hostnames.
                 For example, if your hostname is "thor.ece.uc.edu"
                 your "local domain" is "ece.uc.edu".

        You will need to put a copy of this resolv.conf on
        all NIS(YP) servers including slaves.

        Under SunOS 4.1 and greater, change the "B=" at the top
        of the /var/yp/Makefile to "B=-b" and setup NIS in the
        usual fashion.

        You will need reboot or restart ypserv for these changes
        to take affect.

        Under 4.0.x, edit the Makefile or apply the following "diff":

*** Makefile.orig       Wed Jan 10 13:22:11 1990
--- Makefile    Wed Jan 10 13:22:01 1990
***************
*** 63 ****
!                   | $(MAKEDBM) - $(YPDBDIR)/$(DOM)/hosts.byname; \
--- 63 ----
!                   | $(MAKEDBM) -b - $(YPDBDIR)/$(DOM)/hosts.byname; \
***************
*** 66 ****
!                   | $(MAKEDBM) - $(YPDBDIR)/$(DOM)/hosts.byaddr; \
--- 66 ----
!                   | $(MAKEDBM) -b - $(YPDBDIR)/$(DOM)/hosts.byaddr; \
====================