_acme-challenge as a CNAME: No TXT record?

Hello,

I’m trying to verify a domain using dns-01, having an _acme-challenge record that is a CNAME for a TXT record in a dynamic zone (working on a certbot patch to support this).

My domain is:
smtp.cuivre.fr.eu.org

I ran this command:
certbot --test-cert --dry-run --dns-rfc2136 --dns-rfc2136-follow-cnames --dns-rfc2136-credentials /etc/letsencrypt/dns-rfc2136/credentials.ini --agree-tos -m letsencrypt@thomas.quinot.org certonly -d smtp.cuivre.fr.eu.org

It produced this output:
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator dns-rfc2136, Installer None
Obtaining a new certificate
Performing the following challenges:
dns-01 challenge for smtp.cuivre.fr.eu.org
Waiting 60 seconds for DNS changes to propagate
Waiting for verification…
Cleaning up challenges
Failed authorization procedure. smtp.cuivre.fr.eu.org (dns-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: No TXT records found for DNS challenge

IMPORTANT NOTES:

  • The following errors were reported by the server:

    Domain: smtp.cuivre.fr.eu.org
    Type: unauthorized
    Detail: No TXT records found for DNS challenge

    To fix these errors, please make sure that your domain name was
    entered correctly and the DNS A/AAAA record(s) for that domain
    contain(s) the right IP address.

My web server is (include version):

The operating system my web server runs on is (include version):

My hosting provider, if applicable, is:

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

In addition, note that while certbot was waiting for propagation, I was able to confirm that the TXT record had been provisioned on the two name servers for the zone:

$ dig @ns1.quinot.org txt _acme-challenge.smtp.cuivre.fr.eu.org

; <<>> DiG 9.9.6-P1 <<>> @ns1.quinot.org txt _acme-challenge.smtp.cuivre.fr.eu.org
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60388
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 3
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;_acme-challenge.smtp.cuivre.fr.eu.org. IN TXT

;; ANSWER SECTION:
_acme-challenge.smtp.Cuivre.FR.EU.ORG. 7200 IN CNAME smtp.cuivre.fr.eu.org.challenges.dyn.cuivre.fr.eu.org.
smtp.cuivre.fr.eu.org.challenges.dyn.Cuivre.FR.EU.ORG. 120 IN TXT “km0kTwu_fKnEyPEQ-SMljfRJXvzsN_oM_pdRb9oUJOc”

;; AUTHORITY SECTION:
dyn.Cuivre.FR.EU.ORG. 7200 IN NS ns1.quinot.org.
dyn.Cuivre.FR.EU.ORG. 7200 IN NS ns4.quinot.org.

;; ADDITIONAL SECTION:
ns1.quinot.org. 3600 IN A 194.98.77.222
ns4.quinot.org. 120 IN A 81.57.40.110

;; Query time: 8 msec
;; SERVER: 194.98.77.222#53(194.98.77.222)
;; WHEN: dim déc 24 15:34:48 CET 2017
;; MSG SIZE rcvd: 322

(and same for ns4.quinot.org). I was also able to see the TXT record being served in response to some query from an outside server in a tcpdump trace.

I’m pretty confident I must be missing something obvious… Reading from past forum discussions, it seems to me that this is supposed to work…

(for those interested, the patch as WIP is at:


)

I’ll send a pull request once I understand what’s failing.

Check Certbot’s log, it should have some more information.

This is only a guess, but I have a… guess:

cuivre.fr.eu.org.  (unsigned)  6904  NS  ns1.quinot.org.
cuivre.fr.eu.org.  (unsigned)  6904  NS  ns1.rfc1149.net.
cuivre.fr.eu.org.  (unsigned)  6904  NS  ns3.quinot.org.
cuivre.fr.eu.org.  (unsigned)  6904  NS  ns4.quinot.org.

dyn.cuivre.fr.eu.org.  (unsigned)  7177  NS  ns1.quinot.org.
dyn.cuivre.fr.eu.org.  (unsigned)  7177  NS  ns4.quinot.org.

However, for queries for the dyn.cuivre.fr.eu.org. zone, ns1.rfc1149.net. and ns3.quinot.org. don’t serve a delegation to the other 2 nameservers. Instead they serve a NODATA NOERROR response for any query.

So approximately 50% of queries for dyn.cuivre.fr.eu.org. will fail.

Does the cuivre.fr.eu.org. zone have the correct NS records for the delegation?

Edit:

For example:

$ dig +norecurse @ns3.quinot.org _acme-challenge.smtp.cuivre.fr.eu.org txt

; <<>> DiG 9.10.3-P4-Ubuntu <<>> +norecurse @ns3.quinot.org _acme-challenge.smtp.cuivre.fr.eu.org txt
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40564
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;_acme-challenge.smtp.cuivre.fr.eu.org. IN TXT

;; ANSWER SECTION:
_acme-challenge.smtp.cuivre.fr.eu.org. 7200 IN CNAME smtp.cuivre.fr.eu.org.challenges.dyn.cuivre.fr.eu.org.

;; AUTHORITY SECTION:
cuivre.fr.eu.org.       120     IN      SOA     melchior.cuivre.fr.eu.org. hostmaster.cuivre.fr.eu.org. 2017122401 3600 600 3600000 120

;; Query time: 93 msec
;; SERVER: 5.39.82.72#53(5.39.82.72)
;; WHEN: Sun Dec 24 15:34:41 UTC 2017
;; MSG SIZE  rcvd: 173

See, it says the zone is cuivre.fr.eu.org., not dyn.cuivre.fr.eu.org..

The NS records in the error message from Let’s Encrypt in Certbot’s log should confirm that.

It should also work if you retry a few times.

2 Likes

Argh!

I knew it was something silly, and as expected the problem did sit between my chair and keyboard. A silly mistake in the zone file caused the NS records for “dyn” to not be sent to slaves: they were placed incorrectly with respect to a $ORIGIN clause, and as a result ended up being outside of the zone. Interesting that BIND did not reject the zone file…

Anyway, once the issue was fixed:
"IMPORTANT NOTES:

  • The dry run was successful."

Many thanks!

BIND cannot know what your intention is.

I’m not sure I see a legit use case for out of zone data in zone files, though. For the record, it appears that PowerDNS rejects them. named-checkzone will also generate a warning, although it won’t reject the file outright:

# named-checkzone cuivre.fr.eu.org cuivre.fr.eu.org.BAD
cuivre.fr.eu.org.BAD:20: ignoring out-of-zone data (dyn)

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.