18.04 Unable to connect to server due to "Temporary failure in name resolution"

I am at a bit of a loss. I am able to perform an nslookup and a dig on the address "imap.comcast.net" but if I try to ping it or connect to it from my application I get a "Temporary failure in name resolution". Something must be amiss in my DNS configuration but I am unsure what it is.

> ping imap.comcast.net
ping: imap.comcast.net: Temporary failure in name resolution
> systemd-resolve --status --no-pager
Global DNSSEC NTA: 10.in-addr.arpa 16.172.in-addr.arpa 168.192.in-addr.arpa 17.172.in-addr.arpa 18.172.in-addr.arpa 19.172.in-addr.arpa 20.172.in-addr.arpa 21.172.in-addr.arpa 22.172.in-addr.arpa 23.172.in-addr.arpa 24.172.in-addr.arpa 25.172.in-addr.arpa 26.172.in-addr.arpa 27.172.in-addr.arpa 28.172.in-addr.arpa 29.172.in-addr.arpa 30.172.in-addr.arpa 31.172.in-addr.arpa corp d.f.ip6.arpa home internal intranet lan local private test
Link 2 (ens3) Current Scopes: DNS LLMNR setting: yes
MulticastDNS setting: no DNSSEC setting: no DNSSEC supported: no DNS Servers: 10.0.0.2 DNS Domain: ec2.internal
> cat /etc/resolv.conf
# This file is managed by man:systemd-resolved(8). Do not edit.
#
# This is a dynamic resolv.conf file for connecting local clients to the
# internal DNS stub resolver of systemd-resolved. This file lists all
# configured search domains.
#
# Run "systemd-resolve --status" to see details about the uplink DNS servers
# currently in use.
#
# Third party programs must not access this file directly, but only through the
# symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a different way,
# replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.
nameserver 127.0.0.53
search ec2.internal

Some more forensic information/etc/resolv.conf is a symlink as seen here

> readlink -f /etc/resolv.conf
/run/systemd/resolve/stub-resolv.conf

If I change the symlink and restart systemd.resolve I can ping the address but it appears to disable dns caching

>sudo service systemd-resolved stop
>sudo rm -f /etc/resolv.conf
>sudo ln -s /run/systemd/resolve/resolv.conf /etc/resolv.conf
>sudo service systemd-resolved start
>ping imap.comcast.net
>sudo systemd-resolve --statistics
DNSSEC supported by current servers: no
Transactions
Current Transactions: 0 Total Transactions: 0
Cache Current Cache Size: 0 Cache Hits: 0 Cache Misses: 0
DNSSEC Verdicts Secure: 0 Insecure: 0 Bogus: 0 Indeterminate: 0

4 Answers

I think I had this issue before. I used the first answer in this question to resolve it:Wrong nameserver set by resolvconf and NetworkManager

The answer is to change the resolv.conf symlink:

sudo rm -f /etc/resolv.conf
sudo ln -s /run/systemd/resolve/resolv.conf /etc/resolv.conf
reboot

For me the answer was that the DNS entries were missing in my Netpan setup. I edited them manually (in my case /etc/netplan/50-cloud-init.yaml but I realize that this might be specific to my environment, and might not "stick").

I changed

network:
ethernets: ens160: addresses: - 10.8.25.116/28 dhcp4: false gateway4: 10.8.25.113 nameservers: addresses: [] search: []
version: 2

to

network:
ethernets: ens160: addresses: - 10.8.25.116/28 dhcp4: false gateway4: 10.8.25.113 nameservers: addresses: [8.8.8.8,4.2.2.2] search: []
version: 2

and then applied it using

netplan apply

It may seem crazy ... But after a LONG study of the logs, similar situations on the Internet ... It is banal for me helped - updating the packages!

Specifically, these commands:

systemctl disable systemd-resolved
systemctl stop systemd-resolved
reboot
apt update && apt upgrade
reboot
systemctl enable systemd-resolved
systemctl start systemd-resolved

In particular, I think the systemd package was somehow corrupted ...

PS: Do not try to solve the problem with your forehead right away! Update / reinstall packages first! Save your time ;-)

I just had this issue and it drove me bananas. I checked the DNS and all the local host networking. it was all perfect. There were NO misconfigurations in the host networking: comparative analysis of other hosts which had the same config were working, but this host wasn't. Why?!?!?

The answer was a duff NAT rule in the Internet GW.

<facepalm>The DNS error message was a SYMPTOM of the problem, not the actual problem itself.</facepalm>

A quick check for missing or incorrect NAT rules in your Internet GW could save you a lot of wasted time...