Cloudflare Zero Trust: Internal DNS

I would like to pick up the issue of Internal DNS, which was discussed here some time ago. The proposed solution was this:

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:

Cloudflare added support for this recently.

1 Like

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 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.

Do you have split tunnels configured (Settings>Network)?

I have mine set to include IPs and Domains

My split tunneling is set to exclude, and I removed my local range from the default exclude list.

The thing is: I want the local range to be routed through Cloudflare to be able to access LAN resources while away.

The blue box just under the link I sent:

You’ll need to set your split tunneling to include.

@vnges I understand what you mean and you’re right. Local lookups (green path) do work w/ split tunneling set up as described.

I guess Local Domain Fallback might not be able to do what I want it to do. What I’m looking for is the red path:

It should work. Assuming User device is in a subnet ( that isn’t routed through Cloudflare Tunnel and private network “Data Center” ( is.

Cloudflared config.yaml

   enabled: true

Warp Routing

cloudflared tunnel route ip add <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 {}
* Domain *.lan

Settings>Network>Local Domain Fallback
lan -

If you ping something that is behind the warp tunnel, it should resolve the name, but not respond. If you ping something local (assuming 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.

It’s a little bit of a frustrating experience.

This should be exactly what local domain fallback does.

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.