Resolving Domains Locally?

I have installed Cloudflare Tunnel and enabled warp. I use a local DNS server to resolve services internally via a domain name and can’t access these via IP.

Can I setup so that my domain name resolves internally via my DNS server?

Apparently, according to this post… I can use the override policies? Does anyone know how to do this or if these will even work?

eg: all traffic to * should resolve via

We recently released a feature where users can add their local DNS server as a fallback domain to resolve requests internally. This should be much easier to maintain than individual override policies.

Let us know if this guide is helpful.

1 Like

Thanks for your reply!

I have followed the guide and unfortunately still unable to get it to work.

Before making any settings, I ran an nslookup and see that the domain is resolving to the dns server of what I assume is Cloudflare via My DNS server is located at

Here’s what I did:

  1. Enabled UDP support in team settings (both TCP and UDP are checked)
  2. Created a local domain fallback entry
    Lets say for the domain ‘’ and I put the IP as my DNS server (*
  3. I am running 2021.12.4 running via docker and have enabled the quic flag. Here is my docker compose for ref
    image: cloudflare/cloudflared:2021.12.4
    container_name: cloudflared
    restart: unless-stopped
      - no-new-privileges:true
      - traefik
      - /home/admin/cloudflared:/etc/cloudflared/
    command: 'tunnel --protocol quic --config /etc/cloudflared/config.yml run'
      - traefik.enable=false

and my config file

tunnel: main-tunnel
credentials-file: /etc/cloudflared/RETRACTED UUID.json

  - hostname: RETRACTED DOMAIN
    service: RETRACTED IP
  - service: http_status:404

  enabled: true

(*) To confirm, I can access my domain etc fine on my local network as it is resolving via my local DNS server

I can confirm that these instructions worked for me, but there’s a typo in the Update cloudflared section. Where it’s says protocol: QUIC it should say protocol: quic. My cloudflared refused to start at first, because it didn’t recognize quic in upper-case letters in my configuration file.



Have you tried the Beta WARP client?


Thanks for pointing that out - I didn’t notice that!

I just installed the BETA and it is not working. I did also enable to DNS queries logs within the WARP app and when I do try and request my internal domain, it doesn’t even register to the logs.

Do you know how I can triage my issue to help point in the right direction of where things are going wrong?

Running a nslookup when connected to WARP, I get “connection timed out; no servers could be reached”. When I disconnect, it rolves successfully to my local DNS servers.

When connected to WRAP, I have also tried running the test command dig @MY_IP -p 53 AAAA MY_DOMAIN and get the same “connection timed out; no servers could be reached”. When I disconnect, I get:

; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30961
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0


;; Query time: 28 msec
;; WHEN: Tue Jan 04 18:34:39 GMT 2022
;; MSG SIZE  rcvd: 36

I wish I could give you a definite triaging process - but for me I focused on the client side because I did not see any egress DNS traffic from cloudflared to the internal DNS servers. (Since I’m still testing this implementation for a client, my cloudflared ingress traffic was very quiet - so even when I was executing dig, I was not seeing any traffic hit my cloudflared host at all - Wireshark is a beautiful thing)

The following exhaustive list (in no particular order) got it working:

  • WARP reinstall (Ensured the BETA install)
  • Full logout and back in to the WARP client (This client is using Azure IdP to auth, I needed to clear my Windows Credentials to fully logout - real pain but finally a use for Edge browser :stuck_out_tongue: )
  • Ensure you are using the Gateway Mode in WARP client as well as check the connection under General - it needs to be WARP+ (more on this below - re: cdn-cgi/trace comments)
  • Full Windows stack reset (netsh winsock reset and netsh int ip reset)
  • ipconfig /flushdns (I suspect this is not needed since dig does not care about windows DNS caching)
  • Reboot my testing VM exactly 2349304 times. /s

Then, check the following on cloudflared:

  • Ensure your cloudflared is running quic protocol as per above
  • Ensure your cloudflared tunnel is routing the correct subnets
  • Ensure your cloudflared is up to date. (command: cloudflared version)
  • Ensure your tunnel is active (under Access → Tunnels)
  • Ensure your cloudflared can egress traffic to the internet (to Cloudflare network) via UDP on port 7844
  • Double check that your cloudflared is not further restricted by some OS level firewall that you had no idea was loaded and wasted 3 hours of your time ahem ubuntu ufw

On to the Cloudflare configuration, make sure you have the following:

  • Under Settings → Network → Split Tunnels add your IP range AND the DNS domain you are trying to query
  • Under Settings → Network → Proxy - make sure UDP is checked
  • Under Settings → Network → Local Domain Fallback add the domain AND make sure you have the correct IP address of your DNS server entered
  • Also check there is no overlapping entry on the Local Domain Fallback list that corresponds with your domain (I.E., if your domain is contoso.local, REMOVE the .local entry and leave only your domain)
  • Under Gateway → Policies → Network - Ensure you have a policy to permit the traffic. Since Cloudflare’s Gateway Policies are default allow, I had previously setup a pseudo deny entry as the last rule in the chain. Because of this I needed to add an Allow policy specifically for my DNS traffic further up the chain. You might not need todo this.
  • Further cursing at your equipment for about 3 1/2 minutes.

Note: I read on one of these community threads that you should check the results of cdn-cgi/trace URL to see if “warp” and “gateway” = on. I can tell you first hand that this is not accurate as both of my values are currently off when accessing this URL via a browser on the same test VM as the warp client - yet the internal DNS and other tunneled services are working fine. I have yet to figure out how to properly test the cdn-cgi/trace URL via the warp client but I believe is as simple as interpreting the “Connection” output under General in the client. (Please someone at Cloudflare confirm if this is indeed true…)

Also, don’t loose your mind trying DNS resolution on mobile devices - afaik UDP is not available on mobile devices (Android/IOS) at the time of this post.

Hope this helps

Thanks a million for that write up. It has definitely helped and really is appreciated!

So, I just set everything back to defaults in my account. Starting fresh…

Local Resolution:

  1. The first thing I did reinstall the (BETA) application and logged in. I then immediately tried my local domain and it did not load (as expected).
  2. I then added the Local Domain Fallback domain without the local DNS server ( and it now loads my domain when connected to the local network and using WARP. I also tried adding WITH the DNS server IP and it also works.

However, I’d like to connect to my network while away. My expectation is that if I am on another network, I can connect to Warp and still be able to access my local services which resolve via my local domain.

Remote Resolution:
1.I connect to another network and tried to load the domain = it does not load
2. I try a local IP address and does not load. However, Split Tunnels is setup to Exclude IPs and domains and when removing = it resolves.
3. So the issue is, my local IPs resolve fine but just not my local domains (which I can access all fine when connected to my network).

I again followed this guide @abe suggested but still unable to resolve the domain while connected to other networks and connected to WARP.
I can confirm that as per the guide, I have:

  • Both TCP and UDP Proxies Enabled
  • Created a local domain fallback entry ( with the DNS server at
  • Split Tunnels are configured correctly to be able to access the remainder of my network
  • Cloudflared is up-to-date (running version 2021.12.4 via docker).
  • –-protocol quic is enabled
  • Cloudflared is connected
  • I do not have any policies in the Gateway Network policies section
  • My Private DNS resolver (AdGuard Home) is available locally via on port 53

A few debugging tips:

  • let’s start without local domain fallback, and ask dig to resolve to your specific ip: dig @ —> does it work?
  • if not, let’s try that with tcp: dig @ +tcp —> does it work?
  • in either case, if you go to Teams dashboard, Gateway Audit Logs, Network, did any of those generate an entry there (for either UDP or TCP)?

So, after a long couple of days - I think i have found a solution that seems to work across my devices.

I created a single DNS rule with regex to match all subdomains .*(my_domain)[.]com$ and override it to resolve on my local DNS server located at Now when connected, all subdomains are resolving fine and I do not have to play around with local domain fallback’s etc.

Is there a downside or am I missing anything? From my initial testing, it seems to be working fine.

I’ve spent quite a while trying to figure out what the problem is with resolving local domain names by reverting to a local DNS server, and want to share the solution to ease the pain:

Assuming that you have already completed the installation and configuration steps (if not, see here), there are still a few things that need to be done to make everything work smoothly.

Local Cloudflared Server configuration:

  1. To use the Local Domain Fallback it is important that quic is activated. To do so you have to edit your config.yml:
    tunnel: yourTunnel
    credentials-file: /root/.cloudflared/XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX.json
    protocol: quic
      enabled: true

    What took me quite a while is that protocol: quic line has to be exactly in the position shown above. I assume that otherwise it is simply skipped by the parser and quic remains inactive.

    NOTE: For testing and to make sure that quic is correctly applied, you can specify it as a command line starting parameter by(!!Be careful, this is NOT taken over when you install the cloudflared daemon!!):

    cloudflared tunnel run --protocol quic yourTunnel

Cloudflare Web configuration:

  1. Navigate in the Teams web gui to Teams->Settings->Network
  2. It is important that:
    • Proxy: is enabled with both TCP and UDP checked
    • TLS decryption: is enabled with cipher checked (no glue why)
    • Split Tunnels: Equally configured as here (either you remove your local IP-range from the list if Exclude IPs and domains is activated, or you add it to the list if Include IPs and domains is activated)
    • Local Domain Fallback: Add your local domain and IP of the DNS server.

Cloudflare Warp Client:

  1. Download the newest version (it has to be the beta) here and install it.
  2. Flow the configuration steps as provided here.
  3. Connect to your Cloudflare account.
    Now you should be able to access all your local web-sites just by relying on the local DNS names. NOTES:
    • For testing (Windows) you can use:
      nslookup <DomainName>

      which should be able to resolve your DNS names.

    • You cannot ping your servers by their Domain Names (I guess that the cloudflare firewall is restricting ping requests)
    • This has only been tested successfully on Windows Warp Client and isn’t working with the current Android Warp Client version (no support for UDP). But I guess it should also work with the Mac and Linux Warp Clients.
    • If you have issues, make sure that the cloudflared Deamon is still running


    Switch back to your Local Cloudflare Server and install cloudflared to run at startup:
sudo cloudflared service install
    NOTE: You can check the config file in /etc/cloudflared/config.yml to make sure that the option protocol: quic is still activated and at the right place.


I’m having this same issue. IP based TCP traffic works, but anything UDP (like DNS resolution) seems to just fail.

Do the mobile OS versions of the app not support UDP yet?

Hmm it appears that UDP works with the macOS beta client, but not the macOS release client or the iOS release client. Proxy UDP is not listed as a beta feature in the Zero Trust console though so I find that kind of confusing.

Yes, I’m having the same problem. I can’t get my internal domains to resolve on iOS. But it’s working for me in the current macOS client release.

Thank goodness! I have been struggling with Cloudflare support since the middle of March on this exact issue - iOS domain fallback.

They seemed to be suggesting it should work but I have tried so many different options without any luck.

Got it working on macOS but no joy on iOS

Well that’s disappointing since I intend to access systems via iOS devices over WARP tunneling quite frequently.

Would love for an official word on the support of UDP/DNS on the app for iOS to save me chasing support every couple of days.

@nuno.diegues if you see this would love to know your take

Hi all - thanks for the patience here.

We did discover that local domain fallback on iOS/Android was not working the same as it does on Windows/Mac/Linux - DNS traffic was always being sent outside of the tunnel on mobile devices.

This has been worked on with a high priority, and the fix should be available in the next iOS release. The version will be 6.11 or higher.

Apologies again for the delay in updating everyone on this.

Thank you! I will keep an eye out for this fix and test it the moment I see 6.11 or higher come out.

Hello @louis.cassidy is there a planned release date or ETA for 6.11 on iOS?