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?
-
1Use 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.– TimMar 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.– TommiieMar 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.– ThorinMar 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.– ThorinMar 29, 2019 at 17:43
-
@Thorin: I fail to understand which setup you're trying to achieve here.– TommiieApr 2, 2019 at 13:21
|
Show 1 more comment
1 Answer
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 user192.168.8.9
in thenetstat
as192.168.8.1
- but the same server will see
192.168.1.3
as192.168.1.3
- and it will see Internet user
9.9.9.9
as9.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)