How is it possible that I can do a host lookup but not a curl?

Perhaps you have some very weird and restrictive SELinux (or grsecurity...) rules in place?

If not, try strace -o /tmp/wtf -fF curl -v google.com and try to spot from /tmp/wtf output file what's going on.

Using this: https://www.centos.org/modules/newbb/viewtopic.php?topic_id=39343

I found a key command that helped me troubleshoot:

[root@localhost ~]# wget -6 URL Failed
[root@localhost ~]# wget -4 URL Worked

It's something to do with the default ipv6 stack that's causing problems with certain utils. Disable ipv6 to resolve.

Check your /etc/nsswitch.conf. If the hosts line says something like

hosts:      files dns

I'm as confused as you. But if it says something like

hosts:      files

then the fact that DNS is working (see output of host command) won't help curl, which is doing name resolution via the standard OS libraries, which have been told not to use the DNS.

I had the same problem - host, nslookup resolves ok, curl - can't on the same hostnames.

After tcpdumping communication I found that curl tries to establish TCP (in addition to UDP) connection to DNS port, which was closed in my router. After tcp port 53 was enabled curl started to work flawlessly.

Another strange thing is that this problem does not surface if dns server is regular bind installation. If I use embedded into router DNS server, curl suddenly tries to use TCP ports even if it already received (!) answer via UDP 2ms before. I suppose this is bug.

There could be an error in your /etc/resolv.conf file that nslookup tolerates but curl does not.

The question asked was "How is it possible that I can do a host lookup but not a curl?"

This is possible because curl uses getaddrinfo() to resolve the FQDN, whereas nslookup does not. Instead, I believe nslookup parses /etc/resolv.conf using some other function or library, or via its own custom code. I did not look at source code to verify this, but you can prove it by adding whitespace in front of the nameserver token in /etc/resolv.conf. nslookup can parse this but getaddrinfo() cannot.

Example /etc/resolv.conf
 nameserver 8.8.8.8

If your resolv.conf has this error, or other errors that are tolerated by nslookup but not getaddrinfo(), then you can resolve an FQDN with nslookup, but you will not be able to use curl on that FQDN.

Fix: as root, edit /etc/resolv.conf and remove any leading whitespace on the nameserver line.