mdns resolution fails while VPN is up

[BurntBrunch]

mdns resolution fails while VPN is up

[Rhys-T]

Same here. Not just browsers either - AVNC and Termux also can't resolve .local domains while personalDNSfilter is running.

Note that a number of the default lists¹ have 127.0.0.1 local entries near the top, which seems to cause .local domains to get blocked², but even with !*.local added to 'additional hosts' and the domains being logged in green (or personalDNSfilter in the 'paused' state), the domains still don't resolve correctly - only stopping the pseudo-VPN entirely works. (I get a slightly different error from AVNC after allowing the domain - presumably that's because it changes from getting a wrong/fake IP address to getting an NXDOMAIN error.)

Edit: personalDNSfilter doesn't seem to be blocking mDNS traffic at the network level - I can do dig @224.0.0.251 -p5353 (something).local in Termux and get the correct response back. It just seems to be preventing the normal resolver from trying to do mDNS.

Footnotes

1. Edit: Actually, only one that's enabled by default - the main StevenBlack one. But there are several of the disabled ones that have it too. ↩

2. Is it intentional that entries in hostfile-style lists are treated as applying to subdomains too, even though that's not how they would actually be treated in /etc/hosts? ↩

[Rhys-T]

Looks like this is a side effect of pretending to be a VPN. From the official Android DNS resolver docs:

VPN and mobile data connections are excluded from .local resolution.

For this to work, personalDNSfilter may need to handle mDNS itself when running as a pseudo-VPN.

[Rhys-T]

I see a few options to make .local domains work with pDNSf in pseudo-VPN mode:

• mDNS allows 'legacy unicast' lookups¹, where you basically just do a normal DNS-over-UDP request, but send it to 224.0.0.251 or FF02::FB on port 5353 - and don't use 5353 as the source port. This might let you just use the existing DNS code with a different upstream 'server' in DNSCommunicator.requestDNS. However:
  • If the device has both IPv4 and IPv6, it would probably have to query both addresses, which might complicate things.
  • When you do this kind of request, the spec says that the responses will have their time-to-live limited to 10 seconds, because 'full' mDNS needs various extensions to the protocol to keep caches in sync between all the machines on the network.
  • Possible issues with Unicode domain names - see below.
• Alternately, you could implement the full version of mDNS - or find a Java library that already does - and integrate it into either DNSResolver.resolveLocal or DNSCommunicator.requestDNS when the hostname ends in .local (or a few other domains, see below).
  • (Android has had a separate API² for Zeroconf since before its regular DNS resolver started supporting mDNS/.local, but it seems to be limited to looking up services using DNS-SD over mDNS, and can't do domain name lookups using just mDNS by itself.)

Additional notes:

• mDNS specifies that non-ASCII domain names get encoded as UTF-8, rather than the Punycode encoding used in 'normal' DNS (on the grounds that mDNS didn't have any old, buggy implementations that it needed to stay compatible with). pDNSf might need to translate Punycode to UTF-8 for non-ASCII .local names to work. I'm not sure how common those are. (I also can't tell if that change still applies when doing 'legacy unicast' requests.)
• Besides .local, there are a handful of reverse-DNS domain trees that are also supposed to get sent over mDNS. (I don't know how often these will actually come up, but…)
  • .254.169.in-addr.arpa.
  • .8.e.f.ip6.arpa.
  • .9.e.f.ip6.arpa.
  • .a.e.f.ip6.arpa.
  • .b.e.f.ip6.arpa.

Footnotes

1. See sections 5.1 and 6.7 of RFC 6762. ↩

2. Network Service Discovery ↩