Tired of manually updating DNS records for your Docker Compose services? Explore practical, real-world alternatives to complex tools like external-dns for simple and effective container name resolution.

Docker Compose and the Missing DNS Link: A Guide for the Rest of Us

I remember one frantic Tuesday, around 2 AM, when our monitoring lit up like a Christmas tree. A critical internal tool was down. After an hour of panicked debugging, we found the culprit: a developer, trying to connect a new service to our staging database container, had hardcoded its IP address in a config file. The container had restarted, gotten a new IP from Docker, and boom—everything fell apart. “I couldn’t get `prod-db-01.internal.techresolve.io` to resolve from my service!” he said. That night, I swore I’d find a better way for our non-Kubernetes setups. This problem—bridging the gap between Docker’s internal network and the outside world’s DNS—is a classic headache.

So, What’s Actually Going On?

When you run `docker compose up`, Docker creates a beautiful, isolated little world. Inside this network, your containers can talk to each other using their service names. Your `api` service can find your `database` service just by calling `database`. It’s magic.

The problem is, this magic is contained within that Docker network. Your host machine, your colleague’s laptop, or another server on the same LAN has no idea that `database` is a valid hostname. It tries to look it up using your standard DNS server (like your router or your company’s DNS), which promptly says, “I’ve never heard of this ‘database’ you speak of.”

In the Kubernetes world, you’d solve this with a tool like `external-dns`, which watches for new services and automatically creates DNS records in Route 53, Cloudflare, etc. But for a simple Docker Compose setup on a single VM, that’s like using a sledgehammer to hang a picture frame. We need something simpler.

Solution 1: The “Good Enough for Dev” Fix (extra_hosts)

Let’s be honest, sometimes you just need something to work right now on your local machine or a single, stable server. This is the quick and dirty fix. The `extra_hosts` directive in your `docker-compose.yml` file basically injects entries into the container’s internal `/etc/hosts` file.

Imagine you have a legacy application running outside of Docker on the host machine at `192.168.1.50`, and your new container needs to talk to it via a friendly name.

version: '3.8'
services:
  my_new_app:
    image: my-app:latest
    extra_hosts:
      - "legacy-api.internal:192.168.1.50"
      - "prod-db-01:10.0.5.123"

When to use this:

• When you need a container to resolve a host that has a static, predictable IP.
• For local development to mock external services.
• When you have a very small number of entries to manage.

Why it’s not a permanent solution: This is manual and brittle. If the IP address of `prod-db-01` changes, you have to manually update this file and redeploy. It doesn’t scale and is a recipe for another 2 AM outage.

Solution 2: The “Proper, but Simple” Fix (A Local DNS Resolver)

This is my go-to for small-to-medium-sized projects running on a dedicated VM. We run a lightweight DNS server *as a container* and tell our other containers to use it for DNS resolution. My favorite for this is `dnsmasq`, but `CoreDNS` is also a fantastic option.

The idea is to create a simple DNS config that maps the names you want to the host’s Docker IP. We can use a special hostname, `host.docker.internal`, which Docker conveniently resolves to the host machine’s IP address from within the container.

Here’s a conceptual `docker-compose.yml` using a hypothetical `dnsmasq` image:

version: '3.8'
services:
  local-dns:
    image: my-custom-dnsmasq:latest # You'd build an image with your config
    ports:
      - "53:53/udp" # Expose DNS port to the host network
    restart: always

  my_app:
    image: my-app:latest
    depends_on:
      - local-dns
    # This is the magic! Tell this service to use our custom DNS.
    dns:
      - 127.0.0.1 

  another_app:
    image: another-app:latest
    depends_on:
      - local-dns
    dns:
      - 127.0.0.1

Your `dnsmasq.conf` file (which you would `COPY` into your `my-custom-dnsmasq` image) would contain the magic line:

# Resolve any request for *.docker.host to the IP of the host machine
address=/.docker.host/172.17.0.1 
# Note: You might need to make this IP dynamic or use a startup script
# to get the host's Docker bridge IP reliably.

Pro Tip: Setting this up takes a bit more effort initially, but it pays off massively. You create a single source of truth for your local network DNS. Any service needing to talk to a container just needs to be pointed at the Docker host’s IP for DNS, and it can resolve `my-app.docker.host` correctly.

Solution 3: The “Service Discovery” Fix (Using a Reverse Proxy)

If you’re already using a reverse proxy like Traefik or Caddy, you’re 90% of the way there. These tools are much more than simple proxies; they’re service discovery powerhouses. They can listen directly to the Docker socket for events (like a container starting or stopping) and update their own routing and DNS configuration automatically.

This is the most robust and “cloud-native” way to do it without jumping into the Kubernetes ecosystem.

Here’s how it works with Traefik. You don’t manage DNS records. You just add labels to your services, and Traefik does the rest.

version: '3.8'
services:
  traefik:
    image: traefik:v2.5
    command:
      - "--api.insecure=true"
      - "--providers.docker=true"
      - "--providers.docker.exposedbydefault=false"
      - "--entrypoints.web.address=:80"
    ports:
      - "80:80"
      - "8080:8080" # For the dashboard
    volumes:
      - "/var/run/docker.sock:/var/run/docker.sock"
    restart: always

  whoami:
    image: "traefik/whoami"
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.whoami.rule=Host(`whoami.docker.localhost`)"
      - "traefik.http.routers.whoami.entrypoints=web"

Now, if you configure your machine to resolve `*.docker.localhost` to `127.0.0.1` (by editing your own `/etc/hosts` file), any request to `http://whoami.docker.localhost` will be automatically routed by Traefik to the correct container. It’s fully dynamic. A new service just needs the right labels to get a DNS-routable name.

Warning: Exposing the Docker socket (`/var/run/docker.sock`) to a container is powerful, but it’s a security risk. It effectively gives that container root access to the host. Only do this with trusted images like Traefik and on systems where you control the entire environment.

Which One Is Right for You?

To wrap it up, here’s my quick-and-dirty decision tree:

Don’t over-engineer it. The goal is to solve the problem reliably. Start with the simplest solution that fits your needs and scale up when the complexity demands it. Now go fix that hardcoded IP before you get a 2 AM page.

Darian Vance

Lead Cloud Architect & DevOps Strategist

With over 12 years in system architecture and automation, Darian specializes in simplifying complex cloud infrastructures. An advocate for open-source solutions, he founded TechResolve to provide engineers with actionable, battle-tested troubleshooting guides and robust software alternatives.

🤖 Frequently Asked Questions