Temporary failure in name resolution - Help Needed

semaiheya

New Member
Mar 23, 2025
1
0
1
Really looking for some help/answers to some DNS resolution issues I've been seeing - I've been trying to troubleshoot this for two days now and it's driving me crazy.

I have a completely fresh install of proxmox, but it can't access the internet - I noticed when scripts weren't working. When I try to ping github.com for example (same for facebook.com, google.com, etc), I get

ping: github.com: Temporary failure in name resolution

Here's /etc/resolv.conf:
Code:
search lan
nameserver 192.168.1.1

Here's hosts:
Code:
127.0.0.1 localhost.localdomain localhost
192.168.1.7 pve.lan pve

# The following lines are desirable for IPv6 capable hosts

::1     ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts
I have Adguard Home set up as my DNS server on an OpenWRT router at 192.168.1.1 listening on port 53. I don't believe AGH/my router are the issues here because no other machine/device connected to the internet has any problems connecting to the internet. The weird thing is that I've confirmed that AGH seems to be seeing and responding to the DNS queries, but they just aren't getting returned to proxmox - all the pings do come through in the AGH logs and show as processed.

Proxmox can ping 192.168.1.1 directly:

Code:
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=0.900 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=1.28 ms
64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=0.893 ms
64 bytes from 192.168.1.1: icmp_seq=4 ttl=64 time=0.777 ms
It can also ping other public DNS servers:

Code:
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
64 bytes from 1.1.1.1: icmp_seq=1 ttl=57 time=13.5 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=57 time=13.3 ms
64 bytes from 1.1.1.1: icmp_seq=3 ttl=57 time=12.4 ms
64 bytes from 1.1.1.1: icmp_seq=4 ttl=57 time=12.7 ms
It can also ping github's IP address (140.82.116.3) directly!

Code:
PING 140.82.116.3 (140.82.116.3) 56(84) bytes of data.
64 bytes from 140.82.116.3: icmp_seq=1 ttl=55 time=37.6 ms
64 bytes from 140.82.116.3: icmp_seq=2 ttl=55 time=37.6 ms
64 bytes from 140.82.116.3: icmp_seq=3 ttl=55 time=37.6 ms
64 bytes from 140.82.116.3: icmp_seq=4 ttl=55 time=37.3 ms
nslookup, dig, and getent hosts also appear to work correctly:

Code:
nslookup github.com
Server:         192.168.1.1
Address:        192.168.1.1#53

Non-authoritative answer:
Name:   github.com
Address: 140.82.116.4

--------------------------

; <<>> DiG 9.18.33-1~deb12u2-Debian <<>> github.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16621
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;github.com.                    IN      A

;; ANSWER SECTION:
github.com.             43      IN      A       140.82.116.3

;; Query time: 21 msec
;; SERVER: 192.168.1.1#53(192.168.1.1) (UDP)
;; WHEN: Sun Mar 23 01:41:40 MST 2025
;; MSG SIZE  rcvd: 55

--------------------------

getent hosts github.com
140.82.116.3    github.com
I also don't have any firewall rules impacting port 53. I've tried disabling IPv6 to see if that was the issue (it wasn't). I've tried googling and it does seem like there are other people who have had this issue, but I didn't find a way to resolve it other than just to use a different DNS server - which yes, does work. The only way I've been able to get it to connect has been to create a port forwarding exception that allows proxmox to bypass AGH and reach an external DNS server (e.g., 1.1.1.1 or 9.9.9.9 etc). I get that I could leave it at that, but I'd really like to understand why this is happening.

Anyways, I've been tearing my hair out over this for what feels like forever at this point. If anybody can save me I'd really appreciate it.
 
same situation after latest updates.
Help us
Any one solved the issue?
I would be interested to know if both of you also (like the OP) show a <hostname>.lan in your cat /etc/hosts &
search lan in cat /etc/resolv.conf instead of the (more common?) <hostname>.local & search local output respectively.

My thinking: Many routers/nameservers/AGH etc. can be finicky with this - maybe this is the cause of your issues. If my hunch is correct this is most certainly an mDNS/ICANN etc. issue (I'm not going down that can-of-worms!).
 
I would be interested to know if both of you also (like the OP) show a <hostname>.lan in your cat /etc/hosts &
search lan in cat /etc/resolv.conf instead of the (more common?) <hostname>.local & search local output respectively.

I have:
/etc/network/interfaces
Code:
source /etc/network/interfaces.d/*

auto lo
iface lo inet loopback

iface enp0s31f6 inet manual

auto vmbr0
iface vmbr0 inet static
        address 192.168.10.21/24
        gateway 192.168.10.1
        bridge-ports enp0s31f6
        bridge-stp off
        bridge-fd 0


/etc/resolv.conf
Code:
search .
nameserver 192.168.10.1


/etc/hosts
Code:
127.0.0.1       localhost
192.168.10.21   mox.lan mox

# The following lines are desirable for IPv6 capable hosts
::1     localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

/etc/nsswitch.conf
Code:
passwd:         files systemd
group:          files systemd
shadow:         files systemd
gshadow:        files systemd

hosts:          files myhostname dns
networks:       files

protocols:      db files
services:       db files
ethers:         db files
rpc:            db files

netgroup:       nis


My thinking: Many routers/nameservers/AGH etc. can be finicky with this - maybe this is the cause of your issues. If my hunch is correct this is most certainly an mDNS/ICANN etc. issue (I'm not going down that can-of-worms!).

This is the tricky part.

Replacing nameserver 192.168.10.1 with nameserver 1.1.1.1 does solve the issue. In the node.
But it remains in VMs/containers.

Because this is a Debian issue, not a Proxmox issue.
It happens:
  • in a pure-Proxmox installation (static IP but I also tried DHCP with the same result)
  • in a Debian -> Proxmox installation (static IP)
  • in a Debian VM (DHCP) inside a Proxmox node
  • Edit: in Debian containers & Ubuntu containers
But it does not happen:
  • in a Fedora VM (DHCP) inside the same Proxmox node.
  • Every other device on the network
  • Edit: I managed to create a working container (with a Helper Script) in a Fedora container

This is Fedora's /etc/resolve.conf
Code:
nameserver 127.0.53
options edns0 trust-ad
search-lan

I'm guessing Debian's standard config has an issue with some router configurations.

I have a OpenWRT 24.0 with a Wiregard client but no AGH for the moment.
DNS is the standard port 53 on the router's IP address.
 
Last edited:
So far my theory holds. But we will wait for a (possible/hopeful) response from MALEFX.

New configs:

hosts
Code:
127.0.0.1       localhost
192.168.10.21   mox.local       mox
20.201.28.148   api.github.com

resolv.conf
Code:
search local
nameserver 192.168.10.1

Same results. No name resolving if nameserver is set to router's address.


I don't remember seeing search . before. How did that happen?
By passive incompetence I figure. I can assure you it wasn't proactive incompetence.
 
I was curious about the original poster's report that while "ping" fails, some other name resolution tools work. I came across the following:

Code:
ping is using glibc name resolution, which relies on /etc/nsswitch.conf and potentially /etc/resolv.conf,
tools like dig or nslookup bypass glibc and talk directly to DNS.

So I believe @gfngfn256 is on the right track trying determine correctness of the name resolution configuration files.
That said, it is also possible that the internal router is blocking/refusing PVE requests as a "security" measure. Running a tcpdump would tell you what PVE asks for and what it gets in reply.


Blockbridge : Ultra low latency all-NVME shared storage for Proxmox - https://www.blockbridge.com/proxmox
 
Last edited:
  • Like
Reactions: asdf14
I believe the first line should be:
127.0.0.1 localhost.localdomain localhost
Also make sure you have a single space only between words.


After a reboot? I'm not sure that should matter - but you never know.

New hosts:
Code:
127.0.0.1 localhost.localdomain localhost
192.168.10.21 mox.local mox

# The following lines are desirable for IPv6 capable hosts
::1     localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

Same results.


After a reboot? I'm not sure that should matter - but you never know.

Not before, but I did reboot after reading your reply and the issue persists.

Edit: grammar
 
Last edited:
127.0.0.1 localhost.localdomain localhost 192.168.10.21 mox.local mox
Are you using localdomain or local as the local domain? Pick one and stick to it, please.
resolv.conf
Code:
search local
nameserver 192.168.10.1
Make sure to match the choice above. Maybe chose local instead of localdomain or edit this file also.
Make sure that your local router also uses the same (local) domain.
 
Just FYI, I have a bunch of Debian machines, both VM's and hardware, behind an OpenWRT 24.01 router, all using the router's DNS. It works fine. Whatever's wrong isn't an inherent thing in Debian or OpenWRT. I don't currently have wireguard enabled though, so that's one difference.

Did you install any helpful networking tools like NetworkManager on any of these machines? You get that by default for setups with a desktop. If so, editing /etc/resolv.conf may not be the right approach to changing the DNS.

Also, what is this in /etc/nsswitch.conf?
hosts: files myhostname dns
The Debian machine running KDE Plasma I am sitting in front of has this:
hosts: files mdns4_minimal [NOTFOUND=return] dns
My NFS server, which has no desktop, has this instead:
hosts: files dns
 
  • Like
Reactions: Johannes S
Are you using localdomain or local as the local domain? Pick one and stick to it, please.

Make sure to match the choice above. Maybe chose local instead of localdomain or edit this file also.
Make sure that your local router also uses the same (local) domain.
Oops, missed that. All files matching now.

resolv.conf
Code:
search local
nameserver 192.168.10.1

hosts
Code:
127.0.0.1 localhost.local localhost
192.168.10.21 mox.local mox

::1     localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

network/interfaces
Code:
source /etc/network/interfaces.d/*

auto lo
iface lo inet loopback

iface enp0s31f6 inet manual

auto vmbr0
iface vmbr0 inet static
        address 192.168.10.21/24
        gateway 192.168.10.1
        bridge-ports enp0s31f6
        bridge-stp off
        bridge-fd 0



Soooo, weirdest thing happened:
I adjusted the hosts file following your advice and it instantly pinged a url! Success, right?
Ran a helper-script to see if it extended to the containers, and it failed.
Went back to the node and it doesn't resolve domains anymore.
Rebooted and nothing changed.

Anyway, it's the second time this happens (change a setting, name resolution works once and stops), which is even weirder.


Also, what is this in /etc/nsswitch.conf?
Removed that "myhostname", rebooted, and against my high hopes, nothing...
 
Ran a helper-script to see if it extended to the containers, and it failed.=
"helper-scripts" are not provided or support by Proxmox. Maybe ask help from the people that provide and maintain those scripts?
Soooo, weirdest thing happened:
I adjusted the hosts file following your advice and it instantly pinged a url! Success, right?
Ran a helper-script to see if it extended to the containers, and it failed.
Especially ask the people who created and support those "helper-scripts" since things started working until you ran those scripts.
 
"helper-scripts" are not provided or support by Proxmox. Maybe ask help from the people that provide and maintain those scripts?
Because the issue predates any "helper-scripts" and was replicated in a brand-new Proxmox installation on a different computer.
 
Because the issue predates any "helper-scripts" and was replicated in a brand-new Proxmox installation on a different computer.
I adjusted the hosts file following your advice and it instantly pinged a url! Success, right?
Ran a helper-script to see if it extended to the containers, and it failed.
Best of luck with getting your issue resolved, as I cannot support random scripts from the internet. Sorry for not being more helpful. Maybe someone else can support you with this issue.

EDIT: I'm sorry for the tone for my message. I should not vent my frustration about random internet scripts in this way. And it turns out that I was also wrong about the script causing the problem, which is what I wanted to point out (in a poor way).
 
Last edited:
  • Like
Reactions: news
Best of luck with getting your issue resolved, as I cannot support random scripts from the internet. Sorry for not being more helpful. Maybe someone else can support you with this issue.

Where did that came from? I'm thankful for all the help anyway.



Anyway.

Reinstalled Proxmox from scratch a handful of times in two different machines.

Installation with cable attached -> no name resolution.

Installation with no network -> reboot -> connect cable -> name resolution works -> wait 1 minute -> back to not working
disconnect cable -> reboot -> reattach cable -> no name resolution -- the damage is permanent!

Some notes:
- hosts, resolv.conf and interfaces files are identical for both methods.
- hosts files containing .localdomain incoherently with the rest of the files doesn't stop name resolution working for the first minute, that's not the issue.

It's not the configuration files.

The problem is elsewhere. Some network conflict maybe.
It's not an IP conflict. It's outside my DHCP range and nothing else has that IP.
 
Installation with no network -> reboot -> connect cable -> name resolution works -> wait 1 minute -> back to not working
disconnect cable -> reboot -> reattach cable -> no name resolution -- the damage is permanent!
The problem is in your router.

It's outside my DHCP range and nothing else has that IP.
This may be why


Blockbridge : Ultra low latency all-NVME shared storage for Proxmox - https://www.blockbridge.com/proxmox
 
The problem is in your router.


This may be why


Blockbridge : Ultra low latency all-NVME shared storage for Proxmox - https://www.blockbridge.com/proxmox

I thought static IP addresses were supposed to be outside of the DHCP range to prevent IP conflicts. Am I wrong?

Edit: that's not it. My router doesn't have a problem with my notebook being outside of the DHCP range.

Edit 2:
Tried this:
Fresh PM install w/o network -> switch to DHCP -> reboot & connect cable -> pings 1.1.1.1, doesn't ping google.com

Edit 3:
Not a date&time issue either, by the way.
 
Last edited: