Introduction

You just set a static IP on your Proxmox VE host, or maybe you spun up a fresh LXC container, and now apt update throws "Temporary failure in name resolution." The network cable is plugged in. You can ping 1.1.1.1 just fine. But anything that needs a hostname — a package mirror, a Docker registry, a website — just times out.

That's a DNS problem, and it's one of the most common things beginners hit right after installing Proxmox VE. The frustrating part is that Proxmox actually manages DNS in three separate places — the host, LXC containers, and VM guests — and each one behaves a little differently. Get the wrong one, and you'll be editing a file that has zero effect on the actual problem.

This guide walks through where DNS actually lives in a Proxmox VE 9.x setup, how to check and fix it at each layer, and what to do when a container or VM won't resolve names even though the host works fine.

What You Will Learn

  • What DNS actually does and why Proxmox needs it to be correct in three different places
  • How to view and change the Proxmox VE host's DNS servers, both from the GUI and the CLI
  • How to set DNS servers and a search domain for an LXC container
  • How DNS works differently for VMs, and when cloud-init can set it for you
  • How to tell a DNS failure apart from a general network failure
  • The specific error messages that mean "this is DNS" and what fixes each one

What Is This Feature?

DNS (Domain Name System) is the service that turns a name like download.proxmox.com into an IP address like 212.224.123.1. Every time something on your network needs to reach a hostname instead of a raw IP, it asks a DNS server first. No answer, no connection — even if the network itself is working perfectly.

Proxmox VE doesn't have one DNS setting. It has three layers that each need their own configuration:

  • The host reads /etc/resolv.conf, the same file every Debian system uses. The Proxmox web GUI gives you a friendlier way to edit it.
  • LXC containers get their own nameserver and search domain settings, stored in the container's config on the host. If you don't set anything, a new container copies the host's DNS settings at creation time.
  • VMs are just regular guest operating systems from Proxmox's point of view. Proxmox has no visibility into a VM's internal network stack unless you're using cloud-init, in which case it can push nameserver settings in on first boot.

Mixing these up is the number one reason "I fixed DNS but it's still broken" happens. You fixed the host. The container never got the memo.

Why Would You Use It?

Most people never touch DNS settings until something breaks, but there are good reasons to set them deliberately instead of accepting whatever your router handed you:

If you're running a local DNS server — Pi-hole or AdGuard Home for ad blocking, or a proper internal DNS server for a homelab — you'll want your Proxmox host and every VM or container pointed at it instead of your ISP's resolver. Ad blocking at the DNS level only works if things actually ask that server.

If you have internal hostnames (say, truenas.lab or gitea.internal) that only resolve on your own DNS server, public resolvers like 1.1.1.1 or 8.8.8.8 will never find them. You need your own DNS server in the list, and ideally listed first.

And honestly, ISP-provided DNS is sometimes just slow or unreliable. Switching your Proxmox host to Cloudflare or Google's public resolvers is a five-minute fix that quietly speeds up everything from package updates to container image pulls.

Prerequisites

  • Root access to the Proxmox VE host, either through the web GUI or SSH
  • At least one LXC container or VM to test against, or plans to create one
  • The IP addresses of the DNS servers you actually want to use — write these down before you start so you're not guessing mid-task
  • Basic comfort typing a few commands in a shell; nothing here requires scripting knowledge

Step-by-Step Tutorial

Step 1: Check what the host is currently using

Before changing anything, look at what's actually configured. SSH into your Proxmox host, or open the built-in Shell from the node view in the web GUI, and run:

cat /etc/resolv.conf

You'll see one or more lines starting with nameserver, and possibly a search line for your domain suffix. If this file is empty or missing, that alone explains why nothing resolves.

Step 2: Change the host's DNS from the GUI

In the Proxmox web interface, click your node in the left-hand tree (not Datacenter — DNS is set per node), then go to System > DNS. You'll see three fields for DNS servers and one for the search domain.

  1. Enter up to three DNS server IPs. Order matters — the first one is tried first.
  2. Optionally set a Search domain if your network uses one (for example, lab.local).
  3. Click OK. This writes directly to /etc/resolv.conf — no reboot needed.

Step 3: Change the host's DNS from the CLI

If you'd rather do it from the shell, or you're scripting a fresh install, edit the file directly:

nano /etc/resolv.conf

Replace the contents with something like:

search lab.local
nameserver 1.1.1.1
nameserver 9.9.9.9

Save and exit. There's no service to restart — DNS lookups read this file fresh every time. Test it immediately with:

host download.proxmox.com

Step 4: Set DNS for an LXC container from the GUI

Select the container in the tree, then go to Options, and double-click DNS domain. You've got two choices here: leave it on Use host settings so the container mirrors whatever the Proxmox host uses, or pick Custom and enter your own DNS servers and search domain just for that container.

Custom is worth using when a specific container needs to talk to a DNS server the host itself doesn't use — a container running inside an isolated VLAN, for instance.

Step 5: Set DNS for an LXC container from the CLI

From the host shell, not inside the container, run:

pct set 105 --nameserver 1.1.1.1 --searchdomain lab.local

Swap 105 for your container's actual ID. You can pass two nameservers separated by a space inside the quotes if you want a fallback:

pct set 105 --nameserver "1.1.1.1 9.9.9.9"

This takes effect the next time the container's network stack initializes — for a running container, that usually means a restart:

pct reboot 105

Step 6: Set DNS for a VM

This is where things differ. Proxmox doesn't reach inside a VM's operating system the way it does with an LXC container, so there's no qm equivalent of pct set --nameserver for a VM you installed the normal way. You set DNS the same way you would on any physical machine — inside the guest's own network settings (Netplan or /etc/resolv.conf on Linux, the Network adapter properties on Windows).

The one exception is cloud-init. Cloud-init is a first-boot provisioning tool baked into most cloud VM images — it lets Proxmox inject network settings, users, and SSH keys into a VM before it even finishes booting, without you having to log in and configure anything by hand. If your VM was built from a cloud-init template, you can set DNS the same way you'd set a static IP:

qm set 201 --nameserver 1.1.1.1 --searchdomain lab.local

This only applies on the VM's first boot after the cloud-init drive is regenerated. It has no effect on a VM that's already been running and configured normally.

Step 7: Confirm it actually worked

Don't just trust that the config looks right — test it from wherever you made the change:

host google.com
apt update

If host returns an IP address and apt update pulls package lists without hanging, DNS is working at that layer.

Commands Explained

  • cat /etc/resolv.conf — prints the current DNS servers and search domain the host (or container, if run inside one) is using.
  • pct set <ctid> --nameserver <ip> — sets one or more DNS servers for a specific LXC container, overriding the host's settings just for that container.
  • pct set <ctid> --searchdomain <domain> — sets the DNS search suffix, so you can type truenas instead of truenas.lab.local from inside that container.
  • pct reboot <ctid> — restarts a container so a DNS change actually takes effect.
  • qm set <vmid> --nameserver <ip> — sets the DNS server a cloud-init-enabled VM will use on its next first-boot provisioning pass. Does nothing for VMs without a cloud-init drive.
  • host <hostname> — a simple DNS lookup tool. If this fails but ping 1.1.1.1 works, the problem is specifically DNS, not general connectivity.
  • resolvectl status — on systems using systemd-resolved (common in some Ubuntu container templates), shows which DNS servers are actually active, which can differ from what's in /etc/resolv.conf.

Common Errors

"Temporary failure in name resolution" — the most common DNS error you'll see, usually from apt update or curl. It means no DNS server responded. Check /etc/resolv.conf at whatever layer you're on (host, container, or VM) and confirm the nameserver IP is actually reachable.

"Name or service not known" — similar to the above but from a different tool (often ping or wget). Same root cause, same fix.

DNS works on the host but not inside the container — you probably changed the host's /etc/resolv.conf after the container was already created. Containers copy host DNS settings at creation time, not continuously. Either set the container's DNS explicitly with pct set, or switch its DNS domain setting to Use host settings and restart it.

Changes to /etc/resolv.conf disappear after a container reboot — this happens on Ubuntu-based LXC templates that use systemd-resolved. The file becomes a symlink managed by that service, and it regenerates on boot. Set DNS through pct set --nameserver instead of editing the file by hand inside the container — that goes through Proxmox's own container config, not the guest's resolved stub.

Troubleshooting

Start by isolating whether this is really a DNS issue or a broader network problem. Ping a raw IP first:

ping -c 3 1.1.1.1

If that fails, you don't have a DNS problem — you have a routing or firewall problem, and fixing resolv.conf won't help. If the ping succeeds but host google.com fails, you've confirmed it's DNS specifically.

Next, check whether your DNS server is even reachable on port 53. From the host or a container:

dig @1.1.1.1 google.com

If this times out but you can ping 1.1.1.1, something is blocking UDP port 53 — most often the Proxmox firewall if you've enabled it on that VM or container without an explicit allow rule for DNS.

If you're running your own DNS server (Pi-hole, AdGuard, a router-based resolver) and everything downstream stopped resolving at once, check that the DNS server itself is actually up. This is an easy one to miss — people troubleshoot Proxmox for twenty minutes before realizing the Pi-hole VM crashed.

For containers specifically, run pct config <ctid> and look for the nameserver and searchdomain lines. If they're blank, the container is inheriting the host — which is fine, as long as the host's own DNS is correct.

Best Practices

  • Always configure at least two DNS servers, not one. A single resolver going down takes out name resolution for everything pointed at it.
  • If you run internal DNS (a Pi-hole, AdGuard, or dedicated DNS server), list it first and a public resolver like 9.9.9.9 second as a fallback — not the other way around, or your internal hostnames will never resolve.
  • Don't hand-edit /etc/resolv.conf inside a container that uses systemd-resolved. Use pct set from the host instead, so the setting survives reboots.
  • Keep a short note somewhere (even a text file) of which DNS servers your homelab uses and why. Six months from now you won't remember whether 10.0.0.53 was intentional or a typo.

Frequently Asked Questions

Why does my container still use the old DNS server after I changed it on the host?

Containers copy the host's DNS settings only at creation time, not continuously. Set DNS directly on the container with pct set --nameserver, or switch its Options to "Use host settings" and reboot it.

Can I set DNS for a VM the same way I set it for a container?

No, not unless the VM uses cloud-init. Regular VMs manage their own network stack internally, the same as a physical machine would — you configure DNS inside the guest OS itself.

Why does ping work but apt update doesn't?

Pinging an IP address doesn't use DNS at all. apt update needs to resolve mirror hostnames first. If ping works and apt doesn't, the problem is DNS, not your network connection.

Is it safe to use my router's IP as the DNS server?

Usually, yes — most home routers run a small DNS forwarder that relays to your ISP or a public resolver. It works fine for most setups, though it adds one extra hop compared to pointing directly at a resolver.

What's the difference between the search domain and the DNS server?

The DNS server is who answers your lookup requests. The search domain is a suffix automatically appended to short hostnames — so typing truenas tries truenas.lab.local first instead of failing outright.

Conclusion

DNS trouble in Proxmox VE almost always comes down to the same mistake: fixing it in one place and assuming it applies everywhere. The host, LXC containers, and VMs each keep their own DNS configuration, and only containers inherit from the host — and only at creation time, at that.

Once you know where each layer actually stores its settings — /etc/resolv.conf on the host, pct set --nameserver for containers, and either the guest OS or cloud-init for VMs — tracking down a broken resolver stops being a guessing game. Check the layer that's actually failing, confirm it with host or dig, and you'll usually have it sorted in a couple of minutes.