[Dnsmasq-discuss] Proposal: Optional config‑hashing for runtime verification of loaded configuration

[Stefan Schmors]

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
-- 
Stefan Schmors
Lehrer-Löhlein-Weg 6
91336 Heroldsbach
====================
09190-2151010