Cleanup (and/or removal) of auth.staging.gitlab.com routing and resources
auth.staging.gitlab.com
is configured in Cloudflare DNS as a CNAME for staging.gitlab.com
, however, all requests currently just return 429.
From Slack conversation with @cmiskell:
According to our haproxy config (https://ops.gitlab.net/gitlab-cookbooks/chef-repo/blob/master/roles/gstg-base-lb-fe-config.json#L48) it should redirect to staging.gitlab.com. The request makes it to haproxy (not stopped at cloudflare), but gets a 403 there (no backend service for that host), which somehow gets turned into a 429 by the time it makes it back to the client. I know we have errorfile 403 /etc/haproxy/errors/429.http for the error message, but I'm not clear how that gets turned into a 429 error code.
It looks generally a bit messy; presumably just some legacy thing that has been superseded by other config and not noticed.
Is it still in use and should be fixed or can the DNS and associated configuration be removed?
This hostname came up while investigating patterns of traffic being reported from various sources, including Cloudflare, and only really seeing junk requests to this hostname.
cc @dawsmith