Cert-manager: [Azure DNS] DNS record for "mydomain.com" not yet propagated

Created on 8 Mar 2019  路  4Comments  路  Source: jetstack/cert-manager

Steps to reproduce the bug:
When using Azure DNS with multiple domains it is not clear from the documentation what to do in the ClusterIssuer. With only a single domain you specify hostedZoneName and this works fine. However with multiple domains, you're supposed to remove hostedZoneName completely as cert-manager should figure out the domain by itself.

When using cert-manager with multiple domains, the log line: DNS record for "mydomain.com" not yet propagated will occur again again and will _never_ be propagated though. The reason for this is that there is a bug where either the Azure API or cert-manager create the _acme-challenge TXT record wrong.

Instead of it being created as _acme-challenge.mydomain.com it is created as _acme-challenge.mydomain.com.mydomain.com in the DNS zone in Azure. The extra appended domain name is the culprit of why cert-manager never sees the DNS record propagated. If I rename/recreate to the correct TXT record, then cert-manager sees the propagation and then starts the issuing of the certificate.

Anything else we need to know?:
This could potentially also be a recent change in the Azure API as it seems like cert-manager is trying to resolve the correct TXT record.

Environment details:

  • Kubernetes version (e.g. v1.10.2): 1.12.4
  • Cloud-provider/provisioner (e.g. GKE, kops AWS, etc): AKS on Azure
  • cert-manager version (e.g. v0.4.0): 0.6.2
  • Install method (e.g. helm or static manifests): helm

/kind bug

kinbug

Most helpful comment

@tommy-dk I set up my clusterissuer (with cert-manager 0.6.6/0.6.2) to handle multiple azure zones via DNS-01 like this:

apiVersion: certmanager.k8s.io/v1alpha1
kind: ClusterIssuer
metadata:
  name: letsencrypt-prod
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    email: [email protected]
    privateKeySecretRef:
      name: letsencrypt-prod
    # SEE: http://docs.cert-manager.io/en/master/reference/issuers/acme/dns01/azuredns.html
    dns01:
      providers:
        - name: azure-1
          azuredns:
            clientID: 12345678-abcd-abcd-1234-abcd1234abcd
            clientSecretSecretRef:
              name: azuredns-config
              key: client-secret
            subscriptionID: abcd5678-abcd-abcd-1234-abcd1234abcd
            tenantID: dcba5678-abcd-abcd-1234-abcd12341234
            resourceGroupName: ExampleDns
            hostedZoneName: staging.svc.example.ca
        - name: azure-2
          azuredns:
            clientID: 12345678-abcd-abcd-1234-abcd1234abcd
            clientSecretSecretRef:
              name: azuredns-config
              key: client-secret
            subscriptionID: abcd5678-abcd-abcd-1234-abcd1234abcd
            tenantID: dcba5678-abcd-abcd-1234-abcd12341234
            resourceGroupName: ExampleDns
            hostedZoneName: example.ca
        - name: azure-3
          azuredns:
            clientID: 12345678-abcd-abcd-1234-abcd1234abcd
            clientSecretSecretRef:
              name: azuredns-config
              key: client-secret
            subscriptionID: abcd5678-abcd-abcd-1234-abcd1234abcd
            tenantID: dcba5678-abcd-abcd-1234-abcd12341234
            resourceGroupName: ExampleDns            
            hostedZoneName: example.co

I was then able to request one CERT with three subject-alternate wildcard domains, *.example.ca, *.example.co and *.staging.svc.example.ca.

apiVersion: certmanager.k8s.io/v1alpha1
kind: Certificate
metadata:
  name: example-staging-tls-secret
spec:
  secretName: example-staging-tls-secret
  issuerRef:
    name: letsencrypt-prod
    kind: ClusterIssuer
    commonName: "*.example.ca"
  dnsNames:
    - "*.staging.svc.example.ca"
    - "*.example.co"
    - "*.example.ca"
  acme:
    config:
      - dns01:
          provider: azure-1
        ingressClass: nginx
        domains:
          - "*.staging.svc.example.ca"
          - "staging.svc.example.ca"
      - dns01:
          provider: azure-2
        ingressClass: nginx
        domains:
          - "*.example.ca"
          - "example.ca"
      - dns01:
          provider: azure-3
        ingressClass: nginx
        domains:
          - "*.example.co"
          - "example.co"

All 4 comments

@tommy-dk I set up my clusterissuer (with cert-manager 0.6.6/0.6.2) to handle multiple azure zones via DNS-01 like this:

apiVersion: certmanager.k8s.io/v1alpha1
kind: ClusterIssuer
metadata:
  name: letsencrypt-prod
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    email: [email protected]
    privateKeySecretRef:
      name: letsencrypt-prod
    # SEE: http://docs.cert-manager.io/en/master/reference/issuers/acme/dns01/azuredns.html
    dns01:
      providers:
        - name: azure-1
          azuredns:
            clientID: 12345678-abcd-abcd-1234-abcd1234abcd
            clientSecretSecretRef:
              name: azuredns-config
              key: client-secret
            subscriptionID: abcd5678-abcd-abcd-1234-abcd1234abcd
            tenantID: dcba5678-abcd-abcd-1234-abcd12341234
            resourceGroupName: ExampleDns
            hostedZoneName: staging.svc.example.ca
        - name: azure-2
          azuredns:
            clientID: 12345678-abcd-abcd-1234-abcd1234abcd
            clientSecretSecretRef:
              name: azuredns-config
              key: client-secret
            subscriptionID: abcd5678-abcd-abcd-1234-abcd1234abcd
            tenantID: dcba5678-abcd-abcd-1234-abcd12341234
            resourceGroupName: ExampleDns
            hostedZoneName: example.ca
        - name: azure-3
          azuredns:
            clientID: 12345678-abcd-abcd-1234-abcd1234abcd
            clientSecretSecretRef:
              name: azuredns-config
              key: client-secret
            subscriptionID: abcd5678-abcd-abcd-1234-abcd1234abcd
            tenantID: dcba5678-abcd-abcd-1234-abcd12341234
            resourceGroupName: ExampleDns            
            hostedZoneName: example.co

I was then able to request one CERT with three subject-alternate wildcard domains, *.example.ca, *.example.co and *.staging.svc.example.ca.

apiVersion: certmanager.k8s.io/v1alpha1
kind: Certificate
metadata:
  name: example-staging-tls-secret
spec:
  secretName: example-staging-tls-secret
  issuerRef:
    name: letsencrypt-prod
    kind: ClusterIssuer
    commonName: "*.example.ca"
  dnsNames:
    - "*.staging.svc.example.ca"
    - "*.example.co"
    - "*.example.ca"
  acme:
    config:
      - dns01:
          provider: azure-1
        ingressClass: nginx
        domains:
          - "*.staging.svc.example.ca"
          - "staging.svc.example.ca"
      - dns01:
          provider: azure-2
        ingressClass: nginx
        domains:
          - "*.example.ca"
          - "example.ca"
      - dns01:
          provider: azure-3
        ingressClass: nginx
        domains:
          - "*.example.co"
          - "example.co"

@mikebridge: It seems like a better solution than creating ClusterIssuers for each domain, but it is still a workaround for a bug, considering the following has been said about hostedZoneName on Slack:

alternatively, if you don鈥檛 specify hostedZoneName then it should be auto-detected for you.

@tommy-dk Having it work when there's no hostedZoneName would certainly be nicer than having all the duplicated configuration. I had to take some guesses at how to do this last week since the slack channel seems to be locked down.

Just to follow-up, it now works in 0.8.0 to omit hostedZoneName.

Was this page helpful?
0 / 5 - 0 ratings