it's still an issue and some DNS servers are alergic to so many requests. Why would any application even want to do that many DNS queries?

Still having this issue, temp hack fix by using a local dns caching solution with dnsmasq.

I too still have this issue on multiple machines running Linux Mint 19.1 Cinnamon

Issue still persists. Usging a VPN Service also solves the issue for me.
Why can this bug not be resolved after more than a decade.

Issue still persists. Usging a VPN Service also solves the issue for me.
Why can this bug not be resolved after more than a decade.

Haven't you heard of Valve Time?

Using tcpdump, it looks like it is making a new DNS request every tenth of a second or less? If Valve can't fix this issue, can't they use static ips for game content instead?

Think I might set up a pi-hole just to deal with this.

Chiming in. Experiencing this issue on Mint Cinnamon 19.1.

Maybe related, was able to trigger this on a host that lost network access (laptop). Kind of odd considering the TTL on those records should be at least 3 hours

cm1-iad1.cm.steampowered.com. 10800 IN	A	162.254.192.100

Funny thing is steam will remember whatever nodes it finally is able to latch onto rather then using the configured region. Completely forgot I override dns on steam hosts, only noticed going from home to office. Ethernet was plugged into a cell modem but the data was turned off thus it had a link but no net access.

This is still a problem! Experiencing it on Ubuntu 18.04. dnsmasq as a workaround seems to have some sort of conflict with other services and ends up torching the network, still working on how to fix that, but it would be really nice if steam behaved properly and didn't cause this issue in the first place!

Just wanted to say that this is still an issue. The dnsmasq workaround didn't work for me. Am now using Windows with Steam for the time being.

Just adding my pinch of salt here:
I recently installed Kubuntu 20.04 and installed Steam straight from the software store and had this issue. Kubuntu comes with dnsmasq by default, and in the last issue thread, I saw that one fix was to add "nameserver 127.0.0.1" to /etc/resolv.conf, then restarting Network-Manager.
This was a good work-around for my issue, but when I looked back at resolv.conf, the addition I made was removed automatically. My speeds are still stable, but I know that if I restart my PC, this change may be reverted. I don't see this as a solution, but a workaround.
Is there any chance anyone knows what I can do that's a more permanent solution?

I also experience this issue, setting up dnsmasq solved it as a workaround.

Experiencing this issue as of a couple weeks ago, have a windows PC in my network and issue is not present:

Steam Version:  1702079146
Steam Client Build Date:  Thu, Dec 7 7:33 PM UTC -08:00
Steam Web Build Date:  Fri, Dec 8 6:30 PM UTC -08:00
Steam API Version:  SteamClient021

OS: Arch Linux
Kernel: Linux MYARCHGAMER 6.6.2-arch1-1 #1 SMP PREEMPT_DYNAMIC Mon, 20 Nov 2023 23:18:21 +0000 x86_64 GNU/Linux

I've tried installing dnsmasq and pointing my DNS resolving to it locally with no change in speed on the Steam download.

also having this issue.
on W11 i can download with over 500mbit\s
on archlinux,ubuntu,linux mint its max. 250mbit\s
really annoying

I've tried installing dnsmasq and pointing my DNS resolving to it locally with no change in speed on the Steam download.

Same here on EndouverOS. Didn't see any improvement. Only the steam_dev.cfg workaround added some speed. But still nowhere as fast as on Windows. It's insane that this isn't fixed.

I want to add to this: I am using Arch (Manjaro) Linux and Steam is also overloading my DNS server. I use Pihole as my DNS server on my network, steam overloads & crashes it during downloads. I have to SSH into my Pihole every minute or so to reboot the DNS server in order to keep downloading, very frustrating.

I want to add to this: I am using Arch (Manjaro) Linux and Steam is also overloading my DNS server. I use Pihole as my DNS server on my network, steam overloads & crashes it during downloads. I have to SSH into my Pihole every minute or so to reboot the DNS server in order to keep downloading, very frustrating.

I was actually going to set up a PiHole to see if that would help mitigate the issue since I'm running Mikrotik as my router and figured its DNS was being overloaded. RIP that plan!

For reference I am having the same issues with pihole (my fix is disabling pihole during downloads), the amount of DNS requests is quite high, compared to normal traffic.

For reference, proof pihole is blocking

And the monitoring when downloading a game. the spike are obvious.

Probably doesn't add much but I began seeing this today using a fresh install of EndeavourOS (switched from Manjaro). Never seen anything like it before. Stats very similar to @abelsromero only with peaks of up to 1800 3500. Sites queried are all cache[X]-ams1.steamcontent.com.

I started getting DNS refusals while downloading before I had set up NetworkManager to use my PiHole. Figured the solution was to set it touse it. It didn't change anything other than making it easier to tell what was happening, i.e. rate limiting. PiHole's RATE_LIMIT had kicked in at 1000/60. Setting/disabling RATE_LIMIT to 0/0 'fixed' it.

Just to make explicit what others have been hinting at: Throttling download speeds seems to help a whole lot with the number of queries generated.

The drop around 13:15 and onwards is due to enabling Limit download speed and setting limit in kilobit speed per second to 80,000 (down from somewhere between 320,000 and 360,000 when unregulated).

Before that I tried disabling Game Transfer over Local Network to no effect (not that there were other hosts on the network offering anything).

I am also affected on Manjaro 24.0.2. Tried setting up dnsmasq to no avail. Getting rate limited on my pi-hole because of this.

Also having this problem with Arch during large steam downloads. Rate limited by pi-hole.

I bumped my rate limit up and then it immediately jumped up to 6000. I installed dnsmasq and configured it for local caching and it's temporarily fixing the issue

Aaah, now it got me, too! The pihole was very unhappy about it and shut me completely off, too.

Started to have this issue lately - spamming dns while downloading. Has anyone found fix for this?

Operating System Version:
"Garuda Linux Bird of Prey" (64 bit)
Kernel Name: Linux
Kernel Version: 6.11.0-5-cachyos
X Server Vendor: The X.Org Foundation
X Server Release: 12101013
X Window Manager: GNOME Shell
Steam Runtime Version: steam-runtime_0.20240806.97925

Steam Beta Branch: Steam Beta Update
Steam Version: 1726683985
Steam Client Build Date: Wed, Sep 18 20:13 UTC -08:00
Steam Web Build Date: Tue, Sep 17 02:12 UTC -08:00
Steam API Version: SteamClient021

I was wondering why several applications became unable to resolve domains while I was downloading updates in Steam. As I'm using systemd, running resolvectl monitor can be used to inspect queries easily. Monitoring reveals that several (but always the same) domains under cdn.steampipe.steamcontent.com are repeatedly being queried in relatively short intervals. In my case, at some point those queries started failing with "dnssec-failed: no-signature", followed by a wave of about 100 queries per second, repeating the exact same query. As the wave of queries finally ends, "no internet connection" can be seen in Steam before the download is retried. I suspect that the backing DNS server (my local router or the ISP DNS servers behind it) starts to refuse connections to mitigate flooding. DNS becomes available again after a cooldown period of roughly 1, 2 or 5 minutes (also suggesting that the behaviour triggers a staggered attack mitigation somewhere upstream).

While it should probably be looked into why Steam can even start (to cause) such a flood of queries towards the DNS resolver, it appears that it was actually a bad configuration on the resolver itself (i.e. my local system): When searching for the error message, several reports can be found online regarding similar issues that were caused by problems with DNSSEC verification, be it a broken upstream resolver or other defects in the overall system. Without looking for the exact root cause, disabling DNSSEC via DNSSEC=false in /etc/systemd/resolved.conf and activating the changes by systemctl restart systemd-resolved appears to have "solved" the issue for me. Only allowing downgrades (DNSSEC=allow-downgrade) was not sufficient (matching reports that this depends on upstream support which may be broken for some ISPs/resolvers).

Apart from issues in Steam or upstream DNS servers this may also be some bug or deficiency in systemd's resolved service.

The issue seems to be only reproducible on larger sustained downloads running for at least 15-20 minutes. For me, e.g. DLCs for Train Sim World appear to be a reliable way to trigger the issue.

[!WARNING]
Make sure you understand the consequences of weakening/disabling DNSSEC. In my case (for me, personally, as of now) this is an acceptable risk but it will not suit everybody. In general, DNSSEC should stay enabled. If it does not work reliably, this is an issue that should be investigated more carefully. Disabling it may just be an initial workaround while looking for a proper solution. Switching to different upstream resolvers such as those provided by Google or CloudFlare may solve the rate limiting/DNSSEC verification issues but will introduce other risks and issues instead (such as depending on an extra service provider in addition to your ISP and, possibly, submitted queries being used for profile creation/tracking).

DNSSEC=false

Isn't there any way to apply this just for cdn.steampipe.steamcontent.com?

I found a "workaround" for my issue. This is very embarrassing on Valve's end, they need to address whatever is causing this issue with the client/CDN behavior.

Steam downloads on my normal AT&T route were usually stuck around 100 to 350 Mbps, despite a 5Gb connection and 10GbE NIC. Speed tests were fine, CPU/disk were not bottlenecked, Steam was opening multiple HTTPS connections, and MTR showed 0% loss to the final Valve CDN destinations.

Using a VPN immediately raised Steam downloads to around 900 Mbps, which was the VPN’s throughput limit. The important difference was that Steam opened many more CDN connections over the VPN. Without VPN, Steam kept heavily favoring two Valve CDN IPs:

205.196.6.165
162.254.194.27

When I blackholed those two IPs locally, Steam selected different CDN endpoints and download speed jumped from 300Mbps to around 1.9 Gbps.

Temporary workaround:

sudo ip route add blackhole 205.196.6.165
sudo ip route add blackhole 162.254.194.27

pkill -9 -f 'steam|steamwebhelper'
steam

To verify which CDN IPs Steam is using:

ss -tnp | grep steam | grep ':443' | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -nr

This does not fix the root cause, but it strongly suggests Steam was assigning or sticking to poor CDN nodes for my normal route. Blocking those specific slow nodes forced Steam to pick better ones.

I had to do this a few months ago, and it temporarily fixed it. So this is clearly something you will have to do every couple months until Valve addresses this.

until Valve addresses this.

Ha. Never.