4.4BSD/usr/src/contrib/bind-4.9/contrib/misc/made-easy
Path: pa.dec.com!decwrl!uunet!munnari.oz.au!uniwa!craig
From: craig@ecel.uwa.edu.au (Craig Richmond - division)
Newsgroups: comp.protocols.tcp-ip.domains
Subject: DNS Made Easy (Well that was the plan anyway)
Date: 13 May 1993 10:39:31 GMT
Organization: The University of Western Australia
Lines: 529
Distribution: inet
Message-ID: <1st8h3$laa@uniwa.uwa.edu.au>
NNTP-Posting-Host: decel.ecel.uwa.edu.au
Summary: A guide to installing and testing a domain name server
Keywords: FAQ DNS tutorial step by step
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). If someone would like to provide a pointer to the
appropriate FAQ (I'll include it in here). I have a copy of one particular
set of instructions if you need it.
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. This can take a couple of days, but in all
reality I have no idea how long the worst case is.
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.
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
primary ecel.uwa.edu.au ecel.uwa.domain
primary 0.0.127.in-addr.arpa 4.95.130.domain
primary 4.95.130.in-addr.arpa 4.95.130.domain
cache . root.cache
The lines mean the following.
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.
primary
This is a domain for which this domain is probably 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 hypothetical (or at the moment real) 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.
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.
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 some number of IP addresses for the machines to
query that probably depends on your machine. The numbers 3 and 10 spring
to mind, but I can't remember where from. 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 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. (
93051000 ; 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 200 munnari.oz.au.
IN MX 500 uunet.UU.NET.
localhost IN A 127.0.0.1
decel IN A 130.95.4.2
IN HINFO SUN4/75 UNIX
IN MX 100 decel
IN MX 200 munnari.oz.au.
IN MX 500 uunet.UU.NET.
gopher IN CNAME decel.ecel.uwa.edu.au.
accfin IN A 130.95.4.3
IN HINFO SUN4/75 UNIX
IN MX 100 decel
IN MX 200 munnari.oz.au.
IN MX 500 uunet.UU.NET.
chris-mac IN A 130.95.4.5
IN HINFO MACIICi SYS7.1
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 old
the information must become before it is dumped. This is to help the
information withstand fairly lengthy downtimes of machines or connections
in the network without having to recollect all the information. 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 munnari.oz.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 munnari. And failing that, try the site uunet.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. NOTE: This is really stupid.
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.
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 pornographic 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 porno pictures 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 now have the record for another unix machine called accfin. Nothing
special here, but there are no CNAMEs that point to this machine. Perhaps
we should put gopher there instead. Much less load on decel then.
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 macIIci running System 7.1. Take this information with a grain of
salt because in 5 years time, he will probably still be using a macIIci
running system 7.1 because nobody ever keeps the DNS information up to
date.
NOTE: If Chris had a very high profile and wanted his mac to appear like a
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.
Reverse Name Lookups:
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
;
@ 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.
--
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.
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.
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.
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.
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.
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. Simple 'decel' is enough. 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.
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.
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.
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.
Well that about wraps it up. If anyone else has any questions or answers
or comments they think should be in here, mail me and I'll add them. I'll
also probably set up an automated posting thing so that this file gets
posted to the newsgroup once a month or so. Hope all of this information
helps someone. I had to learn it all the hard way and if I can save
someone that trouble it will have been worth it.
(P.S. I haven't proof read this so if there are any gaping holes, let me
know ASAP so I can fix them)
Craig
--
Craig Richmond. Computer Officer - Dept of Economics (morning) 380 3860
University of Western Australia Dept of Education (afternoon) 2388
craig@ecel.uwa.edu.au Dvorak Keyboards RULE! "Messes are only acceptable
if users make them. Applications aren't allowed this freedom" I.M.VI 2-4