local domain DNS vs global DNS setup

Question

What I have: all the local users are working through local domain controller set up as a typical environment: Win 2008, MS Exchange, MS DNS, etc. I have a web server connected to the local net. to have this server available from "outside" there is a static route in firewall that forwards all port 80 traffic from external ip to my local webserver. There's a public dns (A) record for xxx.domain.com that points to my external ip. everything works fine here...at least if you're accessing xxx.domain.com from "outside" (not being connected as a local domain user).

what am I trying to do: if local user is trying to open xxx.domain.xom, dns resolves correct public ip, but connection fails. I was trying to add forwards DNS zone into MS DNS server to override xxx.domain.com for local users so it goes directly to local web server.

the problem I'm facing right now: nslookup returns xxx.domain.com.domain.local for xxx.domain.com and valid web server IP address, but ping and connect resolves xxx.domain.com as an external IP. as a result, connection to xxx.domain.com fails.

Question: what am I doing wrong? - why cant local users connect to the server using external IP? - how to setup DNS server to override xxx.domain.com for local users?

Feel free to ask questions if my problems doesn't look clear enough!

Solution 1

The way to do this is simple:

Let's say your external domain name is external.com.

1. you shouldn't need to do a static route to your web server unless its on a different subnet (DMZ for example). This should be a simple port forward on your router. Depending on what you've done with routing, this could have an effect on why clients can't access your web server internally.
2. Setup the zone "external.com" in your internal DNS. There should be an A record that points to your sites internal IP. NOT the external IP
3. If your site has a "www" like www.external.com. Then create a CNAME record of "www" that points to example.com

here is a netgear example of a port forward http://kbserver.netgear.com/kb_web_files/n101145.asp

here is how to create a forward and reverse lookup zone. Also, it shows how to create an A and CNAME record. http://support.microsoft.com/kb/323445

Solution 2

What am I doing wrong?

I count four things, for starters:

1. You are lying to us about your domain names, and then expecting us to be able to diagnose your problems based upon false and blatantly erroneous data.
2. You are using nslookup.
3. You are ignoring the effects of your search path settings in your DNS client.
4. You are abusing local., which is not a domain that you own.

And all this simply because of a lack of hairpin NAT.

Further reading

• Jonathan de Boyne Pollard (2001,2002). Don't obscure your DNS data. Frequently Given Answers.
• Jonathan de Boyne Pollard (2001,2004). nslookup is a badly flawed tool. Don't use it.. Frequently Given Answers.
• Jonathan de Boyne Pollard (2003). You've forgotten to populate your "internal" DNS database with data.. Frequently Given Answers.
• Jonathan de Boyne Pollard (2012). Use domain names that you own and don't abuse domain names that you do not own.. Frequently Given Answers.

Comments

[Gregory MOUSSAT]

Your description is not very clear. You should provide some examples about the ping commands you run, and the results. As for nslookup. And explain which dns entrie you made for internal resolution.

[Alex D]

thanks! This might do the job. Let me try to create and test primary Forward lookup zone... will post my results here!

[Eric C. Singer]

one caveat with the forward lookup zone you should be aware of. From now on, if you add a record externally, you must update it internally as well if you want your clients to resolve it. For example. if you ever do "mail.external.com". When you add that externally, you'll also have to create a mirror record internally as your DNS server will think it owns the zone

[joeqwerty]

+1 for you for the Further Reading articles and -1 to me for using .local on my home network.

[Kyle Smith]

I have to disagree with your points in your first article. Many organizations find the naming and layouts of internal servers are to be protected. Also, when a systems administrator posts technical questions about software or protocols used within their network on a public forum associating that information directly with not only the organization they work for, but potentially the location of the systems, is handing information to potential threats. You don't think would-be attackers read these sites looking for targets?

[JdeBP]

That is bunkum that was debunked a decade ago, M. Smith. It's also debunked in what you just read. You should re-read it until the fundamentals of what DNS does sink in.

[JdeBP]

If you liked that, joeqwerty, you should hit your WWW browser's "Up" button and see all of the other articles.

[Alex D]

thanks. Problem was solved: add domain.com and www.domain.com point to external ip. add remote.domain.com point to 192.168.1.2. in this case local users getting to the real website when they're typing domain.com no matter where the server is and all remote.domain.com requests stays inside the local network going to 192.168.1.2 server

[Eric C. Singer]

don't forget to add a reverse zone as well, just for good measure.

[Ian Murphy]

JdeBP doesn't appear to be able to offer any actual help. 1) theres no good reason to give out any real details. 2) nslookup is fine 3) Use your dns server as a dns server and you have no problem 4) using .local is not abusing anything. Any imagined future problems involved in merging two .local domains together in the future are hardly a good reason to avoid .local.

[Ian Murphy]

If you ever add other records to your public dns then you will not be able to resolve them internally unless you add another record. You can avoid this problem by not adding domain.com and just adding remote.domain.com with a single A record with no name pointing to 192.168.1.2. If you have to post any more questions, just say its sbs and everyone will know what you're doing.

[Alex D]

hmm, sounds even better. will try that. Thank you!

[the-wabbit]

@Ian The good reason to avoid .local is that it is reserved. The use of nslookup has indeed been discouraged for Linux/Unix OSes in favor of dig, but dig is not part of a stock Windows install

[Ian Murphy]

Indeed, you're correct on that point - the draft authors have requested that it be reserved. It seems to be only an experimental draft so far and is less than a year old. I've just been reading a little and the conflict with existing networks seems to be a big issue. I wonder if it isn't doomed to failure from the outset. Makes you wonder why they didn't choose '.mDns'? For the moment not having bonjour working is hardly an issue, unless you want the kids to be able to connect their macbooks to the network and print without bothering you. NetbiosV2==Bonjour?? :-)