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

Reply via email to