Hi Willy,
On 13-05-2012 11:00, Willy Tarreau wrote:
Hi Aleks,
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
>libc's
>since the process is supposed to be chrooted, so you'll need to
>implement
>an autonomous resolver with an IP address to be used as the DNS
>server.
>And if you do this, please make it so that the resolver can be
>different
>for different backends.
and of course unbloccking ;-)
Of course :-)
Curl use
http://c-ares.haxx.se/
maybe this is also a possible lib for you.
Maybe, that's a good point.
With a little more searching I have found this.
https://github.com/spc476/SPCDNS
What I have seen from the README, it could use the haproxy pools ;-)
### cite
...
A NOTE ABOUT MEMORY ALLOCATIONS
The dns_encode() and dns_decode() functions do no memory allocation;
they
use what you give them. In the case of dns_decode(), the block of
memory
passed in must be big enough to handle not only the dns_query_t
structure,
but multiple dns_answer_t structures and text strings representing
domain
names and the occasional string or two (say, for TXT or NAPTR records).
In
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
8K
buffer).
...
###
But it does NOT send the DNS request.
This must be done from the calling lib.
### cite
...
SPCDNS is *NOT* a general purpose DNS resolving library (although code
is
provided to make DNS queries, it is simple and fairly stupid). This
code
exists to provide a simple method of encoding and decoding the DNS
protocol
and thus the network side of things is a bit lacking I'll admit. But
that
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
http://25thandclement.com/~william/projects/dns.c.html
###
...
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
plugins
is that you can't change the interface anymore, so that must be done
at
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 ;-)
Cheers
Aleks
