There are two possible points of failure:
- is TCP/UDP connectivity to the DNS server working?
- is the C library configured to use DNS in the first place, and if so, using which resolver library?
The first point can be tested using any of the commands suggested before:
host www.google.es 184.108.40.206
nslookup www.google.es 220.127.116.11
dig +short www.google.es @18.104.22.168
Since the DNS server can be pinged successfully, we know IP routing works and ICMP traffic is allowed - but it tells us nothing about DNS traffic specifically, i.e. TCP and UDP traffic to port 53. A firewall could block that without blocking ICMP, or vice versa.
For the second possible point of failure, run:
grep hosts /etc/nsswitch.conf
If the answer does not include keywords
lwres, then the hostname resolution in this VM has been configured to not use DNS at all - the keywords will indicate which methods are actually going to be used.
dns is the classic DNS resolver, configured via
libnss-lwres: if you find this, also verify that a
lwresd process is running and it has not been configured to use a custom configuration file instead of the default
libnss-resolve: if you find this, verify that the
systemd-resolved process is running, and use the
systemd-resolve --status command to view the current DNS configuration. In this case the classic
/etc/resolv.conf might not necessarily be used at all, other than to direct applications that use their own DNS resolver libraries to send their queries to
To test whether or not an application can successfully use whichever hostname resolution library has been configured, use
getent hosts www.google.es. If you think the application uses IPv4 only, or specifies a preference for IPv4, you can also test with
getent ahostsv4 www.google.es. Likewise, to test specifically for IPv6 only, you can use
getent ahostsv6 www.google.es.