However, from my point of view this is not a very satisfying, because this means you have to manage some kind of “shadow DNS” inside Cloudflare Zero Trust. Is there any news about this topic?
I think it should possible to delegate entire internal DNS zones to an (internal) upstream DNS server - something like this:
Thanks for pointing me to the article. I tried this out - either I’m doing something wrong or the function is meant for a different scenario.
What I did
UDP proxying enabled
Using QUIC for the tunnel
Relevant local networks routed and working
Created the following policy:
The 10.0.7.0/24 network is one of the networks that can be reached through the tunnel. However, DNS lookup still does not work for *.lan. I assumed Cloudflare would redirect those lookups (through the tunnel) to the upstream DNS server, but maybe that’s not the case?
Edit: I think the issue is this:
These DNS requests will be passed back to other DNS servers configured on existing network interfaces on the device.
So I guess this means, the domains defined in this list will be resolved using a LAN resolver (if there is one), but requests will not be routed to the DNS server through the Cloudflare tunnel. So this will only work on the actual LAN, but not if the user is located somewhere else.
So, unfortunately, this still does not solve the problem.
It should work. Assuming User device is in a subnet (172.16.0.0/24) that isn’t routed through Cloudflare Tunnel and private network “Data Center” (10.0.7.0/24) is.
cloudflared tunnel route ip add 10.0.7.0/24 <tunnel id>
Make sure you set a policy to allow and deny traffic under Gateway>Policies>Network.
Settings>Network>Include IPs and domains
* IP address {10.0.7.0/24}
* Domain *.lan
Settings>Network>Local Domain Fallback lan - 10.0.7.21
If you ping something that is behind the warp tunnel, it should resolve the name, but not respond. If you ping something local (assuming 172.16.0.0/24 from your first post), it should resolve the name and respond to pings because the ICMP traffic is not traversing WARP.
This works, but in my limited testing WARP doesn’t have a way of telling your client devices what DNS servers to use. So if the devices are receiving DNS addresses automatically via DHCP, then DNS request will continue to resolve using the DHCP issued DNS addresses. You would need to manually specify your private DNS servers on your clients, since WARP doesn’t appear to have a way of updating this automatically when enabled.
Someone correct me if I’m wrong please.
For example:
I am unable to use nslookup unless I manually specify DNS addresses on Windows and MacOS, but strangely there appears to be some form of internal DNS resolution without manually specifying DNS if I am using SMB. I can use a FQDN and access my SMB server without manually specifying DNS servers on the client. In any case I’ve needed to manually add a DNS Suffix / search domain to the adapter definitions so I could use hostname only to search.
All domains in that list rely on the local DNS resolver configured for the device on its primary interface or the DNS server specified when you add a new local domain.
As long as your DNS server is part of subnet that is in Warp Routing and you are making a DNS request against that domain, it should pass the DNS request to the relevant DNS server.