Link to home
Start Free TrialLog in
Avatar of Sebastien47136
Sebastien47136

asked on

NetWare 6.5 SP4 DNS issues

Hi everyone.

I'm having problems with my DNS services and hope someone here can help.

Here's the situation. I've got two NetWare 6.5 SP4 servers. Up until recently we housed our DNS on border, to resolve an internal problem we moved out DNS to LCS.

I work for a school so the state holds our secondary NS record. I've gotten them to update it to point to LCS, and that appears to be working fine. The problem comes when I go to the domains like "www" or "mail", etc. All of those are reporting that there is no NS record available or that the query has timed out. This effectively stops anyone from reaching our sites. I can still reach the sites just fine with the IP address.

In my DNS/DHCP tool I have 3 zones. A RootServerInfo, a IN-ADDR-ARPA, and the domain.

Under the IN_ADDR-ARPA there is a domain name entry for each server's public IP. As well as an "@" entry which I'm assuming is the root. Under the entries for servers there are PTR records pointing to the full site address of that server. For example server 123.123.123.1 has a domain name entry of 1.123.123.123.IN-ADDR-ARPA and under that entry has a PTR record of border.mysite.com as well as www.mysite.com. Yes, both "border" and "www" are the same server.

The "@" entry is the only entry that has an NS record, the NS entry is the only entry under the "@" entry. The NS record I have gives the full URL for our dns server. Example lcs.mysite.com

Moving on to the domain entries:

This area contains the entries such as "WWW" with an A record to point to the public IP address of the server. There is one "@" entry which contains our MX records and an NS record. All entries under the "@" entry give the full URL of the correct server. Example NS record = LCS.MYSITE.COM, MX record = mail.mysite.com.

Last but not least is the RootServerInfo. Along with the a.root-servers.net entries there is one "@" entry, with an NS record. The NS record again gives the full URL of the DNS server.

Now, moving on to other concerns. Named.nlm is loaded on the server and the server states that the DNS services are running. I've loaded and unloaded named.nlm several times all without success.

We have a PIX firewall which I've opened TCP and UDP traffic to port 53 for the DNS server as well as port 80 and other ports for their respective services.

I also know that entries with DNS take as long as 2 days to circulate the web so changes won't be noticed immediately. What miffs me is that Friday afternoon everything was working fine, Saturday at noon things have gone to poop again.

Thanks in advance for any assistance.
Avatar of ShineOn
ShineOn
Flag of United States of America image

LCS being a NetWare 6.5sp4 server on your LAN?

When you PING those URLs do they resolve?  Have you tried it from an external connection?  Perhaps the problem is with your private LAN's DNS setup and not the public side...

Do you use the same domain internally on your LAN as you do externally on the public 'net?  Are you using your LCS server as the private LAN's DNS resolver? Do you have only the LCS server listed as an authoritative server within your eDirectory tree, or is the border server still listed as an authoritative server?  Is NAMED.NLM only loaded on LCS or is it loaded anywhere else?  When you made the change from Border to LCS, did you simply add LCS as a name server and make it primary, or did you re-load everything?
Avatar of Sebastien47136
Sebastien47136

ASKER

Yes. LCS is a NetWare 6.5 SP4 server on our LAN.

Well pinging our servers from inside and outside the network is what I'm working to resolve, hence the move. Since you asked I'll go a bit into depth about it.

Prior to the move each domain had 2 "A" records. One for the public IP and one for the private IP. If we looked for an "A" record using www.dnsstuff.com we saw both records, public and private. If we pinged it we'd resolve to the private IP address. This struck me as odd, but our previous vendors had set things up that way and they had worked ever since. When I asked about it because it seemed weird I was told that's how it has to be. While trying to figure out why dial-up users often had trouble accessing our sites I tried removing the private A record and low and behold the the load time on the page was dramatically reduced. This had the unfortunate affect of leaving our internal users resolving to the public IP address which does not allow certain ports that are open on the inside. (Think GroupWise Messenger, GroupWise client, etc.)

The dual A records really made things rough on dial up users and they would often time out before they reached our page. Those on broadband were almost always able to duke it out between the IPs and have the page load. Pinging externally used to resolve to the private IP address, but now it's hit and miss as to which IP it resolves to Friday afternoon externally it resolved to the public IP address. When I get an error accessing the page it's resolved to the private IP address. Just to be clear the A record containing the private IP address is no longer present. At present www.dnsstuff.com lists only our Public A record.

If we ping the sites internally they all resolve to the public IP address. A seperate issue that I'm also working on. The URLs are listed in the hosts file, but they don't seem to be working any more. (Again, they were resolving internally to the private IP addresses on Friday afternoon.)

I think that answered your question about the domain as well. Yes, we use the same domain internally and externally. Ideally www.mysite.com internally would get 10.10.0.1 and externally 123.123.123.1

LCS is currently the private LAN's resolver with backups going outside the building. (Might explain why our URL's are resolving to public addresses.) LCS is listed as the only authoritative server in the eDirectory tree. (Which is odd, because even when things work right if I use nslookup I get a non-authoritative answer.) Maybe that can shed some light on things.

Named.nlm is only loaded on LCS. In the midst of things I tried loading named.nlm on Border to try and back-peddle, but found that it would not load. "Socket already bound". Whatever that indicates, afterwards it would shut down the DNS service on that server.

I didn't perform the DNS move myself, I had a vendor do that. From what I can tell LCS was just added and made primary. I had readd the entries to the hosts file and update the resolv.cfg file on the LCS server. All the DNS items from the DNS/DHCP management tool remained the same. I'm not sure if that's enough information to tell you definitively or not. If there is something specific I can look for to tell you if it was moved or copied let me know and I will look.
Is that BorderManager 3.8? (version may not matter, but it's nice to know...)  

If the DNS proxy is running, it will have DNS port(s) bound which might be what won't allow NAMED to load.  Could that be the case?  It's been a couple of years since I've worked directly with BorderManager and DNS...

Are you using 2 physical network interfaces in the BorderManager box, one public and one private?  How about the LCS box - does that have two NICs or one, with the public IP assignment via static NAT?

There is a way, I'm sure, to keep public DNS and private DNS separate while using the same domain name.  One sure way is to make sure your public DNS server never "talks" to your private DNS server...  Hard to do when your DNS servers share a common database.

I will have to do a bit of research to see if my ideas have any merit before I post 'em.  Maybe someone else will pitch in before then.

You could post a (20 point) pointer Question in the general Networking TA, since I believe this to be is more of a "generic" DNS logistics issue than a NetWare implementation of DNS issue.  Once the logistics are figured out, the NetWare DNS/DHCP configuration part shouldn't be difficult to apply to it.  Be sure to include a link to this question in the text of the pointer question.
In the DNS/DHCP console, does the server icon at the bottom show up as the LCS server?  Does the border server still show?
Border is running BorderManager 3.8 SP3.

Bound could we have been the term used when I tried to load Named.nlm on Border again. The jist of the message was that something it needed was already in use and it gave up.

Both servers have only 1 NIC. LCS has a primary and secondary IP address internally, both private, though I'm unclear which one does what. Having a nic with 2 IP addresses was foreign to me, but the guy who put it in knew what he was doing and voila it's got two IP's. Border on the other hand only as one private IP address.

I'm glad to hear someone else thinks that this is a pretty "basic" concept to get. My only problem is that it's not working the way it's supposed to. Very frustrating for someone who's at least moderately good on a network when the basics don't work and you can't figure out why. From my understanding internally DNS should go to the hosts file, if it doesn't find it there check the cache, if it doesn't find it there go outside to find the page. All signs point to our internal DNS skipping the hosts completely.

In the DNS/DHCP console I can see both LCS and Border. Border has a red x on it, but is still listed as a possible DNS server.
http://support.novell.com/cgi-bin/search/searchtid.cgi?10060968.htm

Tells how to isolate private from public.

You can use the same domain name, you just have to have two zones, a public and a private, with the private zone using the private addresses for the servers and the public zone only having the publicly-addressed names.
I never could understand how anyone could put in a bordermanager server with only one NIC.  That's inherently insecure, IMHO, and defeats the purpose unless you're only using it for HTML cache.

Does the LCS server have itself in its RESOLV.CFG?
Hi ShineOn,

Sorry for the delay in response.

I've got more information, hopefully it's helpful. First let me respond to your previous posts.

Thanks for the tips on isolating the private and public IP. Unfortunately we I don't have an extra DNS server to put outside the firewall, unless someone can recommend a free one in which case I'm all ears. :-)

Our BorderManager only servers for content filtering and caching, no VPN's or anything.

LCS does indeed have a RESOLV.CFG file

Here's the updates from the weekend.

The vender who set things up tweaked the system some over the weekend. Now everything internally works correctly, all the time. Externally is a different story....

LCS seems to always resolve to the correct IP address, probably because that's the only record that is housed outside of the building. BORDER as well as any other domains setup in the DNS don't always resolve to an IP, while sometimes they do. Once they do resolve to the correct IP it's only a matter of time (between 8 to 15 hours) before they stop resolving.

LCS does indeed have a RESOLV.CFG file with a domain pointing to mysite.com and two nameservers listed by IP address. (both external)

I'm wondering about just paying the $20 and having someone else house our DNS...it might just be the quick fix that I'm looking for.
ASKER CERTIFIED SOLUTION
Avatar of ShineOn
ShineOn
Flag of United States of America image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Hi ShineOn,

Thanks for the licensing information, could make for a nice test server and some good experience with NetWare for me.

After about a week of playing with things I asked the right question. The vender that working on this didn't realize that the server had 2 ip addresses. (Primary and Secondary) I blankly asked about an IP address he'd never heard of, and since I'd never heard of it I assumed he had added it. Turns out it goes many years and several vendors back.

Turns out DNS was binding to the secondary IP first, at least part of the time, so the more tweaking we did the less often DNS would work. After removing the secondary IP address everything is working as it should.

Many thanks for your time and consideration.