[Dnsmasq-discuss] Add address file option

[Simon Kelley]

Perette Barella wrote:
> On 2010年03月05日, at 12:16, Jan 'RedBully' Seiffert wrote:
>> And there is always the risk the new dnsmasq will not come up,
>> because you made a silly typo in the config, or something like
>> that. Depending on how fast you can rectify the situation, now you
>> have a real window where you are without name resolution. If one
>> can avoid that, he will avoid that.
> 
> A partial/compromise solution: what about a command-line option to
> "Read the options and configuration file, report any errors, and
> exit," like the -n option to the shells.  I realize it doesn't
> address 100% of everything desired, but it does allow you to check
> the config file syntax before proceeding to a restart.  And it's a
> lot easier to get the error messages from the command line, rather
> than having to dig them up in a log file when dnsmasq is spawned from
> init, inetd, or launchd. (Or is there already such an option?)


It exists:

srk at spike:~/dnsmasq-2.53/dnsmasq-2.53$ src/dnsmasq --test
dnsmasq: syntax check OK.


You're right that it doesn't check everything, but it does catch foolish
errors in the configuration file. A failure after this check completes
would be for things like "permission denied" or "address in use" on
sockets, which couldn't be checked until after the "point of no return"
even with a very sophisticated config-file-reload function: in the end
there will always be a set of replacement configuration files which will
leave you dead in the water with no service until you fix them.

Maybe the initscript should do this check by default for the "restart"
command?

> 
> As far as coming up with a way to handle restarting dnsmasq without
> hiccups... I tend to agree with Brad... if you need 100% uptime, a
> better solution is a secondary DNS server rather than complexifying
> the heck out of dnsmasq.

I'm still confused as to how anyone notices a restart anyway. DNS almost
always runs over UDP which is unreliable and therefore resolvers
time-out and retry. Restarting dnsmasq will lose queries that are in
flight (ie, the query has been forwarded but the reply hasn't come back
yet) and any queries which arrive whilst there is no dnsmasq process
listening on port 53. Both of these losses are indistinguishable from a
dropped UDP packet, and will just cause the resolver to retry.

DHCP is even more resistant, a DHCP client will retry for minutes or
hours before complaining.

The only way I can see that restarting dnsmasq will "lose connections"
is for DNS over TCP (very rare) or TFTP.

It _might_ be possible to make an orderly transfer of the port 53
listening socket from old to new dnsmasq instances, and even do the same
with in-flight queries, but I can't see the point at the moment.

Cheers,

Simon.