Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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!

share|improve this question
    
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. –  Gregory MOUSSAT Jan 28 '12 at 19:45

3 Answers 3

up vote 0 down vote accepted

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

share|improve this answer
    
thanks! This might do the job. Let me try to create and test primary Forward lookup zone... will post my results here! –  Alex D Jan 28 '12 at 21:39
    
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 –  Eric C. Singer Jan 28 '12 at 21:47
    
Thanks, Eric! that's exactly what I need! I was afraid of adding another primary forward lookup zone. that was the problem. –  Alex D Jan 29 '12 at 20:41
    
don't forget to add a reverse zone as well, just for good measure. –  Eric C. Singer Jan 29 '12 at 23:17

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

share|improve this answer
    
+1 for you for the Further Reading articles and -1 to me for using .local on my home network. –  joeqwerty Jan 28 '12 at 23:16
    
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? –  Kyle Smith Jan 29 '12 at 16:32
1  
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 Jan 29 '12 at 19:27
    
If you liked that, joeqwerty, you should hit your WWW browser's "Up" button and see all of the other articles. –  JdeBP Jan 29 '12 at 19:28
    
thanks for the links, but you're wrong about 1,3 and 4! doesn't answer my question! –  Alex D Jan 29 '12 at 20:40

You have one simple problem as far as I can see. When your users connect to www.mydomain.com they are connecting to your public IP.

Solution: create a domain in your local dns server for www.mydomain.com. Not mydomain.com with an A record of www, but a domain called www.mydomain.com. Inside that create a default A record with no name which contains the internal ip of your server (lets say 192.168.1.10).

What will happen is that internal users will look up www.mydomain.com, it will resolve to 192.168.1.10.

All other addresses in mydomain.com will be sent to the public dns server and be resolved normally.

Ian

share|improve this answer
    
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 –  Alex D Jan 29 '12 at 23:15
    
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. –  Ian Murphy Jan 30 '12 at 9:38
    
hmm, sounds even better. will try that. Thank you! –  Alex D Jan 30 '12 at 12:44

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.