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

[Simon Kelley]

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