Html site deployed on google bucket giving error

Question

I deployed my html website using gcp bucket and godaddy. It was working fine but just few days back it starts giving this error on browser

{"error":{"code":404,"message":"Could not resolve / to a method.","status":"UNIMPLEMENTED"}}

When i check on bucket that url is working fine https://storage.cloud.google.com/www.autodealersbuddy.com/index.html

How can i fix it?

Answer 1

Google's guidance is to create a CNAME record for your domain pointed at c.storage.googleapis.com, and to configure your bucket containing the static site's assets with a name matching the FQDN you've set up (the latter of which you seem to have done).

Counter to this, the DNS record for your www subdomain (at least, the one that my local DNS server has for it) is pointing to an arbitrary IP:

% dig +noall +answer +multiline www.autodealersbuddy.com any
www.autodealersbuddy.com. 1800 IN A 34.120.131.3

A similar A record (with a lower TTL value) appears in your root zone as well:

% dig +noall +answer +multiline autodealersbuddy.com any
autodealersbuddy.com.   600 IN A 34.120.131.3
autodealersbuddy.com.   3600 IN NS ns49.domaincontrol.com.
autodealersbuddy.com.   3600 IN NS ns50.domaincontrol.com.
autodealersbuddy.com.   3600 IN SOA ns49.domaincontrol.com. dns.jomax.net. (
                2023061803 ; serial
                28800      ; refresh (8 hours)
                7200       ; retry (2 hours)
                604800     ; expire (1 week)
                600        ; minimum (10 minutes)
                )
autodealersbuddy.com.   3600 IN MX 10 mailstore1.secureserver.net.
autodealersbuddy.com.   3600 IN MX 0 smtp.secureserver.net.
autodealersbuddy.com.   3600 IN TXT "v=spf1 include:secureserver.net -all"
autodealersbuddy.com.   3600 IN TXT "google-site-verification=v1ytZYFq8PW919_c8YM8FtzYfOd7R0SkSEDxzapfm8Q"

Cursory research was inconclusive as to what exactly this IP maps to or where it comes from. If this news is surprising to you, you may want to invest some time to investigating whether the records were changed without your authorization, possibly in some form of DNS hijacking attack.

In any event, an update to your DNS settings to replace the A record that's currently there with the proper CNAME in accordance with Google's documentation is in order.

I confirmed this is the culprit by manually setting this CNAME record in my local DNS server and reloading your page, which then shows up as one might expect: