An interesting idea.
A few problems come to mind immediately.
1) There isn't just one config file; there can be more than one
--conf-file command line argument, and config files can include further
files in the same way.
2) Some of the operating configuration can come from the command line:
anything that can go in the config file can go on the command line too.
3) Some parts of the configuration can be replaced whilst dnsmasq in
running, so the hash is no guarantee of what's actually in effect.
4) There are situations where it's useful to run more than one dnsmasq
process.
If this is a real problems, it would be nice to fix it, but I'm not sure
this exact method is the correct one.
Simon.
On 25/09/2026 23:27, Stefan Schmors via Dnsmasq-discuss wrote:
Hi Simon,
I’d like to propose a very small, optional feature for dnsmasq that
would help administrators verify that a running instance has
successfully loaded the intended configuration.
Problem
When dnsmasq is started (or reloaded) via systemd or other service
managers, there is currently no reliable way to determine which
configuration file the running process actually parsed. This becomes
relevant in situations where:
a reload fails silently,
a restart races with an auto‑restart from the service manager,
a process continues running with an outdated configuration,
or multiple units compete to start dnsmasq.
In all these cases, administrators have no introspection mechanism to
confirm that the running daemon corresponds to the current configuration
file on disk.
Proposal: Optional config‑hashing
Upon successful startup (and optionally upon successful reload), dnsmasq
could:
compute a hash (e.g. SHA‑256) of the configuration file(s) it actually
loaded,
write this hash to a small file, e.g.:
Code
/run/dnsmasq/config.hash
This file would contain only the hash, nothing else.
Administrators or service managers could then compare:
the hash of /etc/dnsmasq.conf
with the hash stored in /run/dnsmasq/config.hash
to verify that the running instance corresponds to the intended
configuration.
Why this fits dnsmasq’s philosophy
It is optional.
It adds no runtime overhead.
It introduces no new dependencies.
It does not require DBus, systemd, or any external mechanism.
It does not expose internal state or add introspection APIs.
It keeps dnsmasq small and simple.
It solves a real operational problem with minimal code.
Use cases
verifying that a reload actually took effect
detecting configuration drift
detecting race conditions with service managers
confirming that a running instance is using the expected configuration
simplifying debugging in PXE/TFTP/DHCP setups
I believe this would be a very small patch with significant practical
value for administrators.
Thanks for considering it.
And also thanks for telling me why I would be wrong (If You got the
time). I am not very experienced in proposing stuff to big organisations
Best regards,
Stefan
_______________________________________________
Dnsmasq-discuss mailing list
[email protected]
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
