First Time Setup - Certificate Failure CAA Query Timeout

Hello!

I am attempting to setup on Caddy on Windows. When attempting to request certificates for the first time i receive the error below.

ctivating privacy features… 2018/12/04 15:55:58 [FQDN] failed to get certificate: acme: Error 400 - urn:ietf:params:acme:error:dns - DNS problem: query timed out looking up CAA for FQDN

Here is what the CAA record is for the domain in question.

0 issue “letsencrypt.org
0 issue “godaddy.com

When using a caddyfile without https the configuration works as expected. What additional troubleshooting can be performed to resolve the CAA lookup issue?

caddyfile config
subdomain.domain.com:443 {
proxy / http://123.456.789 {
transparent
}
errors c:\caddy\logs\error.log {
rotate_size 50
rotate_age 90
rotate_keep 20
rotate_compress
}
log c:\caddy\logs\access.log {
rotate_size 50
rotate_age 90
rotate_keep 20
rotate_compress
}
ratelimit * / 10 15 second {
/login
/webstart/jnlp
}
}

Hi @danorth, welcome to the Caddy community!

Who is your nameserver provider?

You can try running dig subdomain.example.com caa in your shell and let us know what you get.

Hey!

We are using DNSMadeEasy.

Just looking at the response that I’m recieving, and my caddyfile, the error I’m getting states that no CAA can be found for the address in question (subdomain.domain.com) which is correct as the CAA record is associated with just domain.com.

Should my opening line just include the domain only with the actual site I’m looking to run through Caddy be reference elsewhere?

CAA records set on a bare domain are inherited by their subdomains unless the subdomain presents a different CAA record.

The errors above don’t indicate there is no CAA record; they indicate that the nameserver LetsEncrypt tried to contact to retrieve the CAA record did not respond to them. Are you getting new errors since? If LetsEncrypt gets an authoritative response indicating no CAA record, it should happily issue the certificate.

I’m not 100% sure what the latter half of the sentence is asking for. The first line of your Caddyfile should always be the site you want to serve - the address you want people typing in their browser. Is this separate from the “actual site” you’re serving? Are you proxing to a different site maybe?

Thanks for the response. So there is an issue with the CAA lookup, however I’m not certain how this should be resolved.

Here’s the lookup for our root domain (culvers.com).

culvers.com. IN CAA
;ANSWER
culvers.com. 1799 IN CAA 0 issuewild “letsencrypt.org
culvers.com. 1799 IN CAA 0 issue “godaddy.com
culvers.com. 1799 IN CAA 0 issue “letsencrypt.org
culvers.com. 1799 IN CAA 0 issuewild “godaddy.com
;AUTHORITY ;ADDITIONAL

However if I do the same lookup for the subdomain I receive a lookup error. Shouldn’t the subdomain inherit the root domain configuration?

Do I have something syntactically incorrect with my CAA record?

What error do you receive?

Your name server shouldn’t be returning errors for a lookup to a subdomain for CAA records. It is valid to supply subdomain-specific CAA records.

That said, the DNS server will not return results for the bare domain for a request for the subdomain. It’s a specification of the CAA resource record that the apex record applies to subordinate domains, not a specification of the DNS system itself; a system that issues certificates (like LetsEncrypt) should check the apex record if the subdomain does not have any records.

The following example is a DNS zone file (see [RFC1035]) that informs CAs that certificates are not to be issued except by the holder of the domain name ‘ca.example.net’ or an authorized agent thereof. This policy applies to all subordinate domains under example.com.

$ORIGIN example.com
.       CAA 0 issue "ca.example.net"

RFC 6844 - DNS Certification Authority Authorization (CAA) Resource Record

None that I can see.

[quote=“Whitestrake, post:7, topic:4855, full:true”]

SERVFAIL

dig @1.1.1.1 hvac-ctrl-01.culvers.com caa

; <<>> DiG 9.11.5 <<>> @1.1.1.1 hvac-ctrl-01.culvers.com caa
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 44187
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1452
;; QUESTION SECTION:
;hvac-ctrl-01.culvers.com. IN CAA

;; Query time: 4026 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Mon Dec 10 14:51:48 Central Standard Time 2018
;; MSG SIZE rcvd: 53

Root Domain CAA Query

dig @1.1.1.1 culvers.com caa

; <<>> DiG 9.11.5 <<>> @1.1.1.1 culvers.com caa
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2644
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1452
;; QUESTION SECTION:
;culvers.com. IN CAA

;; ANSWER SECTION:
culvers.com. 1800 IN CAA 0 issue “godaddy.com
culvers.com. 1800 IN CAA 0 issue “letsencrypt.org
culvers.com. 1800 IN CAA 0 issuewild “godaddy.com
culvers.com. 1800 IN CAA 0 issuewild “letsencrypt.org

;; Query time: 24 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Mon Dec 10 14:54:07 Central Standard Time 2018
;; MSG SIZE rcvd: 176

Those results look good.

Bear in mind that 1.1.1.1 is not authoritative for your domain, those would be:

Name Server: NS10.DNSMADEEASY.COM
Name Server: NS11.DNSMADEEASY.COM
Name Server: NS12.DNSMADEEASY.COM
Name Server: NS13.DNSMADEEASY.COM
Name Server: NS14.DNSMADEEASY.COM
Name Server: NS15.DNSMADEEASY.COM
Name Server: DNS1.EASYDNS.COM
Name Server: DNS2.EASYDNS.NET
Name Server: DNS3.EASYDNS.ORG
Name Server: DNS4.EASYDNS.INFO

LetsEncrypt will be querying the above.

whitestrake at apollo in ~
❯ dig @NS10.DNSMADEEASY.COM culvers.com CAA

; <<>> DiG 9.10.6 <<>> @NS10.DNSMADEEASY.COM culvers.com CAA
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27877
;; flags: qr aa rd; QUERY: 1, ANSWER: 4, AUTHORITY: 4, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1280
;; QUESTION SECTION:
;culvers.com.			IN	CAA

;; ANSWER SECTION:
culvers.com.		1800	IN	CAA	0 issuewild "letsencrypt.org"
culvers.com.		1800	IN	CAA	0 issue "letsencrypt.org"
culvers.com.		1800	IN	CAA	0 issuewild "godaddy.com"
culvers.com.		1800	IN	CAA	0 issue "godaddy.com"

;; AUTHORITY SECTION:
culvers.com.		86400	IN	NS	ns13.dnsmadeeasy.com.
culvers.com.		86400	IN	NS	ns11.dnsmadeeasy.com.
culvers.com.		86400	IN	NS	ns10.dnsmadeeasy.com.
culvers.com.		86400	IN	NS	ns12.dnsmadeeasy.com.

;; Query time: 49 msec
;; SERVER: 208.94.148.4#53(208.94.148.4)
;; WHEN: Tue Dec 11 10:17:15 AEST 2018
;; MSG SIZE  rcvd: 264

Looks good. As for the subdomain:

whitestrake at apollo in ~
❯ dig @NS10.DNSMADEEASY.COM hvac-ctrl-01.culvers.com CAA

; <<>> DiG 9.10.6 <<>> @NS10.DNSMADEEASY.COM hvac-ctrl-01.culvers.com CAA
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33162
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 3
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1280
;; QUESTION SECTION:
;hvac-ctrl-01.culvers.com.	IN	CAA

;; AUTHORITY SECTION:
hvac-ctrl-01.culvers.com. 900	IN	NS	vdns1.culvers.com.
hvac-ctrl-01.culvers.com. 900	IN	NS	vdns2.culvers.com.

;; ADDITIONAL SECTION:
vdns1.culvers.com.	900	IN	A	71.13.132.242
vdns2.culvers.com.	900	IN	A	216.250.6.244

;; Query time: 50 msec
;; SERVER: 208.94.148.4#53(208.94.148.4)
;; WHEN: Tue Dec 11 10:21:33 AEST 2018
;; MSG SIZE  rcvd: 125

Exactly as expected.

I assume that 1.1.1.1 is returning SERVFAIL because it is not authoritative and the authoritative server did not return any CAA records, so it’s telling you it doesn’t have anything for you (but it can’t be 100% sure).

Alternatively, the recursive resolver at 1.1.1.1 wasn’t able to successfully query your name server for CAA records at the subdomain at all. That would imply some issue on Cloudflare’s end. It shouldn’t be important; your actual authoritative name server is returning the expected result, and that’s what LetsEncrypt will check.

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