Fwd: [Dnsmasq-discuss] backend for dynamic data

Eric S. Johansson esj at harvee.org
Mon Jan 21 17:13:13 GMT 2008

richardvoigt at gmail.com wrote:
> Oops, meant to send to entire list.
> On Jan 14, 2008 5:21 PM, Simon Kelley wrote:

>> Think hard about concurrency issues. When dnsmasq gets a query, it
>> either answers it from the cache (so the transaction doesn't block) or
>> it forwards it upstream (which doesn't block either). Once the query is
>> forwarded, only minimal information is kept about it; just enough to
>> send the eventual reply. In particular, no copy of the query, either in
>> raw packet form, or parsed, is kept.
>> That makes lots of stuff very simple, a single, statically allocated
>> packet buffer and working space, and a  simple table of "forwarding
>> records".
>> Once you start execing programs or using database lookups, then the
>> amount of "stuff" you will need to keep around gets much greater, and if
>> you're to avoid blocking whilst you handle one query all that stuff will
>> have to be dynamically allocated.
>> Take home message: there's lots of code you can re-use, but there's also
>> a lot of stuff not there which you'll need, and the end result will be a
>> very different animal from what you started with.
> If it's possible to levy a requirement that the other program already
> be listening, then it should be possible to use the existing "forward
> upstream" logic.  Maybe a couple changes in order to support
> forwarding to a unix socket or fifo in addition to UDP sockets would
> make life more secure.
> Then it's all a matter of whether the specially handled requests can
> be redirected using the existing matching rules, or some first-chance,
> second-chance scheme is needed.

The forward upstream model only works if one uses the connection like UDP and
the upstream process can handle the request fast enough.  I would argue For
embedding forking logic in the interface to the backend.  I would like there to
be two back ends, one you can link against if you're using something like C or
C++ and another (probably built upon the first) calling Python (given that's a
language I can write using speech recognition and not screw up my voice models
too much).

Yes, I know that forking is not considered a fashionable for servers, but, it is
easy to implement in contrast to threading which is much harder to debug.
Having said that, it's possible to put the forking logic in a separate process
spoken to by UDP but that gets me right back in the problem of building a
small-scale DNS server.  Something I dearly wanted to avoid because I know
people like Simon are much smarter than I am about this kind of thing and I was
hoping to take advantage of their knowledge.  You know, stand on the shoulders
of type of thing.

Speech-recognition in use.  It makes mistakes, I correct some.

More information about the Dnsmasq-discuss mailing list