First off, thanks for the response, much appreciated!

On Wed, Aug 19, 2009 at 10:00 AM, Daniel Stenberg <daniel_at_haxx.se> wrote:

> On Wed, 19 Aug 2009, Tom Van de Putte wrote:
>
> It hangs on curl_multi_select() because it can't resolve the hostname.
>>
>
> Note that this function is not libcurl's, it's only provided by the
> PHP/CURL exension and is some kind of wrapper on top of select().
>

In fact it runs curl_multi_fdset() and then returns the output of select().

>
> However the CLI of curl works perfectly so I checked the configs (the
>> development server is a plain (arch)linux - apache - php installation) but
>> they seem clean. If I comment out the direction to our own dns server in
>> /etc/resolve.conf the CLI version also stops working so I figure out that
>> libcurl/php uses another way to resolve eg. via glibc?
>>
>
> curl uses libcurl for the transfers parts, and PHP/CURL uses libcurl for
> the transfer parts. Assuming they both use the SAME libcurl installation
> (which they might not) they will use the exact same name resolving method.
>
> The explanation to why one works and the other doesn't is then left to
> other details: like SElinux? Other security/rights management stuff that
> sits in the way? or whatever. It feels like there's something that makes the
> http server's process not able/allowed to do this.
>
> Quite possibly stracing the server and the tool could help to figure out
> how the system call sequences differ or similar.
>
> Or perhaps you can just wireshark the traffic and see the DNS resolves
> (not) fly by.
>

I checked the traffic (using tcpdump/wireshark) and it seems that
php-curl/apache makes a lot of dns requests (about 20) to the dns-servers of
our previous ISP (which ofcourse refuses the queries because we know use its
major competitor as ISP).

So it is definitely a configuration problem, but i cannot recollect ever to
have entered those ip adresses (dns servers) anywhere in a config file. So
how come does php-curl/apache still remembers them?

Of course this could mean that this is no more a curl problem rather an
apache issue?

>
> Using the options CURLOPT_DNS_USE_GLOBAL_CACHE and
>> CURLOPT_DNS_CACHE_TIMEOUT does not make any differance.
>>
>
> No, they just affect the data after libcurl has received it...
>
> Even worse: if I run 'host dns.be' it returns the requested dns data.
>> which normaly uses the same routines as gethostbyname() (the c function curl
>> uses for this).
>>
>
> If curl works from the command line I would expect host to do so too.
>

I thought that curl had a differant codebase then libcurl.

>
> So this could mean this is perhaps not a dns/bind problem and a fault in
>> how curl caches dns data or handles ipv4/ipv6 adresses?
>>
>
> Why? curl works you say, and it uses the same way to resolve names that
> your PHP/CURL does. So it's not the implementation that's wrong, there's
> something else than hinders it from functioning correctly.
>

Apparently php/apache hinders, but how does php/apache affect the call to
glibc's gethostby* functions? because they only use those dns servers when
run from php/apache. When running curl from command line (and that means
using the same libcurl code) the nameserver given in /etc/resolve.conf is
used (our own nameserver).

> --
>
> / daniel.haxx.se
>
Received on 2009-08-19