If I request a certificate for a subdomain, and subdomain doesn’t have a CAA record, but the second-level domain does, I get an error stating that the domain doesn’t have a CAA record. I don’t think should be the case, since CAA records apply to subdomains. Is this an error in boulder implementation, or is this not a case and CAA records should be specified for every subdomain?
What, exactly, does the error say? Because not having a CAA record is not an error condition. However, if your DNS host responds with an error when queried, that is an error condition.
we need your domain name to check that.
As a domain’s CAA inherited to subdomain unless overided, if main domain’s CAA record doesn’t include LE as allowed then the the cert request for subdomain will be denied.
1 Like
Please show the full error message to better understand the problem.
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:
I ran this command:
It produced this output:
My web server is (include version):
The operating system my web server runs on is (include version):
My hosting provider, if applicable, is:
I can login to a root shell on my machine (yes or no, or I don’t know):
I’m using a control panel to manage my site (no, or provide the name and version of the control panel):
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you’re using Certbot):
1 Like
The error isn't saying that you don't have a CAA record, it's saying that there's a DNS resolution problem.
https://unboundtest.com/m/CAA/znc.tachibana.industries/DEKLJQ7Q
It's some sort of DNSSEC problem, but I'm not sure what.
You do have an NSEC record saying no subdomains at all exist, which is a catastrophic problem, but it doesn't look invalid to me.
tachibana.industries. 300 IN SOA ns1.vultr.com. dnsadm.choopa.com. 1550298527 10800 3600 604800 3600
tachibana.industries. 300 IN RRSIG SOA 13 2 300 20190228000000 20190207000000 34481 tachibana.industries. keJRl/4azqADVS+AAKGwYE8VfbB02G3fVBJBsCeRvWVGRUuTBW1RD/b5 rOIxvb6T17qIXy99zNNYjPEfrJx4HQ==
tachibana.industries. 3600 IN NSEC tachibana.industries. NS SOA RRSIG NSEC DNSKEY CAA
tachibana.industries. 3600 IN RRSIG NSEC 13 2 3600 20190228000000 20190207000000 34481 tachibana.industries. k4WUdQlZ8V965kyXXHNxMVBcXex+jL7+osxFudYTitNYbRy75YmUCqZZ kpmgq9POpNxBnwT61QxprmZCd+xBng==
You -- or the nameserver administrators -- need to run "sudo pdnsutil rectify-zone tachibana.industries" on the authoritative nameserver(s) and ensure that the zones are properly rectified after record changes in the future.
There's a good chance that will fix whatever problem is making negative responses invalid.
Edit: Maybe resolvers are simply unhappy because it's a NOERROR status code and an NXDOMAIN answer?
Not a good sign, since they're using Vultr's managed DNS.
I wonder if @anon51109878 might have better luck by disabling and re-keying their DNSSEC.
If you don't have low-level access to the DNS servers -- via the command line or API or a control panel -- you need to contact Vultr and get them to fix it.
In the meantime, you can disable DNSSEC and/or switch DNS providers, I guess.
Edit: You're not running a hidden primary nameserver, are you? I don't think Vultr's managed DNS supports that.
In short, allows server admin the full control the primary name server [which is not seen from Internet, nor known to the Internet].
What the internet sees are just authoritative secondaries of that [hidden] primary.
Then the Internet seen nameservers are the only nameservers for that zone.
[and the only place to make any required changes]
It seems to be different/fixed for me.
Moved onto different issues about the firewalling of your server.
What did you do?
Your webserver, yeah - https://letsdebug.net/znc.tachibana.industries/23633
But depends whether you intend to use DNS-01 or HTTP-01 challenge, of course.
DNSviz sometimes sees UDP problems with the IPv6 IPs of Vultr nameservers:
http://dnsviz.net/d/znc.tachibana.industries/dnssec/
…and sometimes it all looks OK…
[not enough eggs nor baskets]
Some people say, and many have heard, “never put all your eggs in one basket”.
If you understand that saying, then you should understand what I meant.
For those who don’t, I will try to explain both.
This expression generally refers to a “single-point-of-failure” with a very large impact scope.
[should something bad “happen” to that one basket, your may lose all your eggs]
The “not enough eggs nor baskets” was meant to infer that there is a very big “single-point-of-failure” in this design and attempted to analogize it with “having only one egg and only one basket”.
[The one DNS IP (being the single egg) and only one DNS provider (being the single basket)]
Given that:
When you only have one egg, it must go in only one basket (less you should break it!).
And that:
When you only have one basket, then all your eggs must go to that single basket.
Both of those cases are bad:
- Only one egg & only one basket
- More than one egg; But all in the same basket
But the first is clearly even worse than the second.
Where the second is already a well-known example of a very bad case scenario; as told and retold by many (“never put all your eggs in one basket”).
[where the second case could survive and overcome losing one egg, the first case would fail on any loss]
I saw this case just as that first one (with: just one egg and one basket).
And thus explains the footer message line: [not enough eggs nor baskets]
[more than two hundred words used to explain five words]
[and much like the comedian who has to “explain the joke”… this will (no doubt) fail to “get a laugh”]
[don’t ask me to explain any of that too - LOL]
1 Like
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.