On 13-05-2012 11:00, Willy Tarreau wrote:
On Sun, May 13, 2012 at 09:43:40AM +0200, Aleksandar Lazic wrote:
>Be careful, if you want to implement a resolver, you can't use the
>since the process is supposed to be chrooted, so you'll need to
>an autonomous resolver with an IP address to be used as the DNS
>And if you do this, please make it so that the resolver can be
>for different backends.
and of course unbloccking ;-)
Of course :-)
maybe this is also a possible lib for you.
Maybe, that's a good point.
With a little more searching I have found this.
What I have seen from the README, it could use the haproxy pools ;-)
A NOTE ABOUT MEMORY ALLOCATIONS
The dns_encode() and dns_decode() functions do no memory allocation;
use what you give them. In the case of dns_decode(), the block of
passed in must be big enough to handle not only the dns_query_t
but multiple dns_answer_t structures and text strings representing
names and the occasional string or two (say, for TXT or NAPTR records).
testing, I've found that 4K for decoding appears to be enough memory to
handle DNS requests made via UDP (although the test.c program uses an
But it does NOT send the DNS request.
This must be done from the calling lib.
SPCDNS is *NOT* a general purpose DNS resolving library (although code
provided to make DNS queries, it is simple and fairly stupid). This
exists to provide a simple method of encoding and decoding the DNS
and thus the network side of things is a bit lacking I'll admit. But
is beyond what I wanted for this project anyway.
Which could be good from haproxy point of view ;-).
On this site there is also a link to
A non-blocking DNS resolver library in a single .c file. Supports both
stub and recursive modes.
I don't know which is the 'best' for haproxy?!
How far is the plugin interface?
Still not there, but quite frankly last week when working on SSL, we
noticed that the code becomes very modular and that we're starting to
see some interfaces appear at various points. The problem with
is that you can't change the interface anymore, so that must be done
the end of the development stage for modules which will be developped
for the stable version.
You are right, still stay tuned to plugin framework ;-)