Fiddler New Features – DNS Failover

Fiddler 2.2.9 introduces a ton of new features under the hood. The one I’m going to talk about in this quick note is called “DNS Failover.”

When a client attempts to connect to a web server, it must first resolve the hostname of the server (e.g. into an IP address to which a TCP/IP connection will be made (e.g. The Domain Name System (DNS) is typically used to perform this mapping. Now, it’s important to understand that a DNS resolution can return multiple IP addresses, and many clients will attempt to “fail over” between addresses if a TCP/IP connection to the first address returned cannot be made[1].

Prior to Fiddler 2.2.9, fail over was not supported, which meant that if a connection could not be made to the very first address returned from DNS, Fiddler would report a connection failure. Beyond the rare case where an individual server was temporarily unavailable, there were two other cases where this posed a real problem for Fiddler users.

  1. Cases where an Upstream Gateway Proxy relied upon DNS Failover
  2. The Visual Studio Development Server (Cassini) on Vista+

The problem with the Upstream Gateway Proxy was occasionally hit by Microsoft Employees. We’re all behind a proxy (let’s call it “ITProxy”) at work, and our IT department uses DNS to return more than ten IP addresses for ITProxy, so that if one proxy server is temporarily down, traffic will seemlessly flow to the next proxy in the list. Unfortunately, if the first proxy in the list was unavailable, Fiddler users would find all sites on the Internet unreachable because Fiddler would ignore the upstream proxy setting if the first returned IP address was unreachable. Without an upstream proxy, clients on our corporate network are not able to reach the Internet.

The problem with the Visual Studio Development Server is both more subtle and more interesting. The issue stemmed from the fact that Cassini listens only on the IPv4 interface (e.g. Windows Vista and Windows 7 enable IPv6 by default, and their DNS stacks are configured to return IPv6 addresses first. So, the address list for “Localhost” would return the addresses “[::1],” by default. Fiddler would attempt to contact Cassini using the IPv6 interface, find that it wasn’t listening, and immediately give up, refusing to fall back to the IPv4 address which was second in the list. Cassini users typically would work around this problem by using the virtual hostname “ipv4.fiddler” which, as you probably guessed, is treated as “” by Fiddler. Why not just use directly? Because that address is hardcoded to bypass proxies (like Fiddler) by many web clients, including .NET and WinINET/IE. (That is a topic for a future blog post.)

Fiddler 2.2.9 corrects this limitation by supporting DNS fail over. Fiddler will now attempt to connect to up to three different IP addresses returned from a DNS resolution before giving up and returning an error to the client.

If Fiddler is forced to rely upon DNS fail over when making a connection to a server, a Session Flag is added to the session-- it’s named x-DNS-Failover. If an attempt to connect to a Upstream Gateway Proxy fails during Fiddler's startup, a note will be put in the Fiddler Log tab so that the user may understand why they may not be able to reach Internet sites. If you'd like to disable the DNS fail over feature, you can set the preference to False.

That’s all for now…


[1]For instance, Internet Explorer will “fail over” up to 5 times per connection attempt; WinINET uses the INTERNET_OPTION_CONNECT_RETRIES option to determine how many attempts to make.

Comments (3)

  1. Mark Squires says:

    Hrm. Interest fact about the address being hard coded to bypass proxies. Thanks.

  2. Eli Allen says:

    How about an option to reorder the IP addresses DNS returns to make it easier to debug a site that uses DNS round robin for load balancing?

  3. EricLaw [MSFT] says:

    @Mark: Indeed; “localhost” is also configured the same way by default.

    @Eli: To configure Fiddler to use a particular IP address for a host, you can either use Tools > HOSTS, or you can set the IP address in the x-overrideHost Session Flag (and DIRECT in the x-overrideGateway flag).

Skip to main content