We try to use mDNS to support additional domain names on the device. For example if we have a device with a hostname of HOST we would like to expose ui-host.local and login-host.local as mDNS names.
We created/used a docker container that adjusts the avahi daemon to know about these new names. When logged in to the device (ssh) we can PING these endpoints properly, so mDNS works. mDNS is from RFC6762 and broadcasts the names on port 5353
Now wondering if we can get these broadcasts over the balena tunnel as well?
We are simply using balena tunnel for systems not reachable on the local network (for example, because the device is in the office and a developer works from home).
balena tunnel -p 8080:8080 443:3001 etc
and use localhost:3001 to reach out to the HTTPS port of the device.
Now we would like to also be able to ping on the created mDNS names and tried to expose the port like this:
balena tunnel -p 8080:8080 443:3001 5353:5353
however we do not see the “PING ui-host.local” resulting in a reply. Should broadcasts from avahi be ported differently or are we missing something obvious?
mDNS works by your device sending a multicast packet on port 5353 asking for the device with the name foo.local to identify itself (hence the name, multicast DNS). This is different to your device sending a packet to every distinct IP address it can see on port 5353, and multicast packets won’t get sent over the Balena tunnel.
You could, in theory, write some software that listens for those packets and forwards them over the Balena tunnel, but for development purposes its probably easier to just add ui-host.local and login-host.local to /etc/hosts.
Yes - indeed using the additional names on the developers machine in the /etc/hosts works for us, there are some people in the office outside of the dev-team that “just want to test how it works” and do not want to be bothered changing their /etc/hosts file.
Understood: so the broadcasts will not be able to be tunneled - Also I do understand that we could try to setup a proxy on the host that picks up the traffic on that specific port 5353, sends it out over another port that will be tunneled, and then run something else on the client machine that communicates it back to port 5353 - but that would be nasty workaround.
Would there be another option?
We thought of the office LAN to be configured to always forward “ui-” and “login-*” prefixes in case the machine is getting an IP address from the office network anyways.