Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. https://crt.sh/?q=example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.
My domain is:
amarillo.colmena.biz
I ran this command:
amarillo# acme-client -vD amarillo.colmena.biz
My web server is (include version):
OpenBSD 6.3 / httpd
The operating system my web server runs on is (include version):
OpenBSD 6.3
My hosting provider, if applicable, is: Vultr.com
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.
Or, for that matter, "sudo pdnsutil rectify-all-zones" in case other zones are invalid.
And ensure that it doesn't happen again.
By the way, did you know colmena.biz has an odd SOA record that copies the nameserver and email address from the TLD? It's probably more or less harmless, but still.
I am not actually running my own DNS servers. I use those of my hosting provider. That's what a "vanity" DNS server is. That can certainly be changed if people are unhappy about it.
It would seem that surely the SOA record must be correct if the authority is willing to sign the record for DNSSEC. Doesn't the SOA record have something to do with the delegation from the parent authority?
The DNSSEC test at DNSSEC Analyzer - colmena.biz claims that nothing is wrong with the DNSSEC for colmena.biz. Another test at colmena.biz | DNSViz also indicates that the DNSSEC is valid for colmena.biz.
The SERVFAIL issue is not a normal thing, and appears to me to be some kind of internal issue at whatever recursive DNS server is in use at letsencrypt, which was reported back to acme-client. Perhaps it is only triggered via IPv6 or under certain circumstances, or for some other reason not all users experience it.
@mnordhoff, you mentioned pdnsutil. Do you have reason to believe the authoritative nameservers here are running PowerDNS? If so, they may need an upgrade, since PowerDNS has a known issue similar to this one.
Given the above, @justinacolmena I would recommend you contact your DNS provider and ask them to upgrade their PowerDNS install. You can link them to https://letsencrypt.org/docs/caa/ (in particular the CAA errors section) if it helps.
PowerDNS uses DNSSEC signatures that are valid for 3 weeks, Thursday to Thursday. That's usually my trick for checking. (And I run PowerDNS, so I just dig one of my own domains instead of checking a calendar to see what date Thursday is.) I don't know of any other signers that commonly behave the same way.
colmena.biz. 38400 IN RRSIG A 13 2 38400 20180524000000 20180503000000 43819 colmena.biz. bxNwUq34XourXzODxpZbwH+ha+mikcXxz8mNHSPBW66rS3MAgH6NdQ1/ ISyn0WjaJjLyO3k0y+ibvcwwhnbbGQ==
Upgrading won't necessarily help. The issue is that some methods of updating records automatically update the associated negative records and some don't., requiring you to rectify. If you don't, the negative records may no longer be valid. It's more a design limitation than a bug. I think newer versions handle it automatically under more circumstances, but still not all.
It's configurable. You can turn it off, customize it, or leave it at the default. I guess they've taken option 2, or have a more complicated DNS architecture.
Some DNS providers that are unfamiliar with CAA initially reply to problem reports with “We do not support CAA records.” Your DNS provider does not need to specifically support CAA records; it only needs to reply with a NOERROR response for unknown query types (including CAA). Returning other opcodes, including NOTIMP, for unrecognized qtypes is a violation of RFC 1035, and needs to be fixed.
The servers do reply with NOERROR. I am am starting to think the problem is that I currently only have a CAA record for the bare domain "colmena.biz" -- and that this is not automatically inherited for hosts or subdomains under that hierarchy. Every hostname apparently needs its own CAA record.
That's not accurate. I would say it like this: Let's Encrypt needs to receive a valid response for each FQDN that is part of the tree climbed for CAA. For instance www.example.com, example.com, com. However, the "valid response" thing is tricky. It can be either a non-empty CAA response, or it can be an empty CAA response. However, if DNSSEC is present on the domain name, it must validate.
At any rate, the spirit of your comment is right: Your easiest workaround for now may be to simply add a CAA record on each of your hostnames.
You have to ask them to fix their DNSSEC setup, then.
The SOA DNS server name is only used for a few things. Depending on how the authoritative DNS servers are configured, they might not use it at all, or things might mostly work even if it's invalid.
The SOA email address is only for human usage.
Neither of those tests queried the invalid records. And it can be difficult to make them do so.
It's not. Query any validating resolver for the name amarillo.colmera.biz and a record type that doesn't exist. (Since you added a CAA record, try TXT or something.)
(Edit: I misspelled your domain in this post but not anywhere else.)
See, now I remember that round-robin thing with DNSSEC, where each record in the zone is cryptographically chained somehow to the next (NSEC) -- like looking up a word in the dictionary, and if it's not in its place in alphabetical order, then it may be determined not to exist.
