-
-
Notifications
You must be signed in to change notification settings - Fork 0
Home
Run two or more dnsmasq nodes as one resolver and manage them from a single place. Every node holds the identical configuration except for its own listen address; dcm edits that configuration in the browser, shows exactly what differs between the nodes, and syncs and restarts them. The frontend is plain PHP with no database, and everything that needs root goes through one CLI backend (dcm-cli) over sudo.
Tip
TL;DR — Free port 53 on every node, point dnsmasq at a drop-in directory with a hosts directory in it, then install dcm-cli and the web frontend on one node and run sudo dcm-cli sync. That first sync carries the launch config, the drop-ins, the host files, the node list and the binary itself to all the others. From then on you work in the UI, and the bell tells you when a node needs a sync or a restart. Full walkthrough: Installation.
Important
Early development. dcm is under active, heavy development and far from feature-complete — see Roadmap for what is deliberately not there yet. Two things to know before you deploy it: authentication is not implemented (inc/auth.php is a no-op stub, so keep the UI node off the internet and behind Basic auth, a VPN or a trusted network), and every node must run the same dnsmasq version, because one configuration goes to all of them and dnsmasq refuses to start on an option it does not know.
The setting — every page explains dcm against one and the same fictional setup: two nodes, four VMs on a travelling laptop, five networks and one domain. Network lists it with all the names and addresses, so no other page has to invent its own placeholders.
Setting it up — Installation is the whole sequence: freeing port 53 from systemd-resolved, the dnsmasq base config, dcm-cli and the node list, the sudoers drop-in, the PHP-FPM override that ProtectSystem=full makes necessary, the vhost, root SSH between the nodes, and the first sync. It ends with the table of every path dcm touches and who owns it.
Filling it with records — Hosts files covers the three host files: local for the LAN (including the node entries that generate each listen.conf), vms with its one-click subnet relocation, and isolated for the phone-home endpoints that get pinned to 127.0.0.1 and ::1.
Changing dnsmasq options — Directive catalog is the canonical list of what the Configuration page exposes: type, default, what ON writes, what an explicit OFF writes, and every conflict the UI enforces live.
Understanding what you see — The web interface walks the nine pages and explains the bell: sync pending, restart pending, version mismatch, feature mismatch, unknown directive.
dcm replicates one configuration to every node, so the cluster has to agree on what that configuration may contain. A directive only the newer build understands does not fail when you save it — it takes the older node down on its next restart, after a sync. dcm therefore asks every node for its version, its compile time options and the options its binary accepts, and offers only what the weakest node understands; anything outside that floor is rendered read-only with the reason. Keep the nodes on the same dnsmasq version and the whole class of problem disappears. The mechanics are in Architecture, under Cluster build detection.
| Page | What it answers |
|---|---|
| Architecture | The design: how paths are derived from dnsmasq's own config, the sync flow, cluster build detection, the SSE live log, the analytics pipeline, and how the privilege chain from the browser to root is built |
| CLI reference | Every dcm-cli command, what it touches, and which part of the UI calls it |
| Encrypted upstream DNS | DoH / DoT / DoQ and DNSSEC for a dcm cluster: what each option buys, which tool does what, and where validation belongs. A planning note, not a feature yet |
| Roadmap | What is planned, what is deferred, and what Phase 1 deliberately leaves out |
Something broken, something unclear, or an idea? Open an issue. If it is about a node refusing to start or drifting out of sync, the output of sudo dcm-cli health and sudo dcm-cli diff answers most of the questions up front.
© 2026 [ernolf] Raphael Gradenwitz · GPL-3.0-or-later · Report an issue
Getting started
Managing the cluster
Under the hood
What comes next