Our build server is hosted in our office, but is accessible from the outside via build.mydomain.com. I have a dns entry on rackspace that points to the office firewall which in turn forwards :80 requests to the internal webserver.

This works great from outside the office. I just go to http://build.mydomain.com and it works. However internally (I'm guesssing becuase of a loopback issue??) I can't use the dns name I have to use the local syntax http://buildserver to get to it. Is there a way to resolve this without having to edit the host file on every machine at the office?


Split Horizon DNS

Either ask Rackspace if they can configure it (I don't know if they support it). Or run your own internal DNS server with the proper configurations.

  • So if I setup a DNS server do I point my internal gateway to use it as the primary DNS server? Will it look there first for resolution then externally if it's not found? – Micah Nov 19 '10 at 15:34
  • You would setup the internal DNS server, then change your DHCP server to point to the DNS server. There's no configuration at the Gateway (unless it's also the DHCP server). – Chris S Nov 19 '10 at 15:36
  • My gateway is the DHCP server. I setup the DNS server. Created a foward lookup zone for mydomain.com. Added an A record that points to the internal IP. Now what. What DNS server do I point the DNS server to? My external DNS? Do I change the DHCP server to point only to my new DNS Server? – Micah Nov 19 '10 at 15:57
  • 1
    You have to setup all records for mydomain.com that you want to be accessible from inside your location (like www or whatever else people might go to). Then modify your DHCP server to either point only to your internal DNS server (likely the best idea) or to point to your internal DNS server first and some external one secondarily ( is a free DNS server, there are others too). – Chris S Nov 19 '10 at 16:20
  • DNS is roundrobin in most cases.. Dont choose an external DNS as your secondary ( otherwise your resolution will be slow ) Your internal should resolve internally, and if it cant - look external.. – Arenstar Nov 20 '10 at 5:09

If you don't want to do the split DNS (which is easier) then your other option is configuring same-network DNAT on the "office firewall."



I would guess you are having problems with the NATing on your firewall machine. You definitely CAN make it so that internal machines that hit the firewall public IP get the same results as external hosts. However, to achieve this you will need to "double NAT" the connections. You need to make sure that both the source and destination gets re-written.

I'd guess that right now you are only doing the DNAT, so your packets get forwarded on to the destination machine, but the source address is still your LAN address. So the destination server tries to reply directly to the source, but it replies with it's IP address and the source machine rejects it because it expect it to come from the firewall public IP.

For these sorts of problems I will use tcpdump to track it down. For example, on the destination host I would run:

tcpdump -lni eth0 port 80

Then try making a connection from an internal machine to the "build.example.com" name. What you SHOULD see is the source address is the firewall internal IP address, and the destination IP obviously will be the internal IP on the destination machine. If you don't see any packets related to this traffic, your DNAT isn't working on the firewall. If the source address is the IP on the source machine it means that you are not doing SNATing on the packets. Probably because you are only NATing traffic when it leaves the firewall via your upstream link.

If the tcpdump on the destination machine doesn't help, you can try doing a tcpdump on the firewall. There are several different tcpdumps I typically do:

tcpdump -lni any port 80

This will show port 80 traffic on any interface. So for NATing, you will typically see the incoming packet without any translation, and then you will also see that packet after the results of any NAT. However, this tcpdump will only show HTTP (port 80) traffic. What you WON'T see is ICMP traffic like firewall REJECT rules or if nothing is listening on the port...

tcpdump -lni any host $SOURCE_HOST_IP

This one will show anything to/from the source host, so you will see ICMP messages which may be useful. However, this will ignore the NATed packets.

tcpdump -lni any host $DESTINATION_HOST_IP

This will show packets going to the destination machine, or coming from it. These should list the destination host IP and the firewall IP that is in the same network as the destination host. If it isn't, the NAT rules need to be looked at.

DNS views can be used as well, but that can be annoying to set up and maintain as well. But it does have the benefit that traffic will go directly to the destination host rather than having to hit the firewall.

My recommendation would be to make it so the internal hosts can reach the external IP, but it really depends on your exact needs.

The first will show packets going to


i would simply use tinydns dnscache.. its a great little dns server/cache..

Its easy to setup and install... i just set it up on a development network a few days ago...

Hope this helps :D


Do you have local DNS Server? If you are using local DNS Server and each machine in your network using it for resolving DNS Query. You can Create forward look up and Add A Record. If you are using Windows 2008, you can do Conditional Forwarding as well. You can also achieve this if you have small amount of users editing their host file and add entry of build.domain.com to your local IP address.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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