Checking if CAA query timed out problem exists without executing certbot

How can I implement a function that checks if CAA query timed out problem will occur when registering an SSL certificate for a domain name with certbot?

For example, the function should return true when given as the input. Because returns timeout (see check result here) when checking the CAA record for domain.
And the function should return false when the input is Because doesn’t return timeout (see check result here) when checking the CAA record for

I cannot trigger certbot directly to check if there’s a CAA query timed out problem with the given domain name. Because this function should be triggered before the given domain points the server of my company.

Here’s what I have done with node.js:

const dns = require('dns-socket')
const defaultDNS = ''  // My DNS server
const socket = dns()

function checkCaa (domainName) {
  console.log(`domainName: ${domainName}`)
    questions: [{
      type: 'CAA',
      name: domainName
  }, 53, defaultDNS, (err, res) => {
    console.error(`Error: ${err}`)
    console.log(`Response: ${JSON.stringify(res)}`)


dns-socket module can be found here.

I found my function returns different result when executing it for multiple times. This makes me difficult to determine if CAA query timed out problem will occur with the given domain name.

For example, when I run the function for the first time, it returns:

Error: Error: Query timed out
Response: undefined

And here’s the execution result when I run it for the second time:

Error: null
Response: {"id":57224,"type":"response","flags":386,"questions":[{"name":"","type":"CAA","class":1}],"answers":[],"authorities":[],"additionals":[]}

It seems that something got cached inside my DNS server.

Does any know any better ways to determine if CAA query timed out will occur before running certbot to register a domain name?

It seems like the most reliable way is going to be to run your own copy of Unbound using the config used in unboundtest, since it also mimics the production behavior of Let's Encrypt's VA.

Again, the Unbound config in unboundtest is tuned specifically to avoid this issue.

A hypothetical alternative would be to perform the iterative DNS lookup from the root servers using a DNS library manually, but considering that you also need to be validating DNSSEC as well as other policies, it seems like running Unbound as per the unboundtest project would be the most straightforward solution.

You could then use your node application to query the Unbound server in a similar way to what you are doing now, implementing your own 30 second (or however long) deadline.

1 Like

Thank you. I’ll give it a try :slight_smile:

I’m wondering where the cache is stored at.

If the cache is stored at the DNS server( in my case), how can unbound DNS resolver change the ttl value on the DNS server. Or does it mean that unbound DNS resolver doesn’t rely on my local DNS server? I mean it can convert domain name to its corresponding IP address by itself.

That’s right, it will resolve domains in a standalone manner, descending from the root servers.

The specific Unbound config that comes with unbound test does not rely on any intermediate caching resolvers, nor does it cache any results itself.

Hi, _az, thank you so much for your response.

I found that unbound-host -v -t CAA -C unbound.conf <domain> can also check if CAA query timed out problem will occur.

For domains that has no CAA query timed out problem, the output could be:
<domain> is an alias for <another_domain> (insecure)
<another_domain> has no CAA record (insecure)
<domain> has no CAA record (insecure)

For domains that has CAA query timed out problem, the output is:
Host <domain> not found: 2(SERVFAIL). (error)

For domains that doesn’t exist, the output is:
Host <domain> not found: 3(NXDOMAIN). (insecure)

I think I will let my node.js program to trigger unbound-host command instead of hosting an unboundtest server.
Because maintaining one more service in the production environment is a hard work.

Do you know if there’s any drawback or pitfall for using unbound-host instead of hosting an unboundtest server?

Sounds like a fine plan.

Make sure to test that you can run more than one instance of the unbound-host process concurrently, because unboundtest specifically is built to only perform one test at a time, guarded with a mutex. This is because of the port binding conflict on port 1053 that would occur otherwise.

I am not sure whether the problem of two unbound instances also applies to two unbound-host instances, so it’s something for you to check.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.