Fwd: [Dnsmasq-discuss] backend for dynamic data
richardvoigt at gmail.com
richardvoigt at gmail.com
Mon Jan 21 14:54:34 GMT 2008
Oops, meant to send to entire list.
---------- Forwarded message ----------
From: richardvoigt at gmail.com <richardvoigt at gmail.com>
Date: Jan 21, 2008 2:53 PM
Subject: Re: [Dnsmasq-discuss] backend for dynamic data
To: Simon Kelley
On Jan 14, 2008 5:21 PM, Simon Kelley wrote:
> Eric S. Johansson wrote:
> > let me state up front that I'm not in a position to dive into this
> > seriously yet but I have an distributed application were I am
> > considering using an rbl like DNS lookup. Obviously, I could write my
> > own UDP client/server but I would prefer to recycle existing tools
> > whenever possible. I have come to count on dnsmasq as one of my "highly
> > trusted" DNS tools and I'm interested to see if it's reasonably
> > practical to stretch it just a little bit further to use either a
> > program or a DBM file to translate requests into responses.
> 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
> 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.
> > Thanks for supplying a tool I don't have to worry about.
> > ---eric
> > PS, I'm currently using dnsmasq to handle DNS and DHCP for vmware
> > servers. It's really nice to be able to control IP addresses in one
> > spot (on the host machine) and make everything a nicely self-contained
> > unit. when I have the cycles, I'm planning on experimenting with
> > dnsmasq to also allocate IP addresses for the virtual network feature of
> > VM Ware. Their DHCP server is really primitive and not at all connected
> > to the DNS tool.
> Sounds good. There's a RedHat effort called libvirt(?) which might be
> similar, I think.
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss at lists.thekelleys.org.uk
More information about the Dnsmasq-discuss