I see no negative effect, but only the log-entry for a request is not marked as whitelisted, but this behaviour could be obtained via software (matching).
Is it possible, that whitelisting will be reflected via the stated server command, or is there any reason why this should not be implemented?
--servers-file=<file>
A special case of --conf-file which differs in two respects. Firstly, only --server and --rev-server are allowed in the configuration file included. Secondly, the file is re-read and the configuration therein is updated when dnsmasq receives SIGHUP.
the new conf file should be placed in this parameter to enable dnsmasq to be updated via receiving SIGHUP instead of the service neeed to be restarted.
as quick implemention... just copy modify the blacklist webinterface import and set it up for whitelists too so as users can set a whitelist up in webinterface and it is parsed by push a update button
from my point all features that are implemented for blacklists, could be migrated for the whitelisting context.
as permises (for the gravity script to condense all lists) we have:
hostlist entries should be created last (as dnsmasq gives them top prio for requests)
wildcarded whitelist (super)-domain should drive the removal of contradicting host entries (plain blacklist (sub)-domains)
dnsmasq uses the most specific adress/server entry to decide "routing" of domain-queries: this seems to be a sufficient rule to create reasonable wildcard statements for both, blacklist and whitelist.
i hope to here feedback of the creator of the gravity engine to this statements...
maybe i am missing an important point.
