starred/dehydrated
1
0
Fork 0
mirror of https://github.com/dehydrated-io/dehydrated.git synced 2026-01-11 22:30:44 +01:00
Code Issues 79 Packages Projects Releases 10 Wiki Activity

Issue with CAA DNS #325

New Issue
Closed
opened 2025-12-29 01:22:44 +01:00 by adam · 5 comments
adam commented 2025-12-29 01:22:44 +01:00
Owner
Copy Link

Originally created by @ccoenen on GitHub (Apr 8, 2018).

I currently can't renew my certificates. I am running dehydrated 0.6.1, it may be related to my recent addition of CAA records to my DNS server. But I ran a bunch of CAA testers (for example this one) over it, and they tell me, it's fine.

here's the error that's being produced:

DNS problem: SERVFAIL looking up CAA for (my domain name)

Or, somewhat longer:

$ dehydrated-letsencrypt-update
# INFO: Using main config file /etc/dehydrated/config
Processing www.(my domain) with alternative names: (my domain)
 + Checking domain name(s) of existing cert... unchanged.
 + Checking expire date of existing cert...
 + Valid till May  5 04:47:18 2018 GMT Certificate will expire
(Less than 30 days). Renewing!
 + Signing domains...
 + Generating private key...
 + Generating signing request...
 + Requesting new certificate order from CA...
 + Received 2 authorizations URLs from the CA
 + Handling authorization for www.(my domain)
 + Handling authorization for (my domain)
 + 2 pending challenge(s)
 + Deploying challenge tokens...
 + Responding to challenge for www.(my domain) authorization...
ERROR: Challenge is invalid! (returned: invalid) (result: {
  "type": "http-01",
  "status": "invalid",
  "error": {
    "type": "urn:ietf:params:acme:error:connection",
    "detail": "DNS problem: SERVFAIL looking up CAA for (my domain)",
    "status": 400
  },
  "url": "https://acme-v02.api.letsencrypt.org/acme/challenge/QbY4XmY--redacted---9z2os/413---2653",
  "token": "EhQRH2ub---redacted----L-xUsl4oR5nfs",
  "validationRecord": [
    {
      "url": "http://---redacted---/.well-known/acme-challenge/EhQRH2ubW---redacted----AjRLVEevPPwlL-xUsl4oR5nfs",
      "hostname": "www.(my domain)",
      "port": "80",
      "addressesResolved": [
        "---redacted---",
        "---redacted (v6)---"
      ],
      "addressUsed": "---redacted (v6)---"
    }
  ]
})
Originally created by @ccoenen on GitHub (Apr 8, 2018). I currently can't renew my certificates. I am running dehydrated 0.6.1, it may be related to my recent addition of `CAA` records to my DNS server. But I ran a bunch of CAA testers (for example [this one](https://caatest.co.uk/)) over it, and they tell me, it's fine. here's the error that's being produced: DNS problem: SERVFAIL looking up CAA for (my domain name) Or, somewhat longer: ```sh $ dehydrated-letsencrypt-update # INFO: Using main config file /etc/dehydrated/config Processing www.(my domain) with alternative names: (my domain) + Checking domain name(s) of existing cert... unchanged. + Checking expire date of existing cert... + Valid till May 5 04:47:18 2018 GMT Certificate will expire (Less than 30 days). Renewing! + Signing domains... + Generating private key... + Generating signing request... + Requesting new certificate order from CA... + Received 2 authorizations URLs from the CA + Handling authorization for www.(my domain) + Handling authorization for (my domain) + 2 pending challenge(s) + Deploying challenge tokens... + Responding to challenge for www.(my domain) authorization... ERROR: Challenge is invalid! (returned: invalid) (result: { "type": "http-01", "status": "invalid", "error": { "type": "urn:ietf:params:acme:error:connection", "detail": "DNS problem: SERVFAIL looking up CAA for (my domain)", "status": 400 }, "url": "https://acme-v02.api.letsencrypt.org/acme/challenge/QbY4XmY--redacted---9z2os/413---2653", "token": "EhQRH2ub---redacted----L-xUsl4oR5nfs", "validationRecord": [ { "url": "http://---redacted---/.well-known/acme-challenge/EhQRH2ubW---redacted----AjRLVEevPPwlL-xUsl4oR5nfs", "hostname": "www.(my domain)", "port": "80", "addressesResolved": [ "---redacted---", "---redacted (v6)---" ], "addressUsed": "---redacted (v6)---" } ] }) ```
adam closed this issue 2025-12-29 01:22:44 +01:00
adam commented 2025-12-29 01:22:45 +01:00
Author
Owner
Copy Link

@ccoenen commented on GitHub (Apr 8, 2018):

Now, I'm not entirely sure that dehydrated is at fault at all. But I don't have any idea how to proceed debugging this.

@ccoenen commented on GitHub (Apr 8, 2018): Now, I'm not entirely sure that dehydrated is at fault at all. But I don't have any idea how to proceed debugging this.
adam commented 2025-12-29 01:22:46 +01:00
Author
Owner
Copy Link

@karolaug commented on GitHub (Apr 8, 2018):

If you can state your domain name it would be easier to help you debug.
I have CAA set for my domains and have no problem at all.

@karolaug commented on GitHub (Apr 8, 2018): If you can state your domain name it would be easier to help you debug. I have CAA set for my domains and have no problem at all.
adam commented 2025-12-29 01:22:46 +01:00
Author
Owner
Copy Link

@jobe1986 commented on GitHub (Apr 8, 2018):

This does appear to be an issue either with your DNS host or with Let's Encrypt's servers. Though the latter is less likely as it would be affecting far more users of Let's Encrypt if it were.

So ultimately this is an issue you will likely need to take up with your DNS host.

Even telling us the domain name itself won't help much as all we will be able to determine is whether it is just CAA records that are failing, or if it's the whole domain that has an issue.

Though it is also possible that DNSSEC is improperly setup for the domain too. I experienced that issue when I attempted to issue a certificate for one of my domains and got a SERVFAIL back from Let's Encrypt which turned out to be because there was an erroneous DS record still recorded at the .net DNS servers for the domain in question so DNSSEC validation was failing.

@jobe1986 commented on GitHub (Apr 8, 2018): This does appear to be an issue either with your DNS host or with Let's Encrypt's servers. Though the latter is less likely as it would be affecting far more users of Let's Encrypt if it were. So ultimately this is an issue you will likely need to take up with your DNS host. Even telling us the domain name itself won't help much as all we will be able to determine is whether it is just CAA records that are failing, or if it's the whole domain that has an issue. Though it is also possible that DNSSEC is improperly setup for the domain too. I experienced that issue when I attempted to issue a certificate for one of my domains and got a SERVFAIL back from Let's Encrypt which turned out to be because there was an erroneous DS record still recorded at the .net DNS servers for the domain in question so DNSSEC validation was failing.
adam commented 2025-12-29 01:22:46 +01:00
Author
Owner
Copy Link

@lukas2511 commented on GitHub (Apr 8, 2018):

This definitively is not a dehydrated bug. As @jobe1986 said this is an issue with your DNS host or with Let's Encrypt's servers. If you don't think your dns host is at fault (you can easily test that using something like dig caa yourdomain.tld) you can ask the community or open an issue at https://github.com/letsencrypt/boulder/issues.

@lukas2511 commented on GitHub (Apr 8, 2018): This definitively is not a dehydrated bug. As @jobe1986 said this is an issue with your DNS host or with Let's Encrypt's servers. If you don't think your dns host is at fault (you can easily test that using something like `dig caa yourdomain.tld`) you can ask the community or open an issue at https://github.com/letsencrypt/boulder/issues.
adam commented 2025-12-29 01:22:46 +01:00
Author
Owner
Copy Link

@ccoenen commented on GitHub (Apr 9, 2018):

Just a note to people coming here from Google: It appears to have been my DNS setup after all. For one thing, the DNSSEC didn't sign my (new) CAA records fast enough. Then, those changes didn't propagate as fast as I would have thought, they were probably cached somewhere from previous attempts.

Most of this debugging was in the end "waiting for the records to propagte". Take your time. Do a lot of digging. DNSviz was also immensely helpful. Make sure to check the CAA line in the advanced options (screenshot below). This turned up the missing signature.

Also: the target domain of a CNAME may need its own CAA record, I can't say for sure if this solved it, because this happened somewhere along the way.

dnsviz where to find the CAA setting

@ccoenen commented on GitHub (Apr 9, 2018): Just a note to people coming here from Google: It appears to have been my DNS setup after all. For one thing, the DNSSEC didn't sign my (new) CAA records fast enough. Then, those changes didn't propagate as fast as I would have thought, they were probably cached somewhere from previous attempts. Most of this debugging was in the end "waiting for the records to propagte". Take your time. Do a lot of `dig`ging. [DNSviz](http://dnsviz.net/) was also immensely helpful. Make sure to check the CAA line in the advanced options (screenshot below). This turned up the missing signature. Also: the target domain of a CNAME may need its own CAA record, I can't say for sure if this solved it, because this happened somewhere along the way. ![dnsviz where to find the CAA setting](https://user-images.githubusercontent.com/124909/38525196-af9d381c-3c51-11e8-8f66-930b21277ef2.png)
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Complicated
bug
enhancement
help wanted
pull-request
Mirrored from GitHub Pull Request
 suggestions wanted
testing
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/dehydrated#325
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?