Curl not resolving hostnames

[Nick Lewers]

HPUX 11.11
ixCurl A.07.00-7.15.3 A Command Line Tool For Transfering Data

When running curl commands, getting the following error:
neo: curl --verbose http://devtpe.glscorp.com/priceletter.php?filename=24204.txt > 24204.pdf
* getaddrinfo(3) failed for devtpe.glscorp.com:80
* Couldn't resolve host 'devtpe.glscorp.com'
* Closing connection #0

However, when I run an nslookup on the hostname, it returns the IP correctly.

/etc/nisswitch.conf has:
passwd: compat
group: compat
hosts: files [NOTFOUND=continue UNAVIL=continue TRYAGAIN=continue] dns [N
OTFOUND=continue UNAVAIL=continue TRYAGAIN=continue] nis

/etc/resolv.conf has:
search files
domain synergy55.com
search synergy55.com glscorp.com c1.com glsc1.com
nameserver 172.16.20.2
nameserver 172.16.17.8

Any other thoughts on what I need to do or check? Thanks

[Steven E. Protter]

Shalom,

curl does not resolve host names.

Your system does.

I would say one or both of your nameserver entries in /etc/resolv.conf are not resolving requests.

See if you can ping them.

See if nslookup works, try using nslookup interactively to get more realistic error messaging.

SEP

[Nick Lewers]

I understand, however nslookup is resolving the hostname but curl is not. I can ping the host.

anything else you would like me to look at?
neo(root)#nslookup
Using /etc/hosts on: neo

> set swtrace
> set all
Set options:
swtrace querytype=A

#Lookups = 3
files [RCCC] dns [RCCC] nis [RRRR]

Default Name Server: neo.synergy55.com
Address: 172.16.20.2

Default NIS Server:

Default files Server: neo

> devtpe.glscorp.com
Using /etc/hosts on: neo

lookup source is FILES
Using /etc/hosts on: neo

looking up FILES
*** No address information is available for "devtpe.glscorp.com"

Switching to next source in the policy
lookup source is DNS
Name Server: neo.synergy55.com
Address: 172.16.20.2

Trying DNS
Name: devtpe.glscorp.com
Address: 172.16.20.149

[Nick Lewers]

FYI, I have also simply listed in the /etc/nisswitch file:

files dns files

with the same result, nslookup works, curl fails.

[Nick Lewers]

ok, here is another one:
neo(root)#nsquery hosts devtpe.glscorp.com

Using "files [NOTFOUND=continue UNAVIL=continue TRYAGAIN=continue] dns [NOTFOUND
=continue UNAVAIL=continue TRYAGAIN=continue] nis" for the hosts policy.

Searching /etc/hosts for devtpe.glscorp.com
devtpe.glscorp.com was NOTFOUND

Switch configuration: Allows fallback

Searching dns for devtpe.glscorp.com
Hostname: devtpe.glscorp.com
Aliases:
Address: 172.16.20.149
Switch configuration: Terminates Search

[Matti_Kurkela]

If curl includes IPv6 support, it might be using IPv6-compatible DNS routines to resolve plain IPv4 names too. In that case, you might have to configure an "ipnodes:" line to /etc/nsswitch.conf file too. For example:

ipnodes: files [NOTFOUND=continue UNAVAIL=continue TRYAGAIN=continue] dns

At least in HP-UX 11.23, the default for "ipnodes" is first DNS, then files. This occasionally leads to surprises, as many HP-UX standard commands (e.g. telnet) are IPv6-aware in 11.23.

NOTE: the filename is *NOT* /etc/nisswitch.conf but /etc/nsswitch.conf.
It's a Name Service Switch, not just a NIS switch.

MK

[Nick Lewers]

yes, nsswitch. I added the line as you suggested with no change. I did notice that curl supported ipv6, so i also tried adding a -4 to the curl command (to force ipv4) as well to no avail.

[Nick Lewers]

one more thing:
neo(root)#curl --version
curl 7.15.3 (hppa2.0w-hp-hpux11.11) libcurl/7.15.3 OpenSSL/0.9.7i zlib/1.2.3
Protocols: tftp ftp telnet dict ldap http file https ftps
Features: IPv6 Largefile NTLM SSL libz


Also, by IP address the curl command works, but would like to avoid that if I can.

[Steven Schweda]

I know nothing, but I just whipped this up
("./configure ; gmake") here:

dy # uname -a
HP-UX dy B.11.11 U 9000/785 2012616114 unlimited-user license

dy # curl --version
curl 7.20.0 (hppa2.0w-hp-hpux11.11) libcurl/7.20.0 OpenSSL/0.9.7i zlib/1.2.3 lib
ssh2/1.2.2
Protocols: dict file ftp ftps http https imap imaps ldap pop3 pop3s rtsp scp sft
p smtp smtps telnet tftp
Features: Largefile NTLM SSL libz

Mine fails with a different complaint:

dy # curl --verbose http://devtpe.glscorp.com/priceletter.php?filename=24204.txt
* Curl_ipv4_resolve_r failed for devtpe.glscorp.com
* Couldn't resolve host 'devtpe.glscorp.com'
* Closing connection #0
curl: (6) Couldn't resolve host 'devtpe.glscorp.com'

which suggests that name resolution may take
many forms in this stuff. (On my VMS system,
for example, the 7.19.7 message says
"gethostbyname(2) failed [...]".)

If you have a useful C compiler, I'd suggest
building the thing from the source. With any
luck, the "configure" script might be able to
select a working bit of the (local) run-time
library for this task. A newer version might
catch a bug fix, too.

> Features: IPv6 [...]

And, if you build it yourself, you get better
control over the exotic (and potentially
dangerous) options.

[Nick Lewers]

try your curl command with
curl --verbose -4 www.google.com and see what you get.

I know that there is a new version available, however I didnt wish to install with all of the dependancies if possible. I always like to understand why it isnt working to make sure im not missing anything...always somebody smarter than me out there.

[Steven Schweda]

> try your curl command [...]

dy # curl --verbose -4 www.google.com
* About to connect() to www.google.com port 80 (#0)
* Trying 209.85.225.106... connected
* Connected to www.google.com (209.85.225.106) port 80 (#0)
> GET / HTTP/1.1
> User-Agent: curl/7.20.0 (hppa2.0w-hp-hpux11.11) libcurl/7.20.0 OpenSSL/0.9.7i
zlib/1.2.3 libssh2/1.2.2
> Host: www.google.com
> Accept: */*
>
< HTTP/1.1 200 OK
[...]


Works on the VMS system, too:

alp $ curl --verbose -4 www.google.com
* About to connect() to www.google.com port 80 (#0)
* Trying 209.85.225.147... connected
* Connected to www.google.com (209.85.225.147) port 80 (#0)
> GET / HTTP/1.1
> User-Agent: curl/7.19.7 (ALPHA-HP-VMS) libcurl/7.19.7 OpenSSL/0.9.8j
> Host: www.google.com
> Accept: */*
>
< HTTP/1.1 200 OK
[...]


Whether "-4" actually does anything when I
lack "Features: IPv6" is another question, of
course, but basic operation is basic
operation.

[Steven Schweda]

Curiosity and excessive (or misused) free
time collide again...

dy # ./configure --enable-ipv6 --with-zlib
[...]

dy # curl --version
curl 7.20.0 (hppa2.0w-hp-hpux11.11) libcurl/7.20.0 OpenSSL/0.9.7i zlib/1.2.3 lib
ssh2/1.2.2
Protocols: dict file ftp ftps http https imap imaps ldap pop3 pop3s rtsp scp sft
p smtp smtps telnet tftp
Features: IPv6 Largefile NTLM SSL libz

dy # curl --verbose www.google.com
* About to connect() to www.google.com port 80 (#0)
* Trying 209.85.225.147... connected
* Connected to www.google.com (209.85.225.147) port 80 (#0)
> GET / HTTP/1.1
> User-Agent: curl/7.20.0 (hppa2.0w-hp-hpux11.11) libcurl/7.20.0 OpenSSL/0.9.7i
zlib/1.2.3 libssh2/1.2.2
> Host: www.google.com
> Accept: */*
>
< HTTP/1.1 200 OK
[...]

dy # curl --verbose www.google.cow
* getaddrinfo(3) failed for www.google.cow:80
* Couldn't resolve host 'www.google.cow'
* Closing connection #0
curl: (6) Couldn't resolve host 'www.google.cow'


With "-4":

dy # curl --verbose -4 www.google.com
* About to connect() to www.google.com port 80 (#0)
* Trying 209.85.225.106... connected
* Connected to www.google.com (209.85.225.106) port 80 (#0)
> GET / HTTP/1.1
> User-Agent: curl/7.20.0 (hppa2.0w-hp-hpux11.11) libcurl/7.20.0 OpenSSL/0.9.7i
zlib/1.2.3 libssh2/1.2.2
> Host: www.google.com
> Accept: */*
>
< HTTP/1.1 200 OK
[...]

dy # curl --verbose -4 www.google.cow
* getaddrinfo(3) failed for www.google.cow:80
* Couldn't resolve host 'www.google.cow'
* Closing connection #0
curl: (6) Couldn't resolve host 'www.google.cow'


> [...] I always like to understand why it
> isnt working [...]

An argument could be made that it might be
easier to debug if you build your own.

> HPUX 11.11

I might have patches which you lack, too. As
usual, many things are possible. (And
everything's complicated.) "swa" may be your
friend.

For the record:

dy # cat /etc/resolv.conf
domain antinode.info
nameserver 10.0.0.9

dy # cat /etc/nsswitch.conf
cat: Cannot open /etc/nsswitch.conf: No such file or directory

Apparently, I'm using the compiled-in
defaults.

> /etc/nisswitch.conf has:

I'll assume that that was a typo. (Yet
another case where copy+paste of an actual
command would be better than something
worse.)

[Michael Steele_2]

Hi

You'll get this behavior with an ftp proxy server, which needs to be logged into first before you run your curl command.

Check with network admin.

[Nick Lewers]

thanks, there is no proxy server involved. and yes, the nisswitch was a typo.