Preventing cert-manager from attempting DNS01 challenges using rewritten domains instead of ingress domains

[AlbinoDrought]

Hello, I'm encountering an issue that is resulting from a combination of cert-manager and my CoreDNS config. (See also compumike/hairpin-proxy#10 )

This issue can be reproduced by:

1. Get DNS01 challenges working for a domain like www.example.com
2. Rewrite www.example.com to a cluster-local address in your CoreDNS config, like rewrite name www.example.com com-example-prod-web.com-example.svc.cluster.local
3. When cert-manager renews the cert, it will try to write DNS records for cluster.local instead of example.com. At least for the DigitalOcean provider, this fails (we don't control cluster.local) and the certificate can't be renewed

Output of dig www.example.com -t A:

; <<>> DiG 9.11.5-P4-5.1+deb10u2-Debian <<>> www.example.com -t A
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56961
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: f0dc77a6fcc17669 (echoed)
;; QUESTION SECTION:
;www.example.com.		IN	A

;; ANSWER SECTION:
www.example.com.	5	IN	A	10.245.35.90

;; Query time: 0 msec
;; SERVER: 10.245.0.10#53(10.245.0.10)
;; WHEN: Mon Mar 08 21:29:22 UTC 2021
;; MSG SIZE  rcvd: 87

Output of dig www.example.com -t SOA:

; <<>> DiG 9.11.5-P4-5.1+deb10u2-Debian <<>> www.example.com -t SOA
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44314
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 75d0c41a6156e168 (echoed)
;; QUESTION SECTION:
;www.example.com.		IN	SOA

;; ANSWER SECTION:
cluster.local.		5	IN	SOA	ns.dns.cluster.local. hostmaster.cluster.local. 1615238203 7200 1800 86400 5

;; Query time: 2 msec
;; SERVER: 10.245.0.10#53(10.245.0.10)
;; WHEN: Mon Mar 08 21:29:32 UTC 2021
;; MSG SIZE  rcvd: 149

It appears that the translation may happen here:

• FindZoneByFQDN(www.example.com)
• Ingress FQDN replaced by cluster.local SOA, as appears in above dig output

I see at least a few ways to workaround this:

• Remove the rewrites from CoreDNS config
• Change the rewrites to keep original SOA records, only rewrite for A/AAAA queries (our intended usecase) - how?
• Force cert-manager to use something like 8.8.8.8 or anything else that doesn't include these rewrites
• Fork cert-manager, add some way to disable or bypass SOA check. I'm sure there is a reason this is done in the first place, but I don't know what it is. Does anyone have any info on why the FQDN specified on the ingress would be replaced by the SOA record?

Anybody else experience this, and if so, best resolution?

[dr4Ke]

Can we consider this an issue?

[derfabianpeter]

For what it's worth, we experience the same issue (just with a different DNS provider - IONOS in our case).