franck
e45560f763
zeroconf represents a TXT attribute with no "=" (a bare boolean flag, valid per RFC 6763 §6.4) or an empty value as properties[key] = None. Reconstructing the TXT record blindly did b"%s=%s" % (key, None), which raises TypeError since bytes %-formatting rejects None. The exception propagated out of the deferToThread call and Twisted answered with SERVFAIL instead of the TXT record, silently breaking resolution for any service whose TXT record includes a bare key (e.g. some _rfb._tcp/screen-sharing advertisements). Found by diagnosing a real screen-sharing "impossible de resoudre" failure over a WireGuard-tunneled deployment: dig showed SRV resolving fine but TXT returning SERVFAIL for the same instance, which is why dns-sd -L (needs both) never completed even after flushing the client-side mDNSResponder cache.
This is a Discovery Proxy for Multicast DNS-Based Service Discovery, written in pure Python. It makes use of zeroconf to obtain mDNS advertisements on the local network and Twisted to re-publish them as a unicast DNS service.
Both IPv4 and IPv6 are supported on the mDNS side. For IPv6, only Unique Local Addresses (ULA, fc00::/7) are published in AAAA records: link-local addresses aren't usable by unicast DNS clients (DNS has no way to express the required zone index), and globally routable addresses are filtered out so that only internal ULA addresses are advertised.
This kind of proxy is specified by RFC 8766. I did not actually follow the standard in implementing it, which means that it doesn't abide by many of the finer details. Nevertheless, it works fine with clients like macOS 10.15 and iOS 13. Any violations of the standard are to be considered bugs and should be fixed over time.
Other implementations of discovery proxies are ohybridproxy and included with mDNSResponder. Since the former only runs on OpenWRT and mDNSResponder is not readily available on Linux, I decided to put together my own implementation in Python. Its dependencies are pure Python, so it should be possible to run it pretty much anywhere.
To use the discovery proxy, run it while specifying a domain to use and a port number to listen on:
python3 proxy.py home.arpa 35353
Then, delegate that domain to the machine the proxy is running on (192.0.2.2 in the example below) and advertise it by adding the necessary records to your network's DNS search domain (example.com in the example below). If you are using dnsmasq, this can be done using
server=/home.arpa/192.0.2.2#35353
ptr-record=b._dns-sd._udp.example.com,home.arpa
ptr-record=lb._dns-sd._udp.example.com,home.arpa
ptr-record=db._dns-sd._udp.example.com,home.arpa
To check whether it is working, you can try some of the following queries (assuming your computer is named yourcomputer and advertises an SSH service):
dig yourcomputer.home.arpa
dig yourcomputer.home.arpa aaaa
dig _ssh._tcp.home.arpa ptr
dig yourcomputer._ssh._tcp.home.arpa srv