All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
RackNerd IPs have anycast DNS problems with Google services; RackNerd refused an available fix
Summary
I discovered problems with RackNerd's IPs accessing Google services. RackNerd support gave up instantly. There is a way for the IP prefix originator to fix it, but RackNerd refused to try raising the issue with their IP originator (ColoCrossing?) citing support cost reasons.
Backstory
I bought one of RackNerd's specials in Seattle region recently. I was a bit disappointed to find out it was Cogent bandwidth and hosted by Colo Crossing which would have been red flags and would have normally avoided -- but I will take responsibility for that since I could have discovered that via the test IP provided and I just didn't think to.
That said, while Cogent bandwidth used to be notoriously terrible, some people have said here they are better these days, so I figure it is probably worth me giving them another shot. As for Colo Crossing, my concerns stem from their poorly handled data breach, but at least that's in theory less of an impact to me personally if RackNerd is managing their own colo'ed boxes.
So, I was surprised by the upstreams, but willing to try giving it a shot.
Google Anycast
Anyway, on testing the shiny new RackNerd Seattle VM, I noticed immediately the pings to 8.8.8.8 were not great (19ms instead of 1ms). At first I blamed this on Cogent, but the real reason for this was Google DNS anycast thinks my IP is in China instead of Seattle area. Thus 8.8.8.8 is giving wrong IPs for my location, sending the connection to Google's San Jose DNS server instead of using the Google Seattle DNS server.
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
1 75-127-12-201-host.colocrossing.com (75.127.12.201) 1.717 ms 1.747 ms 1.713 ms
2 10.6.0.89 (10.6.0.89) 1.564 ms 1.537 ms 1.511 ms
3 * * *
4 be3705.agr64.sea02.atlas.cogentco.com (154.24.10.249) 2.119 ms be2805.agr63.sea02.atlas.cogentco.com (154.24.8.229) 2.934 ms 2.869 ms
5 be2316.ccr21.sea02.atlas.cogentco.com (154.54.1.173) 2.819 ms be2347.ccr22.sea02.atlas.cogentco.com (154.54.171.149) 2.764 ms 2.722 ms
6 be2075.ccr21.sfo01.atlas.cogentco.com (154.54.0.233) 19.070 ms 18.552 ms 18.593 ms
7 be3670.ccr41.sjc03.atlas.cogentco.com (154.54.43.14) 19.540 ms be3669.ccr41.sjc03.atlas.cogentco.com (154.54.43.10) 19.618 ms be3670.ccr41.sjc03.atlas.cogentco.com (154.54.43.14) 19.577 ms
8 tata.sjc03.atlas.cogentco.com (154.54.12.126) 19.226 ms * *
9 192.178.71.230 (192.178.71.230) 22.599 ms 22.611 ms 22.695 ms
10 172.253.73.209 (172.253.73.209) 20.282 ms 20.192 ms 192.178.87.203 (192.178.87.203) 23.010 ms
11 209.85.243.113 (209.85.243.113) 19.902 ms 142.251.224.33 (142.251.224.33) 20.081 ms 142.251.224.189 (142.251.224.189) 23.144 ms
12 dns.google (8.8.8.8) 19.325 ms 18.966 ms 19.293 ms
More troublesome, connections to some google services will just totally fail because Google is returning Chinese IPs for some of their services for that IP (Google thinks the IP is in China, and thus returning IPs behind the Great Firewall).
dig @8.8.8.8 www.google-analytics.com
; <<>> DiG 9.18.39-0ubuntu0.24.04.2-Ubuntu <<>> @8.8.8.8 www.google-analytics.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38052
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;www.google-analytics.com. IN A
;; ANSWER SECTION:
www.google-analytics.com. 300 IN A 203.208.41.97 <-- Unreachable China IP
;; Query time: 57 msec
;; SERVER: 8.8.8.8#53(8.8.8.8) (UDP)
;; WHEN: Wed Nov 26 13:00:57 PST 2025
;; MSG SIZE rcvd: 69
I can work around this mostly by using cloudflare DNS instead of Google DNS to at least get routed to a US IP for google services, but long term, I would like to fix it properly since I generally prefer Google over Cloud Flare, and there may be other subtle breakages with google services or things that rely on google's data.
Attempted support remediation thus far
- I reached out to RackNerd to request assistance, and they informed me it was a Cogent routing issue that was out of their hands.
- I reached out to Cogent, no response (exactly what I expected from Cogent, tbh 🙄)
- I reached out to Google -- and actually got not one, but two responses (!). The first was a request for a lot of information I admittedly didn't get back to them yet on (creating packet captures, etc). On the second message from them, they informed me they had looked into it and that the issue was actually an issue with their geographical database. The IP prefix owner would need to sign up for the Google ISP portal to correct the IPgeo information. (Previously my assigned IP was in a China IP range, apparently). I was very impressed Google took the time to correspond with a random VM customer such as myself!
- I reached back out to RackNerd with the responses from Google, informing it was not a Cogent routing issue, but an IPGeo issue. I requested that they pick up the torch and either sign up for the Google ISP portal, or work with their upstreams / IP prefix owner to set the location correctly in Google ISP portal.
- RackNerd replied with a form letter to inform me that "support for your request is not included with your service plan" citing the low cost of unmanaged VPS and that it would not be financially sustainable to provide support for this request. (Context: I paid $100 to them for the VM)
- I have not yet tried to ask ColoCrossing directly. It seems to me the request should come from RackNerd since it's their IPs, and it would need collaboration from RackNerd anyway so the IP locations can be set up correctly with Google.
Conclusion / Thoughts
I feel like RackNerd dropped the ball on this. While I can understand requesting a support plan for many managed services (ex: troubleshooting a linux install or something), this is pretty firmly in the network management level IMO and something that likely affects more than just me as a customer. While this does take a small amount of time to prepare a ticket to ColoCrossing, it is very common for customers to use Google services / 8.8.8.8, so it seems like that would be a worthwhile investment.
I don't think fixing their IP range so it works correctly with one of the largest tech companies on the planet is something an individual VM customer should have to fork out extra for (or even be worried about directly). By the same token, it doesn't even feel particularly appropriate for me to try and figure out who the IP prefix owner is (HostPapa / ColoCrossing ? for what looks to be AS 36352) and contact them directly -- this request should come from their customer (RackNerd). If I am being unreasonable, feel free to call me out as such, but this seems like a typical network management task to me that is usually included with running a hosting service and not something I should be trying to figure out on my own as a random VM downstream customer.
By the same token, this post is not intended to be lambasting RackNerd. Given the reputations of their upstreams (HostPapa / ColoCrossing and Cogent), RackNerd may already know they can't get the IP Originator to be bothered to collaborate with Google on this. It is possible they previously tried, failed and didn't communicate this to me. Since we've seen poor behavior from ColoCrossing before, it would not surprise me if ColoCrossing didn't care to help with IP issues, and that's the reason RackNerd gave up so fast. They may already know it is a lost cause. Or maybe I am too hard on ColoCrossing without giving them a fair chance?
In any case, it would be nice if RackNerd could at least try to raise the issue with ColoCrossing and see if they are willing to go in Google's ISP database and fix RackNerd's IP locations.
Comments
All the MJJs made google think the IPs are chinese haha
I guess change your spawning server may help.
Congratulation on deploying Great Firewall
I have one vm in Seattle which is not from Racknerd/Colocrossing and has only single homed cogent. Its latency to 8.8.8.8 is also 20ms. It may be Cogent/Google problem. By the way how much do you pay? If Anycast latency is your concern, you need to find another not cheap providers.
This is kinda weird cuz it's not something a support guy should really be commenting on. Maybe bringing it to @dustinc will help,
It is a fair point, I paid only $100/year plan
Hi @WyvernCo — I haven’t reviewed your specific case yet (not sure which ticket # this ties to), but I’m more than willing to look into it. For what it’s worth, we have hundreds of IPv4 ranges in Seattle alone, so I’ll need to look to see if this is first impacting only a small handful, or all, etc. Once I have the details, we can absolutely engage upstreams and/or third parties like Google where appropriate, no problem there.
I’ll DM you shortly to gather a bit more info so I can understand the full context and what’s already been done by our support team, to ensure I’m not taking any redundant actions that were already attempted. We will go from there and sort things out, thank you for your patience and for working with us
Thank you for your fast reply, I will DM you my ticket number
You went into too much detail
The technician who read it thought it was a huge, complicated case
I am absolutely guilty of this :P
I should point out though that using Google DNS and Google services is pretty common. A lot of people use 8.8.8.8 as their primary DNS server, and they might have server-to-server queries to google analytics for purchase events, uploading files to google drive, etc. (In this setup, those calls would fail.)
Fake geolocation is a bit valuable. Transfer your server to someone who really needs to pretend to be in China.
Ah great. I will order few Seattle servers.
FWIW all the 3 racknerd IPs that I've had in the past had a terrible reputation. Every google search for instance would be captcha challenged