Name is required.
Email address is required.
Invalid email address
Answer is required.
Exceeding max length of 5KB

Burp Collaborator built-in DNS server responds with NOTIMP to CAA requests

Nicolas Grégoire Jan 28, 2019 11:02PM UTC

Hello! (tested on v.1.7.37)

During renewal of wildcard certificates from Let's Encrypt, there's two DNS-related events: the validation of the ACME challenge (synchronous) and the validation of CAA entries (asynchronous). Burp Collaborator currently supports none of them.

Validating the ACME challenge over DNS is doable: temporarily redirecting DNS traffic to another DNS server (dnsmasq, DNSchef, ...) capable of handling TXT records is enough. Adding the correct challenge to the server config is done via a certbot's hook (certbot being the official Let's Encrypt client) when renewal happens. Not super elegant (Collaborator DNS traffic is hijacked for a few seconds) but it works...

For CAA entries, the situation is worse because they may be checked _hours_ after the DNS validation. As said in, "[Let's Encrypt is] required by the baseline requirements & RFC 6844 to check CAA within 8 hours of issuance". So a temporary hijack of DNS traffic during will not work :-/

Everything would however go smoothly if the built-in Collaborator DNS server simply replied with an empty "NOERROR" message for CAA requests (see But the current behavior is to reply with "NOTIMP", wich is considered by some people as being in violation of RFCs (cf previous link). My understanding, supported by paragraphs 2.1.1 and 2.1.3 of , is that status code "NOTIMP" MUST be used for unknown _opcodes_, but not for unknown _qtypes_. Requests for unknown qtypes MUST be answered with an empty response and status "NOERROR", as already done by Collaborator for TXT records.

My current best setup for fully automatic renewal of Let's Encrypt wildcard certificates with Burp Collaborator requires sending all the DNS traffic to another service (in my case DNSchef), which only answers TXT (for ACME challenges) and CAA requests and proxies everything else to Collaborator. But there's a downside: Collaborator doesn't see the real source IP of DNS interactions anymore :-/

My short-term need? Collaborator answering CAA requests with NOERROR! A long-term feature request? Complete support of certificate renewal inside Collaborator, for example by reading the ACME challenge from the file system.

Thanks in advance,

Liam Tai-Hogan Jan 31, 2019 02:35PM UTC Support Center agent

Nico, we have this logged in our development backlog. We’ve made additional notes of your requirements. Unfortunately, we can’t provide an ETA.

Soroush Apr 19, 2019 10:55AM UTC
This is good to have - so +1 from me too

floyd Jun 03, 2019 05:21PM UTC
+1, not having let's encrypt support means spending money on commercial certs (costs) or not having a private collaborator (unprofessional) or weak workarounds as explained above

Post Your public answer

Your name
Your email address