Using container IPs directly or setting domain names pointing to container IPs is not something we usually do. You can use port mappings (ports section in compose) and add the domain names to your hosts file pointing to a loopback IP (127.0.0.1 or even 127.0.1.2 or anything you like). Or you use a reverese proxy in front of the containers but you would still need to add the domains to your hosts files the same way.
I also had an image that worked on Linux and automatically modified the hosts file, but I havenāt used it for years so I have no idea if it still works. Probably not.
You never mentioned whether itās about dns resolution on your host or the network, or amongst containers within a container network.
While the last scenario is supported out of the box for user defined networks (like networks created by compose deployments), the first is out of scope of dockers responsibilities.
Usually having to rely on container ips is a sign for something that should be done differently. Even on the docker host, it is not intended to access container ports using the container ip. Thatās what published ports are used for. In container to container communication, the intended solution is to put these containers in a shared network, and use the container name, service name, or network alias (if defined by user).
I have Piholev6 Docker for DNS Resolution with Unbound Docker all in the same Docker Network and all with Static IPs because i need that to communicate between some Containers.
InfluxDB and Telegraf also both in Containers and in the same Container Network as Pihole
All with Bridged Network Mode with static IPS
I cant set the Host IP to Telegraf if it communicates internal to the Container with InfluxDB
In the Telegraf config you have to specific a IP for the InfluxDB to communicate with.
Docker automatically handles internal DNS within Docker networks, Docker services should be available via their compose service name or dedicated container_name. No need for fixed Docker IPs.