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

Burp triggers DNS queries despite using an upstream proxy

Alexandre | Last updated: Jun 10, 2015 11:34AM UTC

Hi, We are experiencing performance issues with Burp, with some web application pages taking over a minute to load. After investigation, we found out that Burp was issuing local DNS requests which could not be resolved due to our setup: the browser and Burp are installed on a machine located in network A and web requests have to transit over a proxy to reach the web application located in network B. The machine hosting Burp is configured to resolve to a DNS server located in network A, which does not provide name resolution for network B. Burp issues a DNS resolution request for each accessed domain of the web application, despite being behind a proxy and having no access to host resolution for network B. The observed pattern was - A third party domain located in network B (let’s call it example2.intra), is embedded in the tested webapp page - The page on this domain issues a 302 redirecting to another domain (e.g. example3.intra) - DNS requests for example3.intra would be sent on the network on a regular interval (ever 2 seconds for e.g. 8 seconds in total) - As no answer is received for this request, Windows switches to NetBIOS based name resolution and attempts again to resolve the domain, without success for another 10 seconds or so - Finally, after 20 secs of delays (in my setup) and only then, the GET request to the domain (e.g. example3.intra) is sent on the network and can be seen using Wireshark The web application audited in this case embedded resources from over 10 different domains. DNS resolution failures would be sometimes cached locally for a while, accelerating the page load for a while. A fix for this issue is to install a fake DNS server on the same machine as Burp, which responds all DNS queries by a fake IP. This has no impact on Burp, as name resolution is anyway done by the proxy. In my setup, I did a quick PoC using Mandian's ApateDNS, which solved the long delays I was experiencing. Taking out Burp of the setup (e.g. browser – proxy) works well and no DNS queries for domains of network B can be seen on the wire. A colleague pointed out to the following article as a possible source for those unexpected/unwanted DNS requests: https://corner.squareup.com/2015/05/okhttp-2-4.html […] Ew! Calling URL.equals() also does a DNS lookup, which is bad for both performance and correctness. This is a longstanding bug, and it’s bizarre that it remains unfixed two decades later. […] I wasn’t able to find any related settings in Burp Suite - out of context option "Do DNS lookups over SOCKS proxy" does not work in this case. Full setup details for these performance issues: - Windows 7 VM, NATed to the host located in the network A - Chaining done as following: Firefox <-> Burp <-> Proxy server <-> webapp located in network B - Running the latest x64 Java (1.8.0_45) & Burp version (1.6.18) - Root CA of Burp imported in the browser - No third party plugins loaded in Burp - Proxy server is running a recent version of Squid, supporting HTTP/1.1 Many thanks for your help, Alex

PortSwigger Agent | Last updated: Jun 15, 2015 02:20PM UTC

Thanks for this detailed report. Even though Burp doesn't need to resolve hostnames to IP addresses when using an upstream proxy, it does do this in any case to provide the information to the user, and also to support some types of scope rules and proxy interception rules (which might be IP-based). We could possibly add an option to disable any local domain name resolution when an upstream proxy is being used. In the meantime, another workaround would be to configure within Burp arbitrary IP addresses for each of the domain names that are causing problems. You can do this at Options / Connections / Hostname resolution. If the list isn't too long, this is probably easier than deploying your own DNS server.

Burp User | Last updated: Jun 18, 2015 08:59AM UTC

Many thanks for your response. Your suggestion of having an option to disable local domain name resolution would be great. Configuring manually a hostname resolution entry for each domain name wasn't doable in a few recent cases, as we had 10's of different domains embedded into the web application. We had a look in the Burp Extender API to see if we could automate this via an extension. Unfortunately this kind of settings doesn't seem to be exposed for extensions. We're currently engaging the following mitigation techniques aside the usage of a DNS server faking responses (e.g. ApateDNS, as mentioned above): - Increase of the timeout value for "failed domain name resolution" in Options / Connections to e.g. 900 (15 minutes) - Usage of a SOCKS instead of a web proxy (when possible - but here as well we had some performance hits) Having an option to disable the local DNS lookups when the request transits over an upstream proxy would definitely be welcomed.

Burp User | Last updated: Sep 12, 2015 04:33PM UTC

Hi there ... we have the same Problem here in our Environment. It would be realy a super cool feature to be able to disable local DNS lookups! THX Lofi

Burp User | Last updated: Mar 22, 2016 08:03AM UTC

I'd also welcome such a feature.

Burp User | Last updated: Mar 22, 2016 08:50AM UTC

Me too, +1 for the option to control the local DNS resolution.

Burp User | Last updated: Mar 22, 2016 09:53AM UTC