LSTOWN-L Archives

LISTSERV List Owners' Forum

LSTOWN-L

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Topic: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Melvin Klassen <[log in to unmask]>
Fri, 13 Sep 1996 17:17:17 PDT
text/plain (174 lines)
On Fri, 13 Sep 1996 14:57:02 -0500,
"Ingrid H. Shafer" <[log in to unmask]> wrote:
 
> This is not a listserv problem; however could Peter Weiss or one of
> the other experts on this list come to our assistance.
 
I'm not an expert; I'm just a tutor, but I'll try.  :-)
 
> I teach at the University of Science and Arts of Oklahoma.  Our Hostname is
> MNERCUR.USAO.EDU and we have TWO addresses, 192.146.206.5 (VAX applications)
> and 192.146.206.1 ...
 
It's "MERCUR.USAO.EDU", and it has one IP-address, namely '192.146.206.5'.
 
According to information registered on the InterNIC servers,
DNS (Domain Name Service) for the 'USAO.EDU' domain is provided by two hosts,
namely: NMSVR.usao.edu (192.146.206.1)
and:    ZOO.BACKBONE.OU.edu (129.15.1.10).
 
However, the DNS-software on 'NMSRV.usao.edu' does *NOT*,
at least currently, seem to be giving any "answers",
i.e., it is not providing any "service".  This should be investigated
by the person(s) responsible for running that computer.
 
> (presumably the router to act as name server).
 
IP-routing from the MCI-backbone to 'MERCUR' is:
 
  core1-hssi-2.KansasCity.mci.net          (204.70.1.158)
  core1-hssi-2.KansasCity.mci.net          (204.70.1.158)
  border4-fddi-0.KansasCity.mci.net        (204.70.3.67)
  oklahoma-state-regent.KansasCity.mci.net (204.70.43.6)
  (server failed)                          (164.58.224.2)
  (non-existent domain)                    (192.146.206.5)
 
So, 'MERCUR' is a "de-facto" router.
 
Note that the "inverse" DNS functions,
which map from IP-addresses to host-names,
fail to "map" two of the hosts.  This should be investigated,
since it is one of "your" DNS-servers which should *NOT* be
reporting "non-existent domain".
 
Note that information registered at the InterNIC states
that the host 'MERCUR.USAO.EDU' provides "inverse"
DNS service for the '206.146.192.in-addr.arpa' domain.
Since it isn't doing this, this should be investigated.
Why this host is beingn named,
instead of one of the listed DNS servers, is another question.
 
> No one knows why we are set up this way.  If you run whois on the ...1
> address you find that it was last updated in Feb. 1992 and shows a Macintosh
> running some unknown operating system.   The ...5 address gives correct
> current information.
 
Updates should be E-mailed to [log in to unmask]
 
> When whois is run on the Domain Name, USAO.EDU, Domain servers in listed
> order are ZOO.BACKBONE.OU.EDU 129.15.1.102 (the University of Oklahoma
> which is in no way associated with us) and NMSVR.USAO.EDU, 192.146.206.1--
> which is our actual address.
 
It's quite-common for institutions to cooperate, and to provide DNS service
for some nearby organization.  For example, DNS service for 'PINC.COM' is
provided by 'CCINS.CAMOSUN.BC.CA' (also known as 'NS2.PINC.COM')
and by 'NS.PINC.COM'.  This only takes a commitment of about 1MB of disk-space,
and an ability to occasionally copy the DNS information from the "primary"
server to the "secondary" server, to establish a "backup" server.
 
>Apparently, when information is routed
> to ZOO.BACKBONE it tends to get stuck, and since that address is listed
> as PRIMARY DNS, the system looks no further and doesn't even locate
> our functioning Domain server.
 
Note that DNS uses a "client-server" model.
If some host is running a "brain-damaged" client, i.e., one which doesn't
interrogate the secondary server when the primary server fails to answer,
then the only solution is to fix that client, to function correctly.
Fixing the primary server is only a "bypass" to this problem.
However, in your case, this is *NOT* the cause of your problems. See below.
 
> Our computer systems administrator is Lynn Boyce who took over after our
> previous administrator left a couple of years ago.  She has been trying
> to unravel this mess.  Neither OU nor InterNIC has been of assistance.
> In the meantime our access to Internet is constantly interrupted
> by DNS problems.  We presume this is caused by this dual and confusing
> registration but have been unable to find a live person to see to it that
> the registration is updated.  I told Lynn that I would enlist your help.
> Is there someone with InterNIC Lynn could contact to get this corrected?
 
First, you need to get your own "house" in order,
i.e., either create and run two DNS servers on your own campus,
(be sure to also make the "inverse" mapping work)
and then talk to somebody at 'OU.EDU', if you want to continue (or terminate)
your arrangement to have their machine 'ZOO.BACKBONE' to function
as a secondary (or tertiary) DNS.  However, since the amount of information
to be placed into your DNS is extremely *TINY*, i.e.,
 
[zoo.backbone.ou.edu]
 usao.edu.                      server = zoo.backbone.uoknor.edu
 zoo.backbone.uoknor.edu.       129.15.1.10
 is0104                         192.146.206.104
 ??????
 ?????? Does this computer exist?
 
 usaohub                        192.146.206.1
 loopback                       127.0.0.1
 mercur                         192.146.206.5
 
my first suggestion clearly is "overkill".
 
Part of your problems may be due to incorrect information
stored in the DNS server on 'MERCUR', namely:
 
[mercur.usao.edu]
 USAO.EDU.                      server = MERCUR.USAO.EDU
 USAO.EDU.                      192.146.206.5
 ????????
 ????????  should be 'MERCUR.USAO.EDU'
 
 NMSVR                          192.146.206.1
 192.146.206.1                  server = NMSVR.USAO.EDU.USAO.EDU
 WWW                            192.146.206.5
 MERCUR                         192.146.206.5
 192.146.206.5                  server = MERCUR.USAO.EDU.USAO.EDU
 192.146.206.5                  server = WWW.USAO.EDU.USAO.EDU
 
Note the "duplication" of domain-suffixes, which is incorrect,
and the differences between this set of host-names versus
the information stored on 'ZOO.BACKBONE.OU.EDU',
which could also be part of your problem.
Hint: add/subtract a "dot" (or two) in the DNS database-definition;
their presence/absence as a suffix is *VERY* important.
 
Also, to repeat, the host 'NMSVR' is *NOT* providing *ANY* service
for the domain.  So, listing it as a DNS is a source of problems.
 
> Contacts at OU:
 
|  Administrative Contact:
|     Colaw, Lee M. [Director]  (LMC4)  [log in to unmask]
|     (405) 325-6988 (FAX) (405) 325-0485
|  Technical Contact, Zone Contact:
|     White, James D. [Assistant Director]  (JW136)  [log in to unmask]
|     (405) 325-6988 (FAX) (405) 325-0485
|  Billing Contact:
|     Smith, Glenda [Administrative Assistant]  (GS593)
|    [log in to unmask]
|     (405) 325-6988 (FAX) (405) 325-0485
 
Then, contact [log in to unmask], and tell them the IP-addresses
of your two (or three) DNS servers, and they will update your registration.
 
If you have access to a WWW-browser, check:
 
    http://rs.internic.net/rs-internic.html
 
for information on "Registration Services",
especially the section on "WWW-based Registration Tools",
which points to information titled "Register, Modify or Delete a DNS Host".
 
So, in summary:
 
1. Fix the incorrect data on MERCUR,
2. Distribute the corrected data to ZOO.BACKBONE.OU.EDU and to NMSVR,
3. Start the DNS-server on NMSVR,
4. Tell InterNIC that MERCUR and NMSVR and ZOO
   are the three DNS for the 'USAO.EDU' domain.
 
Or, omit #3 and tell InterNIC that only MERCUR and ZOO are the DNS servers.
Or, do #1 and #2 and #3, stop the DNS-server on MERCUR,
and tell the InterNIC nothing, since ZOO and NMSVR *will* then be providing
the service which the InterNIC expects them to be providing.

ATOM RSS1 RSS2