Research Academy
My account Customers About Blog Careers Legal Contact Resellers
The Burp Suite User Forum was discontinued on the 1st November 2024.

Burp Suite User Forum

For support requests, go to the Support Center. To discuss with other Burp users, head to our Discord page.

SUPPORT CENTER DISCORD

How do I configure our DNS server to support a private Burp collaborator server?

Stijn | Last updated: Jun 16, 2016 03:46PM UTC

Dear all, We're running a Burp collaborator server on a subdomain of our testing domain. However, when running a health check, I get the following error message: "We communicated with the collaborator, and appeared to successfully record events, however when we attempted to retrieve the interaction records the expected records weren't there." Here's some info that might or might not be helpful. I have redacted the domain name and IPs. 123.456.789.012 is the external IP mapped from the firewall to the system. 192.168.1.4 is its internal IP. I have set up our main domain's DNS server as follows: burp.example.com. SOA ns1.burp.example.com. hostmaster@example.com. /serial 7200 3600 604800 1800 ~ burp.example.com. NS ns1.burp.example.com. ~ burp.example.com. MX 10 mail.burp.example.com. ~ burp.example.com. 123.456.789.012 ~ ns1.burp.example.com. 123.456.789.012 ~ mail.burp.example.com. 123.456.789.012 ~ *.burp.example.com. 123.456.789.012 ~ I set the following values in the Burp Client: Server location: burp.example.com Polling location: burp.example.com:9443 When performing a health check from our Burp client, I get the following results: Initiating health check Server address resolution - Success Server HTTP connection - Success Server HTTPS connection (trust enforced) - Success Server HTTPS connection (trust not enforced) - Success Polling server address resolution - Success Polling server connection - Success Verify DNS interaction - Error Verify HTTP interaction - Success Verify HTTPS interaction - Success In the past, our DNS config did not have the line with the wildcard (*.burp.example.com. 123.456.789.012 ~). Back then, I received the following health check results: Initiating health check Server address resolution - Warning Polling server address resolution - Success Polling server connection - Success Verify DNS interaction - Warning Verify HTTP interaction - Warning Verify HTTPS interaction - Warning Server version - Success The capture server hostname <long random string>.burp.example.com coult not be resolved to an IP address. Ensure that an appropriate DNS entry exists for the server. We successfully connected to Burp Collaborator polling service. Since we were unable to connect to the capture interface of the server, we could not verify that interactions could be retrieved. Below is the config of the collaborator server: { "serverDomain" : "burp.example.com", "workerThreads" : 10, "eventCapture": { "localAddress" : ["192.168.1.4", "127.0.0.1"], "publicAddress" : "123.456.789.012", "http": { "port" : 80 }, "https": { "port" : 443, "certificateFiles" : [ "keys/burpexamplecom.key", "keys/burpexamplecom.crt", "keys/intermediate.crt"] } }, "polling" : { "localAddress" : "192.168.1.4", "publicAddress" : "123.456.789.012", "http": { "port" : 9090 }, "https": { "port" : 9443, "certificateFiles" : [ "keys/burpexamplecom.key", "keys/burpexamplecom.crt", "keys/intermediate.crt"] } }, "metrics": { "path" : "minhnqzefv", "addressWhitelist" : ["127.0.0.1", "10.10.10.10", "987.654.321.098"] }, "dns": { "interfaces" : [{ "name" : "ns1", "localAddress" : "192.168.1.4", "publicAddress" : "123.456.789.012" }], "port" : 53 } } We have a wildcard certificate for *.burp.example.com, but this does not include burp.example.com itself. This results in a certificate warning when browsing to http://burp.example.com An nmap scan of burp.example.com shows ports 80, 443, 9090, 9443. When specifically scanning port 53, it shows up as Closed. As there's no real logging, except for the few cryptic DNS messages (like below), its nearly impossible to diagnose the issue. The DNS logging only appears when doing a manual DIG, but doesn't seem to appear when performing a health check. 2016-06-16 17:26:46.765 : Request received: <hex encoded request> 2016-06-16 17:26:46.766 : Sending response: <hex encoded response> I hope you can help. Kind regards, Stijn

PortSwigger Agent | Last updated: Jun 16, 2016 04:03PM UTC

The following line in your DNS configuration: *.burp.example.com. 123.456.789.012 ~ should not be necessary because if everything is working then the Collaborator will resolve everything under burp.example.com. The fact that you needed to add this line to get some parts of the healthcheck working suggests that your domain is not properly configured to use your Collaborator server as its authoritative DNS server. This is consistent with everything working aside from the DNS interaction. Everything appears to be resolving correctly but it is not the actual Collaborator server doing the resolving, so it never sees any DNS lookups. Running a network sniffer on the Collaborator machine should confirm this. The evidence suggests that for some reason your domain is not properly configured to use your Collaborator server as its authoritative DNS server. This is registrar-specific and we would suggest reviewing your configuration with them, and their documentation, and maybe contacting their support to understand how to get things working.

Burp User | Last updated: Jun 16, 2016 05:00PM UTC

Dear I do not fully comprehend why, but the following settings in our DNS seem to have fixed the issue. Our DNS server uses different configuration files which you can link to a domain, i.e. > csv2["example.com."] = "db.example.com" > csv2["burp.example.com."] = "db.burp.example.com" I was configuring all our DNS settings for the Collaborator domain in db.burp.example.com By following some vague information I found on the internet, I decided to comment out the entry for "burp.example.com." in the DNS config and edited the config file for "example.com.". I added the following lines > burp.example.com. NS ns1.burp.example.com. ~ > ns1.burp.example.com. 123.456.789.012 ~ This still didn't seem to work. So I added 1 more line to that same config: > *.burp.example.com. 123.456.789.012 Now all queries are resolved by the Collaborator DNS server. In the end, it seems like I was on the right track with my DNS settings, but I had to add them to the DNS config of the main domain instead of creating a config for the subdomain. I now finally get all green in the health check :) Thank you for your support. It because of your answer that I adapted my search queries enough to find the documentation I needed. Kind regards Stijn

PortSwigger Agent | Last updated: Jun 17, 2016 07:57AM UTC

Glad you got things working. Let us know if you run into any other problems.

Burp User | Last updated: Apr 20, 2019 11:37AM UTC