Lame referral error on go mod download during docker build in RancherDesktop cluster

I encounter an error during my docker build on the "RUN go mod download" line that is downloading Golang dependencies. It usually fails with numerous lame referral errors like the following:

Error:

...
 => CACHED [builder 4/7] COPY go.sum go.mod Makefile /app/                                                                                              0.0s
 => ERROR [builder 5/7] RUN go mod download                                                                                                            18.5s
------
 > [builder 5/7] RUN go mod download:
#12 17.98 go mod download: github.com/aws/aws-sdk-go@v1.44.13: Get "https://storage.googleapis.com/proxy-golang-org-prod/6d16f241873ba42e-github.com:aws:aws-sdk-go-v1.44.13.zip?Expires=x&GoogleAccessId=gcs-urlsigner-prod%40golang-modproxy.iam.gserviceaccount.com&Signature=x": dial tcp: lookup storage.googleapis.com on 192.168.x.x:53: lame referral
...
------
executor failed running [/bin/sh -c go mod download]: exit code: 1

Every once in a while the docker build will work, but it almost always fails after 30s during this go mod download.

I'm within a corporate VPN. I can pull these dependencies directly from my Mac easily by directly running "go mod download", but docker build encounters this error very often. My teammates experience similar issues when they try to build as well from different regions. If we need to configure a docker proxy or add known_hosts, specific examples would be appreciated.

Dockerfile:

FROM golang:1.16.4-buster AS builder
ENV GOOS=linux GOARCH=amd64 CGO_ENABLED=1 GOPRIVATE="github.com/x"
ARG GITHUB_ACCESS_TOKEN

RUN mkdir -p -m 0600 /root/.ssh && \
  ssh-keyscan github.com >> ~/.ssh/known_hosts && \
  git config --global url."https://${GITHUB_ACCESS_TOKEN}:@github.com/".insteadOf "https://github.com/"

# separate for better caching purpose
WORKDIR /app
COPY go.sum go.mod Makefile /app/
RUN go mod download
COPY . .
RUN make install && make build
...

I'm not sure yet if this is a consistent fix, but I was able to resolve this for today via the following unfortunately long process:

1. minikube stop (minikube connects to my local RancherDesktop cluster)
2. re-start RancherDesktop (also updated it)
3. minikube start - this informed me that docker was out of disk space
4. minikube delete (maybe overkill, minikube ssh -- docker system prune might have worked)
5. minikube start
6. eval $(minikube -p minikube docker-env)
7. build and start my service/s (using Skaffold which utilizes Docker to build and Helm via minikube to deploy)

No lame referrals!