Route 53 does not support CAA records. Is there no way around this? Or is Let’s Encrypt just not an option for the folks using Route 53 for DNS?
Hi @treaves,
You don't have to be able to add CAA records to use Let's Encrypt, you just have to have an authoritative DNS server that does not return an error when asked about CAA. It's perfectly fine for the answer to be empty, it just can't be an error.
I don't believe Route53 is one of the authoritative servers that will return SERVFAIL for CAA lookups so you should be OK without having to do anything.
No, it does indeed return SERVFAIL. Which was why I created this post.
That would be a key detail to include next time.
1 Like
Like checking instead of assuming. 
Yes, I should have included that. For anyone that uses Route 53, they already know that, if they had encountered this. I guess I was hoping for someone from the Let’s Encrypt staff to speak up, as there are several threads similar to mine, all unresolved.
A response from Amazon in an AWS forum about this topic (that’s been going on for almost a year now) indicates that Route 53 will support CAA records before the CAB deadline on September 8. Doesn’t really help you now, I know, but just wanted to throw out that this should stop being an issue “soon”.
Official announcement post: https://forums.aws.amazon.com/ann.jspa?annID=4799
Thread where people have been hounding Amazon for a year now: https://forums.aws.amazon.com/thread.jspa?threadID=236806&start=75&tstart=0
Thanks for the info.
Really? Route 53 works fine in my experience.
$ dig mattnordhoff.win caa
; <<>> DiG 9.10.3-P4-Ubuntu <<>> mattnordhoff.win caa
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4739
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;mattnordhoff.win. IN CAA
;; AUTHORITY SECTION:
mattnordhoff.win. 3600 IN SOA ns-392.awsdns-49.com. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 3600
;; Query time: 163 msec
;; SERVER: ::1#53(::1)
;; WHEN: Thu Jul 20 20:52:53 UTC 2017
;; MSG SIZE rcvd: 126
1 Like
It’s possible they’re adding CAA support slowly across nameservers as they work towards fully implementing it, and you happened to be on the lucky side of that.
That’s possible. However it’s also possible that the OP screwed up somehow. It seems as though a surprising range of goofs with Route 53 cause SERVFAIL as the symptom.
FWIW, I run a number of domains on Route 53 and haven’t experienced any issues with the CAA check in the past > 12 months.
IIRC, some failure modes other than SERVFAIL will still show up as SERVFAIL from the point of view of Let’s Encrypt’s CA software. I think this includes DNSSEC issues - perhaps you still use glue records from a previous provider or something like that. Give the DNSSEC debugger a try.
(“It’s always DNSSEC” should be the new “It’s always DNS”.)
It’s one thing to support a given record type. It’s a different thing to run broken servers that don’t adhere to standards. Even the most ancient DNS server that knows nothing about CAA should answer properly when asked about it.
The proper reaction should be pressure to fix their service and not just a nice request to “support” CAA. Just to make that clear.
Could you provide the domain name for which you are getting SERVFAIL? I just tested one of my domains that uses Route53 and do not get SERVFAIL. You can use https://unboundtest.com/ to test using an Unbound instance configured similarly to Let's Encrypt.
I just tried from my local machine, and there I do not receive the SERVFAIL. I still do receive it on the machine where I am running certbot (the AWS EC2 instance). How very odd.
Ya, the domain in egagle.us .
Hm, https://unboundtest.com shows that as NXDOMAIN. This is strange…
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.