Docstoc

Setting up a basic DNS server for a domain

Document Sample
Setting up a basic DNS server for a domain Powered By Docstoc
					Setting up a basic DNS server for a domain

Revision 1.1.2



Craig Richmond

craig@ecel.uwa.edu.au

3rd August 1993



Additional comments by Ronny H. Kavli

kavli@ludd.luth.se

About this document



This document is starting to be really dated. It covers BIND-4 specific issues mostly. You should really
use BIND-8 instead. 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
&ltMark.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:
1 An Overview of the DNS




2 Installing the DNS



 2.1 The Boot File

 2.2 The Cache File

 2.3 The Forward Mapping File

 2.4 The Reverse Mapping File




3 Delegating authority for domains within your domain



4 Troubleshooting your named



 4.1 Named doesn't work! What is wrong?

 4.2 Local has noticed change, but nobody else has new info

 4.3 I can see their info, but they can't see mine

 4.4 Forward domain works, but not backwards




5 How to get useful info from nslookup



 5.1 Getting name to number mappings
 5.2 Getting number to name mappings

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

 5.4 Getting a list of machines in a domain from nslookup




6 Appendicies



 6.1 Appendix A sample root.cache file

 6.2 Appendix B Excerpt from RFC 1340 - Assigned Numbers - July 1992

 6.3 Appendix C Installing DNS on a Sun when running NIS

 6.4 RFC-1034 (Domain Names - Concepts and Facilities

 6.5 RFC-1035 (Domain Names - Implementation and Specification




1 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.



2 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.x, which is the most recent
version at this point in time.
For more information on the latest version of BIND you should take a look at Internet Software
Consortium which sponsors the development of BIND. - Kavli



2.1 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.

An alternative is of course to make a symbolic link from /etc/named.boot to the wanted directory. -
Kavli



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 &ltChristophe.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

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.

Be sure you get an up-to-date cache-file. An obsolete cache file is a good source of problems. - Kavli



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 sec/gu.uwa.edu.au

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.



2.2 The cache file:



You should always use the latest cache file. The simplest way to do this is by using dig(1) this way:
dig @ns.internic.net . ns > root.cache



You can also get a copy of the cache file by ftp'ing FTP.RS.INTERNIC.NET.



An example of a cache file is located in Appendix A.



2.3 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 IN type is default and can safely be omitted. It looks better without them I think.

- Kavli
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. 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.



If your name contains a dot: E.g. Ronny.Kavli@mailhost.somedomain.there. - you must escape the dot ->
Ronny\.Kavli.mailhost.somedomain.there. - But, if possible, you should create a mailalias instead. That
way, related mail can go to more than one person. - Kavli

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 larger 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.

Do not point an MX record to a CNAME record. A lot of mailers don't handle this. Add another A-record
to it instead, but let the reverse table point to the real name. In other words: Don't add a PTR record to
it. - Kavli



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.

Regarding CNAME from dns: NS records must point to A records. Same for MX records. - Kavli



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)

WKS == Well Known Services. - The different services a host is providing

- Kavli



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.



2.4 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.

In general: Each primary file pointed to in named.boot should have one - and only one - SOA record.

- Kavli



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

                       =============



3 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 its 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.



4 Troubleshooting your named:



4.1 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.



4.2 Local has noticed change, but nobody else has new info



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.



4.3 I can see their info, but they can't see mine



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.
4.4 Forward domain works, but not backwards



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 your 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.



5 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.



5.1 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 &ltmachine name>



5.2 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 &ltmachine number>



5.3 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 &ltzone> mx



5.4 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 &ltzone> @&ltserver>



6 Appendicies



6.2 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




6.3 Appendix C

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; \

====================



--

Craig Richmond. Computer Officer - Dept of Economics (morning) 380 3860

    University of Western Australia Dept of Education (afternoon) 2368

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

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:11
posted:4/19/2011
language:English
pages:35