We have an DNS zone, example.com, that is split-horizon (internal vs. public). So for example the internal zone has private IP addresses for app.example.com and the public zone has public IP addresses for the same name app.example.com. We've recently switched public DNS to Cloudflare and I would like to start using them as a CDN/proxy, however I need to roll these changes through QA team before going to production. We need to be able to hit the public IPs of app.example.com while being inside the office and using the internal version of DNS zone. This DNS sends people to internal IPs so they wouldn't be able to test Cloudflare. Modifying the clients' HOSTS file would work but this would be a pain to do, I can't update the internal DNS with public IP addresses. Wondering if anyone can think of any other options?

  • 1
    Use a VPN from inside the company to test as if you're external. Or test from home. Or have a computer set up so it's on the internet, outside your firewall, rather than on your LAN. – Tim Mar 29 at 8:25
  • Can you explain how you want to use them as a CDN/proxy? I don't really associate either of these two terms with your described DNS challenge. – Tommiie Mar 29 at 8:39
  • Using Cloudflare as a DNS provider will offer a number of features such as caching, DDoS protection, etc. Take a look at their site. – Thorin Mar 29 at 17:42
  • Tim, I think that is the way we are going to have to go. Probably will have the support department do testing externally next week and report any issues. – Thorin Mar 29 at 17:43
  • @Thorin: I fail to understand which setup you're trying to achieve here. – Tommiie Apr 2 at 13:21

This answer addresses one possible option, admittedly a controversial one.

Get out of that split-horizon DNS idea (1) while you still can and (2) while you temporarily have a "business" argument for it. The unclear DNS configuration will bite you more and more as your organization grows, but the more it is coupled with your environment the harder is to get out of it.

Use IP layer to solve a problem of IP layer.


  • less confusion for human users
  • one DNS name resolves identically, wherever client resides in the network
  • easy to merge foreign networks with their own DNS zones
  • when you need performance, you use app.in.example.com and you know it resolves to a private IP


  • you will meet "hairpin NAT" situations - google it
  • routers will pass twice more packets (for hairpin NAT situations)
  • microseconds more latency (for hairpin NAT situations)
  • your DNAT-from-public server will see his own subnet under anonymized source IP for hairpin situations
    • this is because you set up SNAT to his whole IP subnet
    • for example server will see user in the netstat as
    • but the same server will see as
    • and it will see Internet user as
    • it is easily fixed as DNAT-from-public server is usually a reverse proxy and can be easily put in a separate subnet away from users (in other words: the revproxies are usually in DMZ)

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.