In some clusters, DNS will not resolve correctly due to Alpine not handling DNS resolution correctly. Alpine is used as a base image for cert-manager.
This is a critical problem as I'm unable to get this to work within my large Kubernetes cluster with Let's Encrypt.
There is a HUGE chain of issues that describe's what's happening. Essentially, Alpine does not resolve the DNS queries correctly and either returns incorrect queries, or (depending if the provider uses Cloudflare), returns them incorrectly.
After removing "net" (provided by Kubernetes) from /etc/resolv.conf, DNS now resolves correctly:
/ $ nslookup letsencrypt.org
nslookup: can't resolve '(null)': Name does not resolveName: letsencrypt.orgAddress 1: 126.96.36.199 a23-195-219-207.deploy.static.akamaitechnologies.comAddress 2: 2600:140a:0:384::ce0 g2600-140a-0000-0384-0000-0000-0000-0ce0.deploy.static.akamaitechnologies.comAddress 3: 2600:140a:0:3b0::ce0 g2600-140a-0000-03b0-0000-0000-0000-0ce0.deploy.static.akamaitechnologies.com/ $ ^C
I highly suggest changing the base image from Alpine (the current one) to Debian in order to resolve these DNS issues as at the moment, cert-manager is incompatible with Let's Encrypt due to DNS issues not being able to resolve correctly with the current Alpine image.
I'd honestly open a PR, but it looks like the Alpine image is being built somewhere else and is pushed to gcr.io.
Just FYI: cert-manager won't use Alpine's (musl) DNS resolver, it's fully statically compiled and uses Go's built-in resolver. So nslookup will tell you absolutely nothing about how cert-manager looks up DNS. You technically don't even need an OS to run it and I'm not sure why they include one.