[] Android 10 has broken DNS

REPRODUCIBILITY (% or how often): 100%
BUILD ID = OS VERSION (Settings > About product):
HARDWARE (XA2, Xperia 10…): XA2 (H3113)
REGRESSION: (compared to previous public release: Yes, No, ?): Yes


Disclaimer: Having freshly flashed the device I was still in the process of downloading the latest update while starting to configure all the bits and pieces, which means I cannot 100% rule out the possibility until the factory reset is done, but I’m pretty sure.

I’m running NAT64&DNS64 locally, with no IPv4, only IPv6 with public IPs assigned through SLAAC.
Everything does seem to handle that pretty well, however as soon as I had upgraded to 4.1, most notably with the Android 10 support, my Android apps were not able to resolve DNS anymore.
Example from Aptoide:

05-19 21:05:38.539  1246  1408 W System.err: cm.aptoide.pt.dataprovider.exception.NoNetworkConnectionException: java.net.UnknownHostException: Unable to resolve host "ws75.aptoide.com": No address associated with hostname

Poking more deeply into the inner workings (by the way, nice job with that LXC, looks very neat) it seems that Android at some point after 8.0 may have removed the known cogs for tweaking DNS settings (i.e. net.dns1 and friends are all gone apparently).
The native Android settings yield the DNS settings to be set to “automatic” by default, and setting them to “off” or e.g. “dns64.dns.google” or “dns64.cloudflare-dns.com” does not seem to fix anything.
There isn’t much to go by other than anything and everything within that LXC container reporting resolution failures, despite having a public IPv6 address with no firewall whatsoever (i.e. that thing is public in the internet and can reach everything it wants, as long as it’s either IPv6, or it resolves via DNS64 to a 64:ff9b::/96 IP) and pings work just fine.
More probing sadly didn’t yield anything more, and I can’t seem to get anything useful out of tcpdump either, it almost looks like the container bluntly decided to not even try resolving any DNS record at all.


A working NAT64/DNS64 setup I guess?
Seeing as IPv6-only networks are getting more traction in mobile environments this might be more common, although in my case it’s WiFi.
Switching over to a regular NAT4 WiFi fixes everything.


  1. factory reset your device to 4.0 & setup NAT64&DNS64 WiFi
  2. connect to WiFi
  3. use Android apps (notice: they work)
  4. update to 4.1
  5. use Android apps (notice: they can’t resolve DNS names)


Android Apps can resolve hostnames and do so via DNS64 (i.e. the way SailfishOS itself does).


Android Apps cannot resolve any hostnames.


Things I tried:

  • setting the net.dns properties at runtime
  • adding the net.dns properties to /usr/sbin/alien-generate-properties.sh
  • rebooting, restarting Android Support, reinstalling Android support, etc.
  • setting the “Private DNS” option to Cloudflare’s DNS64, or Google’s DNS64, or turning off the Private DNS entirely (i.e. not “automatic”)
  • running tcpdump, but it seems the container doesn’t do anything at all while the resolution errors are being logged (sudo lxc-attach -n aliendalvik -- tcpdump -Ani any 'not port 22')

Factory reset yielded that it works at 4.0, but not at 4.1, with no changes other than the upgrade.

1 Like

It seems like Android apps are no longer using /etc/resolv.conf for DNS resolving under Kvarken (
Does anyone know from where they take their configuration now?

To me it seems (though I can’t say for sure) that Android only respects the interface specific configuration (i.e. the extended WiFi dialogue) and the global DNS settings.
The latter doesn’t seem to do anything for me, while the former isn’t applicable with aliendalvik (since the interface is passed through to the container directly so there is no network setup running on Android side).

Those are a lot of guesses and assumptions of course.
However if this holds true then I suspect that the Android “way to go” of using the global DNS settings (which do DoT rather than regular DNS) does not work because the initial resolution of those DNS servers fail due to the absence of an interface-specific DNS setting.

Regardless of any suspicions of mine it very likely needs an upstream (aliendalvik) fix which reimplements/overrides the Android internal DNS resolver with one that specifically queries the resolver running on localhost, which might work without too much trouble if the network namespace is not fully separated.

Just want to add that this also affects VPN configurations that push a DNS server address to the client (Sailfish).

All of my Android apps can’t resolve hostnames behind my VPN server anymore starting from Sailfish 4.1, since my own DNS server isn’t queried by them. Native apps resolve them fine though.

1 Like