On 07/22/2010 02:43 PM, Daniel Stenberg wrote:
> On Mon, 19 Jul 2010, Ben Greear wrote:
>
>> + /* Set the DNS servers for c-ares to use.
>> + * comma separated list of host[:port] entries.
>> + */
>> + CINIT(DNS_SERVERS, OBJECTPOINT, 206),
>
> Some comments:
>
> I'm very curious. What is the specific use-case for this? We're working
> really hard at making the name resolving done resolver-agnostic and here
> you all of a sudden no longer provide the name servers using the generic
> /etc/resolv.conf or similar but instead control them directly within
> libcurl.

We make network testing software. I can currently run dhcp on several
different interfaces and get the IP, mask, gateway, and DNS info. I
want to run a libcurl app on each interface and use potentially unique
DNS. This allows users to connect one interface to one network,
and another to another, and to use the DNS servers that belong to
that particular network.

It might allow a more 'normal' user to test some particular DNS
server w/out mucking with /etc/resolv.conf. This might be particularly
useful for users who do not have root privs.

If users don't set these options, then the default values in /etc/resolv.conf
will be used, of course.

If there are other name resolver backends (aside from c-ares) that
folks want to use in this manner, I guess they'll need to add appropriate
API and then tie in curl near where I did the c-ares hooks).

> Do we really need _three_ options to set outgoing interface for DNS
> queries when we manage with _one_ for the ordinary TCP connection? I
> would much rather have the DNS resolves use the same logic and concept
> as CURLOPT_INTERFACE. Thoughts on that?

First, the TCP connection in curl needs to be updated to take
both interface-name and IP. But, we can do so with one ascii
string and parse it apart. This is on my list of things to do,
and I hope to get a patch posted by next week.

I could do similar with DNS if you want, but it will add more
parsing code to libcurl, which adds bloat and complexity in my
opinion.

Since a user might want to use IPv4 for one DNS server and IPv6 for another,
and do use them round-robin, I think we will still need to provide ipv4 and
ipv6 binding API, not just one API that can take either ipv6 or ipv4.

> In regards to all your suggested options, I miss the docs for them in
> your patch. Unfortunately, I realize adding decent test cases for them
> is very tricky.

I see no way to write useful automated tests for this, but we do
testing on our code that uses this..and it seems to work as
designed. If it doesn't, it's most likely a c-ares bug anyway
since the curl part of this is pretty minimal.

As for docs, I'll post a patch for curl_easy_setopt.3
as soon as we agree on the API.

Thanks,
Ben

-- 
Ben Greear <greearb_at_candelatech.com>
Candela Technologies Inc  http://www.candelatech.com
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html