Anonymous_User Absent Member.
Absent Member.
1651 views

Rootserverinfo problem

Hi,

Some weeks ago I deleted our Netware 6.5 Sp2 DNS server's rootserverinfo
zone after a dsrepair procedure caused some random unknown objects in the
tree, including some in the rootserverinfo object, and dns for external
internet histnames stopped working.
Last night I recreated it using the standard import template supplied by
Brad in previous posts, but it still would not resolve internet hostnames.
Although internal names in it's own database worked fine deleting the newly
recreated zone fixed the problem.

I'm not sure how to fix this problem.

One possiblity: there are forwarding addresses set for both our dns servers
(which are both primaries). The first entry is the external dns server of
our internet provider. I noticed that trying to troubleshoot that if I tried
to invoked this external dns server to perform an nslookup on www.google.com
(with the command "nslookup www.google.com xx.xx.xx.xx" then I got a failure
message which seemed to be based on the fact that dns couldn't resolve the
ip address of the external dns server to a hostname. Does dns *need* to be
able to resolve the hostname of a dns server in order to use it? Why can't
it just query it as an ip address? Does this mean I have to put in an A
record or nameserver record for all forwarding entries?
Once I deleted the rootserverinfo zone I can use the external dns server in
this way as it has no trouble resolving it's hostname.

I tried to take a log trace but was under too much pressure to fix the
problem and screwed up the command. I'll see if I can get one tonight by
recreating the problem.

Our network is fairly simple: one main dns zone, two primaries (the second
being for fault-tolerance), no zone transfers or anything like that.
NW65SP2, named.nlm is 6.03.06 14th Dec 2004.

Any help appreciated,


Steve Law



Labels (1)
0 Likes
3 Replies
Anonymous_User Absent Member.
Absent Member.

Re: Rootserverinfo problem

In article <Z88Id.543$863.39@prv-forum2.provo.novell.com>, SLaw wrote:
> I noticed that trying to troubleshoot that if I tried
> to invoked this external dns server to perform an nslookup on www.google.com
> (with the command "nslookup www.google.com xx.xx.xx.xx" then I got a failure
> message which seemed to be based on the fact that dns couldn't resolve the
> ip address of the external dns server to a hostname. Does dns *need* to be
> able to resolve the hostname of a dns server in order to use it?
>

Where were you running NSLOOKUP from? A Windows machine? Your Novell server?

Trying the same thing here from an XP machine does get an error about not
being able to find the name of the DNS server, but it still resolves. So...
1) your problem doesn't seem to be related to the reverse lookup problem, and
2) the reverse lookup problem NAY be specific to the NSLOOKUP client and
version being run.

> Once I deleted the rootserverinfo zone I can use the external dns server in
> this way as it has no trouble resolving it's hostname.
>

As you've noted, the problem appears to be related to your RootServrInfo zone.
I think when you import the zone, the import process insists on assigning the
zone an authoritative server. In my working config, there is no authoritative
to designated primary server assigned to the zone -- try duplicating that and
see if it helps.

bd
NSC Volunteer SysOp


0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Rootserverinfo problem

Hi Brad,

You're saying I should NOT assign an authoritative server to the
rootserverinfo zone?
I'll test as soon as I can find a time slot.

Thanks,


Steve Law


"Brad Doster" <bd@NSCSysOps.net> wrote in message
news:VA.00002ebf.0a53d2b9@nscsysops.net...
> In article <Z88Id.543$863.39@prv-forum2.provo.novell.com>, SLaw wrote:
> > I noticed that trying to troubleshoot that if I tried
> > to invoked this external dns server to perform an nslookup on

www.google.com
> > (with the command "nslookup www.google.com xx.xx.xx.xx" then I got a

failure
> > message which seemed to be based on the fact that dns couldn't resolve

the
> > ip address of the external dns server to a hostname. Does dns *need* to

be
> > able to resolve the hostname of a dns server in order to use it?
> >

> Where were you running NSLOOKUP from? A Windows machine? Your Novell

server?
>
> Trying the same thing here from an XP machine does get an error about not
> being able to find the name of the DNS server, but it still resolves.

So...
> 1) your problem doesn't seem to be related to the reverse lookup problem,

and
> 2) the reverse lookup problem NAY be specific to the NSLOOKUP client and
> version being run.
>
> > Once I deleted the rootserverinfo zone I can use the external dns server

in
> > this way as it has no trouble resolving it's hostname.
> >

> As you've noted, the problem appears to be related to your RootServrInfo

zone.
> I think when you import the zone, the import process insists on assigning

the
> zone an authoritative server. In my working config, there is no

authoritative
> to designated primary server assigned to the zone -- try duplicating that

and
> see if it helps.
>
> bd
> NSC Volunteer SysOp
>
>



0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Rootserverinfo problem

In article <Tu2Jd.923$P_6.914@prv-forum2.provo.novell.com>, SLaw wrote:
> You're saying I should NOT assign an authoritative server to the
> rootserverinfo zone?
>

Correct

> I'll test as soon as I can find a time slot.
>

Sounds good...

bd
NSC Volunteer SysOp


0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.