0

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?

Improve this question
6
  • 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, 2019 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, 2019 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, 2019 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, 2019 at 17:43
  • @Thorin: I fail to understand which setup you're trying to achieve here.
    – Tommiie
    Apr 2, 2019 at 13:21

1 Answer 1

Reset to default
1

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.

Pros:

  • 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

Cons:

  • 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 192.168.8.8 will see user 192.168.8.9 in the netstat as 192.168.8.1
    • but the same server will see 192.168.1.3 as 192.168.1.3
    • and it will see Internet user 9.9.9.9 as 9.9.9.9
    • 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)
Improve this answer

You must log in to answer this question.

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