Dns issues

[lixo12nitb]

Hello all!

I’m having an issue with name resolution on my environment on my Android phone. I'm using private resources, and the newt VPN is working, and I can access all resources by IP, but when I use the local dns, it fails to resolve.

In the Pangolin app on Android, I have my two internal DNS servers configured as the primary and secondary upstream DNS. I’ve tried enabling/disabling DNS override and DNS tunnel, as well as enabling both at the same time, but I still can’t resolve names.

Something I find strange, though I’m not sure if it’s expected, is that in the JSON file inside the app’s status, the dns_servers field always shows 100.96.128.1. I don’t know if this is something I misconfigured or a bug in the app.

I’m using the latest versions available as of today.

Any help would be appreciated!
Regards

[FouMiiii]

Your two internal DNS servers are behind the VPN, but Tailscale (Pangolin) forwards DNS requests through its own resolver by default.

If the Tailscale resolver doesn’t know about your private domain, queries will fail.

Android may also ignore custom DNS in VPN apps if “DNS override” isn’t working correctly.

[AntonVonDelta]

This smells like Ai-generated. Tailscale has nothing to do with a default Pangolin installation

[marcolino7]

Hi,
same issue here. I have internal network with newt client and I use internal DNS to resolve internal clients.
With Windows App, all works fine. I selected "Enable Aliases" and when I connect my windows PC with pangolin to my private network, I can resolve internal name, ping DNS server and nslookup addresses using internal DNS.

Same configuration on my android phone does not work:

I setup like this, but when I enable VPN, DNS resolution donot work at all. All site are not resolved, internal and public.

What I miss?

Thanks

[FouMiiii]

Add your internal domain in the Tailscale Admin Console under DNS → Split DNS → Add Domain, then reconnect your Android client.

for example:
Domain: internal(your internal domain)
DNS: 192.168.1.9, 192.168.1.2 (your dns servers)

We need to do this because:
Your Android client sees server1.internal and tries to resolve it using a public DNS server → fails, because that name only exists internally no external dns server will know it hence why you need to tell it where it is.

With Split-DNS configured, Tailscale knows: “anything ending with .internal goes to these internal DNS servers” → your device can correctly reach internal resources.

[marcolino7]

Ok, I’ll try that as soon as I can. However, it still doesn’t explain why it works on my laptop.

I’ll let you know whether it worked or not.

I use Genemini 3 Pro to help me troubleshoot. As I undesrstood, in windows is more simple to have DNS setup by Pangolin client, and DNS are set directly on network stack and used natively. On Anrdoid you cannot set DNS directly, Pangolin client pass DNS to use to system that check if that the request coming back from same address where it was sent. Using host network mode, the reply address is the same where you sent the request, and in this case it worked for me.

Please try and let me know.

Marco

[HPTBrolin]

Unfortunately, the issue remains even with network_mode: host in the docker compose file. Another weird thing is that my Android device is showing up with the IP address 100.90.128.0 and I can’t change it.

I’m not sure if the issue might actually be this.

[HPTBrolin]

Just a quick update: the IP address isn’t the issue. I installed Pangolin on another Android device and the behavior was exactly the same.

[AntonVonDelta]

Add your internal domain in the Tailscale Admin Console under DNS → Split DNS → Add Domain, then reconnect your Android client.

for example: Domain: internal(your internal domain) DNS: 192.168.1.9, 192.168.1.2 (your dns servers)

We need to do this because: Your Android client sees server1.internal and tries to resolve it using a public DNS server → fails, because that name only exists internally no external dns server will know it hence why you need to tell it where it is.

With Split-DNS configured, Tailscale knows: “anything ending with .internal goes to these internal DNS servers” → your device can correctly reach internal resources.

ChatGPT? Do you know what you are talking about? Tailscale is not Pangolin.

[oschwartz10612]

Aliases work by overriding the DNS of your computer running the client so that all DNS requests are sent to the Pangolin client for resolution. The dns server on your computer is typically 100.96.128.1 (the first address inside of your utility subnet on the org) when connected to the tunnel which will forward request to an upstream server.

[cat-inGlasses]

Box o also have the same issue.
I enabled DNS over tunel, and it does not work on my iOS app, while same settings on my Mac work perfectly fine.

I can't resolve my internal address on mobile phone, while can on my Mac...

[svandive]

I’m so confused, why do replies keep mentioning Tailscale? What does that have to do with anything?

[AntonVonDelta]

Most likely generated by ChatGPT, bots

[GisaLab]

I have exactly the same problem. I've added a private resource, allowed all TCP and UDP ports in the DNS restrictions, and then in the Pangolin Android client, I have:
Enable aliases (DNS replacement): Enabled
DNS via tunnel: enabled

If I test a ping from my phone to the DNS, it responds correctly, but it's as if Android isn't recognizing the Pangolin DNS configuration.

[anytimesoon]

Im also facing a similar issue. Not sure if its related, but when I connect, I also lose internet access

[jordanhandy]

I had this same issue on my Android device.
I have a selfhosted AdGuard Home instance that uses 3 Technitium DNS servers as upstreams. Here is what I did, I hope it helps someone else.

1. Create a Private resource in Pangolin, with the destination being your DNS server IP address
2. On Android, install the Pangolin app, authenticate to your site, and in Settings, enable DNS Override and DNS over Tunnel, and set your private DNS server as the primary and secondary (optional) upstream DNS servers
3. Enable Pangolin Tunnel, attempt to resolve a DNS query you know that only your internal DNS can resolve
4. At this point, when I connect to the tunnel, the Pangolin app says "Connecting..." then "Connected".. I thought this was normal
   This is where it failed for me.. and nothing I do could seem to fix. Nothing internal was resolving

To fix:
Reboot your Android device. When rebooted, and you immediately try to connect to Pangolin tunnel, the app text changed slightly to "Connecting...", "Registering.....", "Connected"

Once this had completed, DNS resolution worked without issue. When in doubt, always power cycle the device. lol

[GisaLab]

I had already done this configuration and it didn't work at all, but I updated pangolin to version 1.19.4 and newt, magically it works without me having changed anything in the settings.

[anytimesoon]

Same for me

[DarinDev1000]

I have the same issue on Android

[CFinne01]

Same issue here, but on macOS (client v0.9.0, confirmed latest per the app's own update check) against a self-hosted Enterprise Edition server (v1.20.0). A few concrete data points that might help narrow this down:

• WireGuard tunnel is fully up (utun interface active, routes present for the private-resource subnet).
• Querying Pangolin's own DNS server directly (dig @100.96.128.1 <hostname>) returns the correct private tunnel IP for every private resource — including plain aliases (e.g. nas.internal) and Private HTTP/HTTPS resources on our own public domain (e.g. heimdall.echolimits.com → 100.96.128.10). So server-side resolution is 100% correct.
• The problem is entirely client-side: scutil --dns on macOS shows 100.96.128.1 registered as a Supplemental resolver with no domain scope. Without a domain match, macOS's resolver never actually routes ordinary hostname lookups to it — confirmed by testing a name with zero competing public DNS (nas.internal), which returned nothing at all through normal system resolution, even though the same name resolves correctly when queried directly against 100.96.128.1.
• Reproduces with "Enable Aliases (DNS Override)" on, tunnel fully connected, after a fresh client restart.

Might help whoever looks at this: the fix likely needs the macOS client to register 100.96.128.1 as a domain-scoped resolver (via SystemConfiguration/NEDNSSettingsManager matchDomains) instead of an unscoped Supplemental one, so macOS actually consults it for the relevant hostnames rather than silently ignoring it.