Community Solution

ZimaOS Port 53 for Pi-hole: What Changed and What to Check

Early ZimaOS used port 53 for ZVM dnsmasq; IceWhale later announced that v1.2.3 released the port for Pi-hole-like applications.

You should not need to disable ZimaOS core services to free DNS port 53 on a current system. The original 2024 conflict came from ZVM's dnsmasq occupying port 53, but IceWhale announced that ZimaOS 1.2.3 released that port specifically to improve compatibility with Pi-hole-like applications.

Current ZimaOS documentation now includes a dedicated Pi-hole deployment guide, which confirms that DNS-server workloads are an intended use case. If port 53 is busy today, identify the current listener instead of applying old commands that stop ZVM or system networking.

Why Port 53 Was Busy on Early ZimaOS

In the original thread, ZVM used dnsmasq and bound the DNS port. That prevented Pi-hole or AdGuard Home from publishing their own DNS service on the host address.

IceWhale first acknowledged the compatibility issue, then announced that version 1.2.3 released port 53. That makes the old workaround discussion historical rather than current setup guidance.

Check What Is Using Port 53 Now

If a current Pi-hole or AdGuard container reports “address already in use,” identify the listener:

ss -lntup | grep ':53 '

Also check UDP listeners, because DNS commonly uses both UDP and TCP. Do not stop a process until you know what it is and whether ZimaOS or another container depends on it.

Install Pi-hole Through the Current App Workflow

The current ZimaOS Pi-hole guide walks through installing Pi-hole from the App Store and configuring router or client DNS.

That is a much better starting point than old instructions designed around the pre-1.2.3 port conflict.

If Port 53 Is Occupied by Another Docker App

Two DNS servers cannot both bind the same host IP and port. Check installed apps for another Pi-hole, AdGuard Home, DNS proxy, or custom Compose stack. Stop or reconfigure the duplicate service rather than changing ZimaOS internals.

Do You Need macvlan or a Separate IP?

Not just to work around the historical ZVM conflict. A macvlan or dedicated LAN IP can still be useful when you intentionally want a DNS appliance to behave like a separate network device, but it adds routing and management complexity.

Use it for a networking design reason—such as DHCP service or service isolation—not because a 2024 post said port 53 was permanently reserved.

Configure Your Router or Clients After Pi-hole Starts

A running Pi-hole container does nothing for the rest of the network until clients use it as DNS. Set the router's LAN DNS address to the ZimaOS/Pi-hole address, or configure DNS on selected devices for testing.

The official guide also recommends flushing client DNS cache during troubleshooting. This separates “Pi-hole is running” from “clients are actually querying it.”

What Not to Do

  • Do not permanently disable ZVM services based on the old 2024 port conflict.
  • Do not kill dnsmasq by process name without confirming the current listener.
  • Do not expose DNS port 53 to the public internet unless you deliberately run a secured public resolver.
  • Do not run Pi-hole and AdGuard Home on the same host IP:53 simultaneously.

The service troubleshooting guide is useful when a service conflict is only one part of a wider system issue.

FAQ

Does ZVM still permanently reserve port 53?

The original conflict was changed in ZimaOS 1.2.3, and current official documentation supports Pi-hole deployment. Verify the actual listener on your current release.

Can Pi-hole and AdGuard Home both use port 53?

Not on the same IP address and protocol at the same time. Give them separate addresses or run only one DNS service.

Should I use macvlan for Pi-hole?

Only if you want Pi-hole to have its own LAN identity or need a specific network design. It is not required merely to undo the historical ZVM conflict.

How do I know whether clients are using Pi-hole?

Check the client's DNS configuration and Pi-hole query log. A running container alone does not prove your router or devices are sending it DNS queries.