DNS errors with --force-renew and CNAME records

Help
1

I am having to renew certs due to the revocation issue. I have set up and renewed certs on this server with no issues in the past, with the same DNS setup. However, this time, I am getting DNS errors, which imply that an A record is required (I am using CNAME records, which normally work).

There are currently 2 domains reporting errors, previously there were more, so some previously problem domains are now OK, even though the DNS settings have not changed.

My domain is:

gocompose.camart.co.uk (failing)
gocompose.soundandmusic.org (failing)
(and others on the same cert that are working, eg soundam.camart.co.uk)

I ran this command:

certbot renew --force-renewal

It produced this output:

Attempting to renew cert (bmc.camart.co.uk) from /etc/letsencrypt/renewal/bmc.camart.co.uk.conf produced an unexpected error: Failed authorization procedure. gocompose.camart.co.uk (http-01): urn:ietf:params:acme:error:dns :: DNS problem: NXDOMAIN looking up A for gocompose.camart.co.uk - check that a DNS record exists for this domain, gocompose.soundandmusic.org (http-01): urn:ietf:params:acme:error:dns :: DNS problem: NXDOMAIN looking up A for gocompose.soundandmusic.org - check that a DNS record exists for this domain. Skipping.
All renewal attempts failed. The following certs could not be renewed:
/etc/letsencrypt/live/bmc.camart.co.uk/fullchain.pem (failure)

All renewal attempts failed. The following certs could not be renewed:
/etc/letsencrypt/live/bmc.camart.co.uk/fullchain.pem (failure)

1 renew failure(s), 0 parse failure(s)

IMPORTANT NOTES:

My web server is (include version):

Apache 2.4

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

Debian 9.9

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

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you’re using Certbot):

0.28.0

2

Using CNAME records is fine. But sometimes one or more your nameservers return the wrong CNAME record, pointing to a name that does not exist.

https://unboundtest.com/m/A/gocompose.camart.co.uk/KKCR4JZX

$ dig +dnssec +norecurse gocompose.Camart.co.uk @74.207.254.12

; <<>> DiG 9.16.0 <<>> +dnssec +norecurse gocompose.Camart.co.uk @74.207.254.12
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16450
;; flags: qr aa ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 2

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;gocompose.Camart.co.uk.                IN      A

;; ANSWER SECTION:
gocompose.Camart.co.uk. 3600    IN      CNAME   sam-memset.

;; ADDITIONAL SECTION:
sam-memset.Camart.co.uk. 3600   IN      A       78.31.105.243

;; Query time: 43 msec
;; SERVER: 74.207.254.12#53(74.207.254.12)
;; WHEN: Thu Mar 05 11:11:27 UTC 2020
;; MSG SIZE  rcvd: 103

$ dig +dnssec +norecurse gocompose.camart.co.uk @74.207.254.12

; <<>> DiG 9.16.0 <<>> +dnssec +norecurse gocompose.camart.co.uk @74.207.254.12
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10710
;; flags: qr aa ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 2

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;gocompose.camart.co.uk.                IN      A

;; ANSWER SECTION:
gocompose.camart.co.uk. 3600    IN      CNAME   sam-memset.camart.co.uk.

;; ADDITIONAL SECTION:
sam-memset.camart.co.uk. 3600   IN      A       78.31.105.243

;; Query time: 53 msec
;; SERVER: 74.207.254.12#53(74.207.254.12)
;; WHEN: Thu Mar 05 11:11:32 UTC 2020
;; MSG SIZE  rcvd: 103

Let’s Encrypt makes DNS queries with random capitalization. Your nameservers shouldn’t return the wrong results when they receive queries with a different case.

1 Like
3

Hi @camart

unboundtest reports a curious answer:

https://unboundtest.com/m/A/gocompose.camart.co.uk/TB7GJYMI

;; ANSWER SECTION:
gocompose.camart.co.uk. 0 IN CNAME sam-memset.

So the result is a NXDOMAIN.

Try the same "trick" I've shared yesterday.

Change your DNS, remove the CNAME, create an A record with the ip address of sam-memset.camart.co.uk = 78.31.105.243 (from https://check-your-website.server-daten.de/?q=gocompose.camart.co.uk ), then try to create a certificate.

1 Like
4

Thanks Juergen,

That's a very useful tool, thanks.

Strange, I but I get the DNS output below, with a NOERROR response

I can try the A record trick for this case, but I don't know what I'm going to do about another server which uses a LOT of CNAME domains.

It's not clear to me yet whether the issue is with my DNS provider, or the resolver at LE. I'll keep digging (in every sense)

A.P.

dig A gocompose.camart.co.uk

; <<>> DiG 9.5.1-P3 <<>> A gocompose.camart.co.uk
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45713
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 4, ADDITIONAL: 0

;; QUESTION SECTION:
;gocompose.camart.co.uk. IN A

;; ANSWER SECTION:
gocompose.camart.co.uk. 74 IN CNAME sam-memset.camart.co.uk.
sam-memset.camart.co.uk. 3600 IN A 78.31.105.243

;; AUTHORITY SECTION:
camart.co.uk. 172800 IN NS dns4.mtgsy.com.
camart.co.uk. 172800 IN NS dns3.mtgsy.com.
camart.co.uk. 172800 IN NS dns2.mtgsy.co.uk.
camart.co.uk. 172800 IN NS dns1.mtgsy.co.uk.

;; Query time: 269 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Mar 5 11:29:51 2020
;; MSG SIZE rcvd: 172

5

I see a really strange answer section, though:

; <<>> DiG 9.11.14-3ubuntu1-Ubuntu <<>> @dns1.mtgsy.co.uk. gocompose.camart.co.uk
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30392
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;gocompose.camart.co.uk.		IN	A

;; ANSWER SECTION:
gocompose.camart.co.uk.	3600	IN	CNAME	sam-memset.
gocompose.camart.co.uk.	60	IN	A	54.72.52.58

;; AUTHORITY SECTION:
.			86400	IN	SOA	a.root-servers.net. nstld.verisign-grs.com. 2020030500 1800 900 604800 86400

;; Query time: 3 msec
;; SERVER: 172.105.69.234#53(172.105.69.234)
;; WHEN: gio mar 05 12:55:11 CET 2020
;; MSG SIZE  rcvd: 166

a CNAME, if it exists, is supposed do be the only record for that hostname

6

Ah. That's different than what I got! And your query was entirely lowercase, too.

We got odd behavior just using dig to manually send queries to the domain's authoritative nameservers -- the queries Let's Encrypt sends could exacerbate their issues, but the authoritative nameservers are certainly broken on their own.

7

Thanks Matt, Pepe,

Strange behaviour from my DNS provider indeed!

8

Strange reply from my DNS provider's support:

As for your DNS records you can't perform a direct "A" type lookup on a CNAME record, you will not get a valid response, hence the responses from the site you are using.

I'm pretty up to speed on basic DNS, but this is becoming too deep for me.

The reply from my DNS provider implies that the change is at the LE end, they shouldn't be explicitly asking for an A record in their DNS query (in case there isn't one, only a CNAME), and therefore ALL CNAME domains could potentially have difficulty.

Is this plausible?

9

That is not how DNS works. It may be how their servers work, but it's not how compliant DNS implementations work.

The point of CNAME records is that the client can send a query with an arbitrary type and the server responds with the CNAME record (and optionally other information related to the destination*).

It would be inefficient if clients had to make two queries, one for CNAME and one for whatever type they really wanted, for everything.

Here's an example:

$ dig +norecurse www.facebook.com @a.ns.facebook.com

; <<>> DiG 9.16.0 <<>> +norecurse www.facebook.com @a.ns.facebook.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7808
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.facebook.com.              IN      A

;; ANSWER SECTION:
www.facebook.com.       3600    IN      CNAME   star-mini.c10r.facebook.com.

;; Query time: 0 msec
;; SERVER: 2a03:2880:fffe:c:face:b00c:0:35#53(2a03:2880:fffe:c:face:b00c:0:35)
;; WHEN: Thu Mar 05 12:46:07 UTC 2020
;; MSG SIZE  rcvd: 102

That is valid.

You're provider's stuff is... not.

* Not to mention DNSSEC, which is not involved here.

10

I smell first-level helpdesk bullshit.

11

@camart:

is your CNAME record
gocompose 3600 in CNAME sam-memset
or
gocompose 3600 in CNAME sam-memset.
?

If it’s the second, remove the dot.

Because it looks like some resolvers, including mine and cloudflare’s, correct this error, but others don’t.

12

(sniff, sniff) … by jove, I think you’re right!

so NXDOMAIN is not a reasonable response to an EXPLICIT “A” request on a domain without an A record?

13

Resolvers aren't correcting it, the authoritative nameservers are just returning the correct thing sometimes. :grimacing:

1 Like
14

Your provider isn't actually returning NXDOMAIN -- they're just returning the wrong CNAME record and some other nonsense.

Resolvers return NXDOMAIN because "sam-memset." is not a TLD that exists.

(When resolvers follow CNAMEs, the response code is based on the ultimate destination.)

15

I was just investigating the same thing (dot suffix)

That DNS (with the dot suffix) is the DNS I am NOT in control of, I think it was set up incorrectly, I’ll see if I can get that changed

… though it doesn’t explain https://unboundtest.com/m/A/gocompose.camart.co.uk/OMPHW4HA … this is the DNS I am in control of, and it definitely isn’t configured with a dot suffix

16

sam, that dns record is on the gocompose hostname. can you edit which cname it points to?

17

Ah, thanks Matt, that makes sense

18

peppe, gocompose.camart.co.uk I can edit at will

19

remove the dot from the cname record, then :smiley:

20

it doesn’t have a dot in the configuration panel!

However, I have tried the opposite approach - fully qualifying the CNAME…