DNS conflicts with same-named containers on different projects

#1

I was wondering what happens with the DNS *.lxd names for containers with the same name on two different projects. I found out that they don’t work as expected.

If I have containers a, b on the default project and a, c on project p1, then a.lxd resolves to the same IP on both projects (from containers b and c), which means that one of the two “a” containers is not addressable via its .lxd name.

Is there a solution to this?

I would expect that a.lxd should resolve to the ip of (default)a from container (default)b and to the ip of (p1)a from container (p1)c. Alternately, perhaps there could be DNS names that include the project, e.g. p1_a.lxd vs a.lxd.

#2

Yes this is a known limitation currently, as the network has a top-level domain “.lxd” and the host names given out do not include the project.

@stgraber have you got any recommendations for this?

#3

Maybe we can add a DNS mode where we encode the project as sub-domain.
But ultimately this can only work when LXD is fully in charge of DNS records.
When we just rely on dnsmasq to generate them from DHCP requests, there’s nothing we can do.

#4

Yes so it could only work when dns.mode=managed (the default if not specified).

#5

Have added to ideas board.

#6

Is it possible to work around this by specifying a project with a separate network, or do all LXD networks share the same dhcp server? Can there be a separate top-level domain per project?

#7

You could setup a separate LXD managed bridge network for each project and then update the project’s default profile NIC device to use it. You wouldn’t be able to resolve domains between projects though, although not sure if that is a requirement for you.