ProxMox VE Frequent DNS Queries for ProxMox Backup Server

G

GuardedAirplane

New Member
Proxmox Subscriber
Jul 8, 2021
9
0
1
28
Indiana, USA
Not really a major issue, but I have noticed that my ProxMox VE server makes frequent DNS queries pertaining to my ProxMox Backup Server (8 queries every 10 seconds). This actually makes up ~50% of the DNS traffic reported by my PiHole server on my network which is surprising considering all the smart devices I own and I only trigger backups every 6 hours.

Is this expected behavior or do I potentially have something misconfigured? PiHole is configured out of the box with a low TTL, but I am surprised ProxMox wants to ping the backup server so often when not in use.
 
GuardedAirplane said:
every 10 seconds
Click to expand...
This sounds a lot like the pvestatd service checking on the configured storage.

I assume you configured the PBS via its name and not directly via its IP? Why there are 8 queries all the time, I cannot say for sure right now.
 
Yep, that's how I set it up. I guess to be fair I also have two separate pools managed by that server, so might just be 4 per pool. Also checks for ipv6 too despite not being assigned an address (other than link local), so may could be thought of as 2 per.Screenshot_20211104_220753.png

P.S. I am loving PBS so far as the file restore function came in handy recently.
 
Did you make any progress on this? I noticed this behavior as well with sending stats to influxdb, all of the proxmox nodes are super chatty doing dns lookups for the influx server.
 
Follow up, after editing my dnsmasq server to increase the TTLs on the internal domains, proxmox is not honoring them. I still see a huge number of queries, so for now I'm going to set the metrics server to an IP address as a break fix.
 
I had the sameproblem. I used the host.conf to specify order hosts bind and put the ip resolution addresses in /etc/hosts file.
 
This is still happening with latest version of proxmox and proxmox BS (as of today).

On my side, I'm using Unbound and proxmox BS DNS queries account for as much as 60% of my local traffic.

It would be nice if we could get this under control. It works, not an issue but an annoyance as to why so many hits, almost 1 / sec if not more...
 
  • Like
Reactions: gr3n
Hello,
I came accross this thread. The problem still exists. I do not use a local pbs but a remote pbs (with external domain name).
Proxmox issues 4 DNS requests every 10 seconds ( 2 x A + 2 AAAA).

That leads to 1.000.000 DNS requests per month!

I believe there must be some error and ask some staff to have a look at it!
 
Did you try to change your DNS servers TTL as described in #5 and #6m and why are you concerned in the first place? As long as everything works some noise won't hurt anybody.
 
  • Like
Reactions: UdoB and news
Hello Johannes, with this argument, you can downplay all improvements and minor errors.

Of course, the most important thing is that it works, and it does.

But you don't leave your faucet unrepaired if it's constantly dripping water.

But yes, to answer your question, all my DNS queries are assigned a minimum TTL of 2400 seconds.
 
  • Like
Reactions: templar
epionier said:
Hello Johannes, with this argument, you can downplay all improvements and minor errors.
Click to expand...

Imho it's not an error. To my understanding the root cause is that the pvestatd needs to check the status of attached storages on a regular schedule:
https://pve.proxmox.com/pve-docs/pvestatd.8.html
This is logical since otherwise ProxmoxVE couldn't tell whether it could actually connect to the storages.
Normally this would use DNS cache entries but due their low TTL this doesn't work so every time the status of the storages is checked a new DNS request is sent. If I understand correctly, everything is working as expected thus not an error, not even minor. YMMV

And I wouldn't count it an improvement to do less regular checks for the availability of attached storage ;)
 
Johannes S said:
Imho it's not an error. To my understanding the root cause is that the pvestatd needs to check the status of attached storages on a regular schedule:
https://pve.proxmox.com/pve-docs/pvestatd.8.html
This is logical since otherwise ProxmoxVE couldn't tell whether it could actually connect to the storages.
Normally this would use DNS cache entries but due their low TTL this doesn't work so every time the status of the storages is checked a new DNS request is sent. If I understand correctly, everything is working as expected thus not an error, not even minor. YMMV

And I wouldn't count it an improvement to do less regular checks for the availability of attached storage ;)
Click to expand...

I also experience this, you can adjust TTL on records to mitigate it somewhat.

What really doesn't make sense is, it also looks up the IPv6 address for PMBS hostname (AAAA record). There aren't any so it gets NXDOMAIN response. And it just keeps requesting this forever, multiple times per second despite having & using a perfectly good IPv4 record.
 
jamespo said:
What really doesn't make sense is, it also looks up the IPv6 address for PMBS hostname (AAAA record). There aren't any so it gets NXDOMAIN response. And it just keeps requesting this forever, multiple times per second despite having & using a perfectly good IPv4 record.
Click to expand...
To be honest in the year 2026 the lack of IPv6 should be considered an error in the network setup so I don't see an issue in this behaviour.
Yes I know that there are still ( even large ) organizations who stick to IPv4-only this doesn't make the lack of IPv6 less wrong ;)
 
Johannes S said:
To be honest in the year 2026 the lack of IPv6 should be considered an error in the network setup so I don't see an issue in this behaviour.
Yes I know that there are still ( even large ) organizations who stick to IPv4-only this doesn't make the lack of IPv6 less wrong ;)
Click to expand...

Guess what, it would have exactly the same DNS spamming behaviour for A records if you had no IPv4 record defined.

Additionally if you get your IPv6 allocation via your ISP and they dynamically change it, any internal records you've set up would be invalidated.
 
You must log in or register to reply here.
Top Bottom
Back