1

I need some help with a DNS issue. I have a sharepoint server that i just installed on our small network, we use the server name to get to it () which has an internal IP of 172.18.1.13. Randomly when users go to it they get a message that says:

We're sorry, but we were unable to process the redirection request for the site you are attempting to access. If you feel that you are receiving this message in error, please check the URL and try your request again.

(RF)

Doing a ping on it shows a new outside IP address. After a random time it will go back to the internal IP. I dont knw much about DNS and could use help with it. Our DNS is part of our AD 2008 system.

Also using the IP address in the broswer (http://172.18.1.13) works without issue. I can sometiems do a DNS Flush on the end users computers which will fix the issue for a time but it always comes back. Perhaps I didnt setup my DNS right? Looking in DNS I can see the Forward Lookup Zone has the server in there.

enter image description here enter image description here

enter image description here

enter image description here

1
  • Why the heck would you post all of your internal network info on a public website? As a security person I would have to let you go for that. Just sayin, in the future you may not want to give up the goods that easily.
    – Rob
    Jul 3, 2012 at 20:36

4 Answers 4

1

On an AD network, for all domain members (workstations, laptops, servers) you should ONLY have their TCP/IP Properties point to an internal AD DNS server for resolution, ideally two different DNS servers. The "Network Guy" (tm) was good-hearted in that they wanted you to have a "failover" solution in case your main DNS failed, but in adding an external DNS you've broke your AD DNS. By broke I mean that if any computers decide to use the 2nd DNS (4.2.2.2) then all of your internal resolution will stop working... even AD logins.

Having multiple DNS entries in your TCP/IP Properties is not so you can have "one inside, one outside" but to have redundancy in case the first fails. DNS is the lifeblood of a modern IP network so it's important to keep running. In a internal network with internal-only DNS records you would need to run two internal DNS servers if you wanted failover redundancy... simply sticking an external IP (4.2.2.2) as the 2nd will not work well (as you've seen).

So what's happening is your computers are randomly not able to talk to the primary DNS server (that is another issue you should look into) and when they can't connect they start using the Secondary DNS, which has no awareness of your internal DNS entries. Those computers ask 4.2.2. what your SharePoint servers IP is, and it knows of it as an Internet public IP. Windows will not just "switch" back to the Primary (that I'm aware of) until a reboot or restart the DNS Client service.

I bet you'll find that removing 4.2.2.2 solves the problem (but now you have no DNS failover). To fix that, you'll need a 2nd AD DC running DNS, and then stick it's IP in all computers Secondary DNS entry.

0

When I take a look at the zone, name-services.com seems to be authoritative on the outside, i.e. your domain at first glance doesn't look like it's handled by your internal AD. Having said that, gsisql001.gsi.us does seem to resolve in the outside world - so I guess you need to provide more details of your DNS setup.

A quick query of the authoritative name servers for the zone yields mixed results for the host gsisql001.gsi.us (externally).

In terms of your question - yes, your problem certainly appears to be your DNS setup (your different results when pinging internally confirm that).

Not knowing the layout of your internal network resolution, I would suggest some reading on Microsoft AD/DNS practices specifically around using a .local zone (or any non-internet TLD) for internal services. MS has a kb at this link, it is SBS centric but the principles for internal zone management are the same.

5
  • Hi mark. What would you lik eto know about the dns setup? This is a weak area for me as Im a developer not a network admin ...only IT guy here.
    – GabrielVa
    Feb 11, 2012 at 17:48
  • you would need to share the exact topology of your internal and external DNS servers and explain which servers are used for client resolution (and how those servers treat the gsi.us zone). If this is the sort of info you are comfortable sharing, add the details to the question above. Feb 11, 2012 at 17:57
  • Ok... As I said Im a developer so forgive me if Im not up to par here. I have an 08 AD system pretty vanilla with DNS services on it. I setup workstations here with static IP address's and I use the AD server for the primary DNS 192.168.1.5. I also use the 2nd DNS (as told by the network guy that helped me setup our firewall yrs ago) to use 4.2.2.2 to resolve things outside. Never had any issue before bc we only had a file server and we used the IP address for everything. Now that I have SharePoint server up and running (the gsisql001 or 192.168.1.50 box) thats when Ive been having issues...
    – GabrielVa
    Feb 11, 2012 at 18:09
  • However I might have always had them to begin with. Anyway in the gis.us Forward zone I setup a record as shown above. All 15 users appear to have the same issue as far as I can tell. Do I need to add in the gsisql001 as a FQDN?
    – GabrielVa
    Feb 11, 2012 at 18:14
  • I think I might have figured it out. When I removed the 4.2.2.2 @ndary DNS zone it started working once I restarted IE. Im going to test this for a day or so and see if this is the case.
    – GabrielVa
    Feb 11, 2012 at 19:11
0

Trying using the FQDN instead of just the hostname, i.e.

ping gsisql001.yourdomain.local

I would guess that this will work fine, in which case, check the DNS search suffix for your PCs, by looking at the DNS tab of your TCP/IP properties for the network adapter.

1
  • I just tried it and it gave me the same thing as before, the outside IP address. I did it as ping gsisql001.gsi.local
    – GabrielVa
    Feb 11, 2012 at 17:46
-1

I use the AD server for the primary DNS 192.168.1.5. I also use the 2nd DNS (as told by the network guy that helped me setup our firewall yrs ago) to use 4.2.2.2 to resolve things outside.

That network guy didn't have a correct grasp of the DNS. Preferred and alternate servers, in a (Windows NT's) DNS client's configuration settings, are not some form of data merging mechanism. Nor do they represent a priority order, thanks to various bugs and odditied in DNS clients over the years. They must all present the same view of the DNS namespace. This is exactly what happens when they do not.

One should work on the principle that any query can be sent to any of them, varying from moment to moment. MacOS 10 has a way of splitting up queries by which portion of the DNS namespace tree is being asked about. Windows NT does not.

Using external promiscuous proxy DNS servers run by people with whom you have no contractual relationship is a bad idea anyway. You wouldn't use an external proxy HTTP server like that; nor would you route your mail through an external SMP Relay server where you didn't have an agreement with the server owners. You'd be quite rightly thinking how unsafe it would be to hand over the keys to the kingdom like that to a complete stranger against whom one has no redress and who hasn't contractually agreed to even provide you with service in the first place. So don't do it for DNS either.

If you want redundancy, run extra internal DNS servers, configured to replicate your internal data. Even an old 1990s PC sitting unloved in a cupboard has enough horsepower for providing such service. Or you could have a fully-fledged second domain controller (for which you'll want a more recent machine, of course).

Further reading

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .