summaryrefslogtreecommitdiffstats
path: root/contrib/bind/doc/misc/dns-setup
diff options
context:
space:
mode:
Diffstat (limited to 'contrib/bind/doc/misc/dns-setup')
-rw-r--r--contrib/bind/doc/misc/dns-setup1081
1 files changed, 1081 insertions, 0 deletions
diff --git a/contrib/bind/doc/misc/dns-setup b/contrib/bind/doc/misc/dns-setup
new file mode 100644
index 0000000..19f0197
--- /dev/null
+++ b/contrib/bind/doc/misc/dns-setup
@@ -0,0 +1,1081 @@
+ 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; \
+====================
+
OpenPOWER on IntegriCloud