Stale TXT record on dns challenge unless 10 minute pause before validation

[cub_dj]

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

This has worked for a long time with a 25 seconds pause to allow propagation but recently starting having issues with TXT record validation. I've had to increase the pause to 10 minutes to avoid the stale TXT record. I can see the the correct/current TXT record at DNS Lookup Text Record - MxToolbox. The incorrect record is being returned in the validation step. I'm using the ansible acme_certificate module, community.crypto.acme_certificate module – Create SSL/TLS certificates with the ACME protocol — Ansible Community Documentation

My domain is: nyqa.labs.ctsservice.com

I ran this command:

• name: Get ACME challenge
  acme_certificate:
  account_email: ctsny-nfps@cubic.com
  account_key: "{{ cert_destination }}/letsencrypt_account.key"
  acme_directory: "{{ acme_url }}"
  terms_agreed: true
  acme_version: 2
  challenge: dns-01
  remaining_days: 15
  csr: "{{ cert_destination }}/{{ le_host }}.csr"
  fullchain_dest: "{{ cert_destination }}/{{ le_host }}.pem"
  register: acme_data

• name: Print validation value as msg
  debug:
  msg: "{{ acme_data.challenge_data[le_host]['dns-01']['resource_value'] }}"

  • name: Get certificate
    acme_certificate:
    account_key: "{{ cert_destination }}/letsencrypt_account.key"
    acme_directory: "{{ acme_url }}"
    terms_agreed: true
    acme_version: 2
    challenge: dns-01
    remaining_days: 15
    csr: "{{ cert_destination }}/{{ le_host }}.csr"
    dest: "{{ cert_destination }}/{{ le_host }}.pem"
    chain_dest: "{{ cert_destination }}/{{ le_host }}-chain.pem"
    fullchain_dest: "{{ cert_destination }}/{{ le_host }}-fullchain.pem"
    data: "{{ acme_data }}"

It produced this output:
ok: [ussanqnyccpa02] => {
"msg": "DsswLjZWLqyLvYGPHBbVp4PDIae5G0KZ1RyW42K2grk"
}

TASK [Get certificate]
fatal: [ussanqnyccpa02]: FAILED! => {"changed": false, "msg": "Authorization for dns:ussanqnyccpa02.nyqa.labs.ctsservice.com returned invalid: CHALLENGE: dns-01 DETAILS: Incorrect TXT record "globalsign-domain-verification=06F20193FEECC6EF220566A9DCB72C2D" found at _acme-challenge.ussanqnyccpa02.nyqa.labs.ctsservice.com;", "other": {}}

My web server is (include version): apache-tomcat-9.0.89

The operating system my web server runs on is (include version): Red Hat Enterprise Linux release 8.10 (Ootpa)

My hosting provider, if applicable, is: N/A

I can login to a root shell on my machine (yes or no, or I don't know): yes

I'm using a control panel to manage my site (no, or provide the name and version of the control panel): no

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): I'm using the ansible acme_certificate
ansible --version
ansible 2.9.27
config file = /home/ctsapp/new-york/ansible.cfg
configured module search path = [u'/home/ctsapp/.ansible/plugins/modules', u'/usr/share/ansible/plugins/modules']
ansible python module location = /usr/lib/python2.7/site-packages/ansible
executable location = /bin/ansible
python version = 2.7.5 (default, Jun 28 2022, 15:30:04) [GCC 4.8.5 20150623 (Red Hat 4.8.5-44)]

[orangepizza]

Well not much can do from CA side if godaddy nameservers are slow at applying updated dns record

[MikeMcQ]

Let's Encrypt validates from multiple points around the world. The DNS provider (GoDaddy?) must sync their authoritative DNS servers and give the correct response from each query location. LE queries the auth servers directly.

You aren't the first to report this kind of problem with GoDaddy recently. You should probably ask them whether this is temporary or the new service level.

[cub_dj]

I appreciate the feedback. Thank you. I've reached out to GoDaddy already but they haven't been very helpful. It may be time to move on to a more helpful/responsive provider.