[COMCAST] Comcast Steam domains causing cache misses

[Leapo]

The following domains need to be black-holed by steamcache-dns in order to prevent cache misses for Comcast subscribers:

edge.steam-dns.top.comcast.net
edge.steam-dns-2.top.comcast.net

If the Steam client is able to resolve the above addresses, it will automatically use them to retrieve content. This is a problem, because these Comcast-specific content servers require HTTPS, which isn't cached. If these addresses are black-holed, the Steam client automatically reverts to normal behavior.

[ghost]

hello this resolution is referenced to a few cases but no steps or process on how to achieve this...

[astrolox]

It's my understanding that this is now fixed. PR uklans/cache-domains#19

[ghost]

this has not been fixed I was able to confirm steam will not cache over comcast without blocking https edge servers via sniproxy

[unspec]

Hopefully the new built in Steam support for caching - see lancachenet/monolithic#85 - should resolve any outstanding ISP specific issues. Feel free to reopen if there is still something we can help with.

[fivesixzero]

I can confirm that this is still a problem with Comcast connections even after Valve's changes to the Steam client earlier this year.

The fix in #47 got things caching properly though. Once sniproxy.conf was modified, the container was restarted, and the DNS cache was flushed on all clients the cache started working as expected.

[Glitch990]

I can confirm this is still happening on Comcast. Steam is repeatedly defaulting to HTTPS. The fix above #47 does not appear to be working anymore either. New docker images this morning.

[Leapo]

Yup, still happening. I've been working around this issue for years by having my firewall/router block the two domains I listed in my original post.

[Glitch990]

So let me ask you this. Are you running the SNIproxy? When I block those domains in my firewall without lancache running everything works over HTTP. But as soon as I start lancache or the sniproxy everything switches back to HTTPS. I'm guessing it has to with the external resolvers on the dockers. Do you sinkhole those two domains in your DNS resolve configuration?

[Leapo]

I'm not running sniproxy, just lancache. I'm only using it to cache Steam, so I have the following DNS settings:

lancache.steamcontent.com = lancache internal IP address
edge.steam-dns.top.comcast.net = 127.0.0.1
edge.steam-dns-2.top.comcast.net = 127.0.0.1

Seems to be working, but it's still a poor work-around.

[Glitch990]

I have figured out a "less than perfect" solution but it works surprisingly well. So I had to give up having my DNS resolver (Pfsense) do the forwarding, which is a big sacrifice. I am running SNIProxy, LANCache, and LANCache-DNS. I pointed my DHCP server at the LANCache-DNS for resolution. I have the SNIProxy, LANCache, and LANCache-DNS pointed to my router as the upstream. I then have two aliases in my firewall for the ComcastDNS addresses for both port 80 and 443 (I noticed that if any connection is made the subsequent connections try for HTTPS) and have those aliases blocked on the LAN side. This caches almost every game through LANCache (Battle Brothers does not cache).

[Glitch990]

I tried your method as well because I would really like to get back to using my DNS resolver on PFSense but it appears for me the solution only works if the game was already cached otherwise those three entries allow to much to not be cached. Unless I misinterpreted what you mentioning.

[Leapo]

Make sure you clear the DNS cache on your clients and restart Steam.

I had the same issue until I did that (I'm also using pfsense as my sole internal DNS server)

[Leapo]

Need to re-open this. Just blocking DNS resolution doesn't appear to resolve the issue anymore. Steam always fails-over to pulling data from Comcast (bypassing the cache) no matter what I try.

Downloads initially use the cache for about 30 seconds, then it just stops and tries using Comcast's servers instead. It's almost like Steam is hard-coded to try Comcast's servers...

[stale]

This issue has been automatically marked as inactive because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[ghost]

can confirm, sniproxy workaround appears functioning again

[stale]

This issue has been automatically marked as inactive because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically closed after being inactive for 30 days. If you require further assistance please reopen the issue with more details or talk to us on discord