First off, thanks for the response, much appreciated!
On Wed, Aug 19, 2009 at 10:00 AM, Daniel Stenberg <[email protected]> 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 >
