Domain names not published on local network

[Nic0w]

Describe the bug

Containers appear to be correctly discovered but domain names are not published on the local network.
Domain name resolution only works on localhost.

To Reproduce

Steps to reproduce the behavior:

Install ldddns, deploy container, ssh to another machine and try to ping container.local

Expected behavior

I expect domains to be published on the local network.

Desktop (please complete the following information):

• OS: Raspbian
• Version: Bookworm - Linux 6.6.74+rpt-rpi-2712 aarch64
• Docker version: 20.10.24+dfsg1

Additional context

I run docker on a Raspberry Pi 5 with avahi-daemon already working.
Manually publishing a service from the same Raspberry Pi works :
avahi-publish -a -R foo.local 172.17.0.2

foo.local can then be pinged from other machines.

[arnested]

Domain names are only meant to be published on your own machine. Hence the "local" in the name.

By default Docker containers are also just accessible from your host machine, right?

Are you able to ping the container from the other machine using the containers IP address?

If, yes, how did you achieve that?

This has been asked before (#237) so I'm trying to figure out if we can support this in some way.

[Nic0w]

Hi,

Accessing docker containers from outside the host machine is pretty straightforward; 2 methods I can think of :

• adding a static route on your home router so that machines on your LAN can reach the internal docker network
• port forwarding (NAT) on the host machine (it seems docker already kinda does that ?)

Agreed, both methods are outside the scope of ldddns, but

1. If ldddns would broadcast domains on the LAN, which avahi-daemon is clearly able to do,
2. combining that with the first method
3. could allow one to reach its containers from all other mdns-able LAN machines.

that would be a nice plus for people with homelabs, I guess =)

[arnested]

Thank you for the follow-up, @Nic0w! It's really helpful.

What we currently broadcast is the IP address of the container.

Currently, we only broadcast it on the local machine. Unconditionally broadcasting it on the network is not a viable solution. I would rather not broadcast a domain name that cannot be accessed and which might conflict with other hosts broadcasting the same name. The use case I developed the tool for is running websites in Docker for development purposes, and one of my coworkers might be working on the same project and therefore broadcast the same domain name.

So we should only broadcast on the local network if the container is accessible from the network.

If you use the approach with the static route, it would work if we broadcast the container's IP address on the local network (conflicts with other hosts aside). But detecting that a static route exists isn't something we can determine from inspecting the container (which is how we get the ip address and the hostname now). We might be able to figure it out by inspecting the host machine's routing configuration, but I'm not compelled to go down this route (pun intended).

The port forwarding approach has different shortcomings (in my opinion). In this case, it's not the container's IP address that we need to broadcast but the host machine's IP address. So we need to figure out the host machines' IP address, and we could be exposing on several interfaces: Wi-Fi, cable… (and totally unrelated, I dislike the port mapping and one of ten reasons for writing in ldddns in the first place was to avoid looking up ugly port numbers like 32842 and just use port 80 as the gods intended 😄)

Some level of manual configuration could be possible, e.g., putting a label on containers that need to be broadcast to the local network. That would potentially be doable for the static route approach. For the port forwarding approach, we would still need to figure out the right host machine IP address(es) to broadcast (and making them configurable as well would more or less be just as cumbersome as running avahi-publish yourself).

So there appears to be numerous things to consider (also more than I originally anticipated). I'm reluctant to add too much complexity to support this use case (“do one thing and do it well”).

But please comment with your thoughts and ideas. If we can find a simple(r) solution to this, I'm game.

[Nic0w]

Hi @arnested,

I thought not broadcasting on the LAN was a bug, not a feature. Hence this issue.
I realize now I didn't understand the use case ldddns was built for.

Thanks for taking the time to explain.

I feel like the simplest option would be to pass a parameter, env variable, or label to ldddns to enable broadcasting on the LAN.

I'm not sure how the underlying Avahi API works but I feel like an env variable with the interface's name to broadcast on would be nice. If the variable were to be absent, ldddns would default to the current behavior, ie broadcast on localhost.

Now wether, to broadcast the interface's IP address or the container's IP address, I don't know. I guess both could work. Could be a choice left to the user as well. Another env variable ?

I feel like the burden of knowing about possible addressing conflicts or how to configure a static route should not be on ldddns but on the user enabling the feature/administering the LAN. That would keep things simple.