cert-manager: DNS01 CNAME support breaks wildcard support for nginx ingress

Describe the bug:

We have a wildcard domain pointing at an nginx ingress controller, which basically means that the wildcard domain resolves to an Elastic Load Balancer.

When trying to create the _acme-challenge record in the wildcarded domain, it sees the CNAME to the ELB and then tries to update the DNS in the ELB’s domain (us-west-2.elb.amazonaws.com).

I0817 02:04:31.075401       1 logger.go:73] Calling GetAuthorization
I0817 02:04:31.203160       1 logger.go:98] Calling DNS01ChallengeRecord
I0817 02:04:31.203193       1 prepare.go:279] Cleaning up old/expired challenges for Certificate staging/staging-phoenix-my-tls
I0817 02:04:31.203206       1 logger.go:68] Calling GetChallenge
I0817 02:04:31.436572       1 wait.go:66] Updating FQDN: _acme-challenge.example.com. with it's CNAME: ab06d0c81742111e8b745062d6efc4d9-1815477658.us-west-2.elb.amazonaws.com.
I0817 02:04:31.075401       1 logger.go:73] Calling GetAuthorization
I0817 02:04:31.203160       1 logger.go:98] Calling DNS01ChallengeRecord
I0817 02:04:31.203193       1 prepare.go:279] Cleaning up old/expired challenges for Certificate staging/staging-wildcard-tls
I0817 02:04:31.203206       1 logger.go:68] Calling GetChallenge
I0817 02:04:31.436572       1 wait.go:66] Updating FQDN: _acme-challenge.example.com. with it's CNAME: ab06d0c81742111e8b745062d6efc4d9-1815477658.us-west-2.elb.amazonaws.com.
I0817 02:04:31.436589       1 dns.go:93] Checking DNS propagation for "example.com" using name servers: [100.64.0.10:53]
I0817 02:04:31.472333       1 dns.go:100] DNS record for "example.com" not yet propagated
I0817 02:04:31.472460       1 dns.go:83] Presenting DNS01 challenge for domain "example.com"
I0817 02:04:31.481949       1 wait.go:66] Updating FQDN: _acme-challenge.example.com. with it's CNAME: ab06d0c81742111e8b745062d6efc4d9-1815477658.us-west-2.elb.amazonaws.com.
I0817 02:04:31.841210       1 helpers.go:201] Found status change for Certificate "staging-wildcard-tls" condition "Ready": "False" -> "False"; setting lastTransitionTime to 2018-08-17 02:04:31.841201695 +0000 UTC m=+9743.366825451
I0817 02:04:31.841235       1 sync.go:276] Error preparing issuer for certificate staging/staging-wildcard-tls: Failed to determine Route 53 hosted zone ID: Zone us-west-2.elb.amazonaws.com. not found in Route 53 for domain ab06d0c81742111e8b745062d6efc4d9-1815477658.us-west-2.elb.amazonaws.com.
E0817 02:04:31.841254       1 sync.go:197] [staging/staging-wildcard-tls] Error getting certificate 'staging-wildcard-tls': secret "staging-wildcard-tls" not found 
E0817 02:04:31.854121       1 controller.go:180] certificates controller: Re-queuing item "staging/staging-wildcard-tls" due to error processing: Failed to determine Route 53 hosted zone ID: Zone us-west-2.elb.amazonaws.com. not found in Route 53 for domain ab06d0c81742111e8b745062d6efc4d9-1815477658.us-west-2.elb.amazonaws.com.

Expected behaviour: The _acme-challenge TXT record is created in the wildcarded domain (example.com in the above)

Steps to reproduce the bug:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  annotations:
    certmanager.k8s.io/acme-challenge-type: dns01
    certmanager.k8s.io/acme-dns01-provider: route53
    certmanager.k8s.io/cluster-issuer: letsencrypt-staging
    kubernetes.io/ingress.class: nginx-external
  name: staging-frontend
spec:
  rules:
  - host: '*.example.com'
    http:
      paths:
      - backend:
          serviceName: staging-frontend
          servicePort: http
  tls:
  - hosts:
    - '*.example.com'
    secretName: staging-wildcard-tls

with a suitable nginx ingress controller pointing at an AWS ELB should do the trick

Anything else we need to know?:

The CNAME behaviour was introduced in #670 and the commit message is sufficient to understand the motivation behind the change, and there’s plenty of support for the change within #670 - as such I don’t know how best to fix this so that my use case is supported without breaking the use case that motivated #670.

cc: @gurvindersingh

Environment details::

• Kubernetes version (e.g. v1.10.2): 1.9.7
• Cloud-provider/provisioner (e.g. GKE, kops AWS, etc): AWS
• cert-manager version (e.g. v0.4.0): quay.io/jetstack/cert-manager-controller:canary
• Install method (e.g. helm or static manifests): static manifest

/kind bug