Is there any way to pass validation if DNS Server does not respond to CAA?

Issuance Tech
1

Hello,

We were looking into using Letsencrypt certificates for some of our web services, however our infrastructure setup seems to have turned out to be somewhat special, so we seem not to be able to get around the ominous “DNS problem: query timed out looking up CAA” error. Now, the short question is whether there is any way to pass the validation, without changing our redundancy setup/infrastructure/software:

We have a firewall which has a “ISP provider redundancy” feature which is DNS based, so there is no need of doing BGP or similar to make our webservers accessible to the net on both providers in a redundant way. Basically, this means we have two different IP ranges for each provider, and our firewall tells the clients via DNS to which IP on which provider to connect to.

Our DNS zone setup for a redundant web server looks like this:

firewall1.domain.com.    A      1.1.1.1      ;IP Address of firewall in IP range of ISP1
firewall2.domain.com.    A      1.2.1.1      ;IP Address of firewall in IP range of ISP2
webserver.domain.com.    NS     firewall1.domain.com.
webserver.domain.com.    NS     firewall2.domain.com.

The firewall itself has a miniature DNS service running, which returns the A records with a low TTL for the webserver, depending on which ISP is online, or for both ISPs simultaneously. This DNS service responds to queries for A records only, and returns no response in all other cases (I think this is for security reasons). Also, there is no possibility to configure anything else there.

The zone itself is hosted externally, and we have no possibility to enter a CAA record there (option is missing in the web interface).

With dig I get a reply like this, the first is on the external DNS server, the second is the query directed to the firewall:

dig -t TYPE257 webserver.domain.com.@dns1.dnsprovider.com

; <<>> DiG 9.10.4-P2 <<>> -t TYPE257 webserver.domain.com.@dns1.dnsprovider.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24170
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;webserver.domain.com.                 IN      CAA

;; AUTHORITY SECTION:
webserver.domain.com.          3600    IN      NS      firewall1.domain.com.
webserver.domain.com.          3600    IN      NS      firewall2.domain.com.

dig -t TYPE257 webserver.domain.com.@firewall1.domain.com

; <<>> DiG 9.10.4-P2 <<>> -t TYPE257 webserver.domain.com.@firewall1.domain.com
;; global options: +cmd
;; connection timed out; no servers could be reached

Now, if I understood everything correctly, our problem is that the firewall does not respond with anything when the validation check follows the NS record for webserver.domain.com and queries the firewall for a CAA record.

Is there any way to get around this?

The firewall manufacturer is a large, well known company which will less likely change their software for one small customer for this exclusive use case.
The external DNS provider will also take his time to implement a new software version on our request so we can add a CAA record for webserver.domain.com in the main DNS zone.

Thank you in advance for your ideas.

Regards,
Marc

2

This is a serious defect in the firewall software. Not only Let’s Encrypt but also (at least according to their published policies) other popular CAs including Symantec should not issue for this domain based on its inability to answer CAA queries. If CA/B passes Gerv’s ballot on making CAA mandatory no CAs should ever issue for this domain at all.

Early in its history Let’s Encrypt actually whitelisted domains which were doing this, to allow them to use the service while they corrected the problem. I believe that whitelisting ended some time ago. Maybe someone from Let’s Encrypt can say for sure.

Note that saying “I have 0 matching records” (which is what a DNS server should do when asked about CAA if it hasn’t even heard of CAA or if no CAA records were added) is not the same as refusing to answer. Refusing to answer queries causes all sorts of mayhem, for example refusing to answer AAAA caused a big roadbump for IPv6 deployment. It’s unfortunate for you that you fell for the idea that somehow non-compliance is “for security reasons” when the reality is that these products are usually just poorly made and handle only the very simplest cases then punt on everything else.

1 Like
3

Hi @mposch, sorry to hear about the trouble you're running into!

Would you be willing to provide more details about the manufacturer and model of firewall? Sometimes it can be surprising how quickly enough voices calling for sanity can achieve change :slight_smile:

Is it safe to say that you're constrained from migrating away from your current DNS provider? There's unfortunately no way to bypass the CAA check done by Let's Encrypt for issuance.

4

This is correct - we've transitioned to making support for CAA DNS requests mandatory.

5

Also @tialaramex is completely right that eventually (maybe not long from now) all CAs may be required by CA/B Forum rules to implement this same policy. So fixing the firewall would be the safest course.

2 Likes
6

Hello,

Thank you all for your valuable input.

I do not necessarily think it is a defect. They have designed the software for a specific use: replying to requests for DNS "leaf nodes", not more and not less.

I think that they just did not think about this case, that there would be something, that needs to "crawl down" all NS records in the DNS infrastructure until it finds a matching leaf (A record) and queries for something else on the same level.

While I have never tried IPv6 records (we just had luck not to need IPv6 connectivity yet), I am sure that it will support AAAA queries if I configure IPv6 records. The manufacturer states the firewall generally supports IPv6.

Unfortunately no. I am bound by an agreement not to disclose any information about which software or hardware we are running in the company. Even though I have done my best to anonymize the information posted here, I'd rather not risk anything in this point.

Thank you, that was the short answer I was looking for. :slight_smile:
Unfortunately this means we cannot use Letsencrypt for now.

However as @schoen points out that this will be standard for all CAs soon, I will go though the procedure and open a bug request with the manufacturer and refer them to this post. Thank you for this final words too, I am sure this will give my request the necessary importance.

Regards,
Marc

1 Like
7

You're describing the AAAA queries that clients with IPv6 support, whether or not they have IPv6 connectivity, have been making for the last ten or fifteen years. I hope this buggy DNS server gives valid (empty) responses for that. :sweat:

8

Hmm, good point.
Clients with IPv6 should at least get any reply, would be much faster than waiting for a timeout.

I just checked that again with dig:
When I query the DNS service on the firewall for AAAA it runs into a timeout.
When I query any recursive DNS server for the same AAAA record it runs into a SERVFAIL after ~4000 msec.

That’s not very customer-friendly to let a dual-stack user wait for a DNS response for 4 seconds, until the browser can finally start loading the page.
I have just tried that on a client with IPv6 connectivity: as soon as I enable IPv6, it really takes ~4 secs. longer to load the page, in comparison to the page load time before that, when IPv6 was disabled.
As soon as I disable IPv6, page load times are normal again.

Thank you very much!
Marc

9

That is unfortunate but I can understand the spot you're in. I hope you can continue to internally pressure your company & vendors to support important standards like CAA. It's difficult to ratchet up the security of the PKI ecosystem when companies selling security products are actively impeding progress with incomplete support.

I hope that changes in the future and you'll be able to use our services. Good luck!

I'm going to close this thread since I expect further discussion related to the deficiencies of this particular anonymous vendor's firewall/DNS support won't be especially productive. Please feel free to open a new thread if you have other questions!