March 16, 2008

Testing Your Internet Connection for ISP DNS Diversions

Greetings. Over at the Network Neutrality Squad, the issue of ISPs intercepting and/or diverting DNS (Domain Name Service) lookups has recently risen to the surface. Some tests that you can perform to investigate this for yourself on your ISP are described below.

Increasingly, ISPs have been attempting to monetize users' Web browsing in various ways, and steering them to ISP-partnered search engines in cases of mistyped domain names and the like is just one example of this activity.

There is a great deal of variation in how this is accomplished; whether or not effective opt-outs are available; and how forthright, opaque, or simply confused ISPs' tech support pages and people may be regarding this matter.

Beyond the issue of shunting users to search engines of the ISPs' own choosing, diversion of DNS requests can have significant negative impacts on various applications, especially non-browsing (non-http) applications.

In some cases, ISP DNS diversion can be bypassed simply by changing router and/or client DNS settings to those of your own choosing. But a particularly devious practice involves ISPs actually intercepting "port 53" UDP and/or TCP DNS traffic and rerouting it to their selected servers, making the most straightforward bypass techniques ineffective. This appears to be the situation disclosed today on the NNSquad Discussion List regarding HughesNet.

Testing for DNS interception can be somewhat tricky, but last night I set up a quick hack involving a "dummy" DNS test zone on an NNSquad server to make it a bit easier to accomplish, if you access to either the dig or nslookup utilities on your system.

On Linux, for example, you would enter the dig or nslookup commands directly on your normal shell command line.

Under Windows XP you can run nslookup via: Start->Run, then enter the word nslookup in the Run box, then click OK.

For Vista, use Start->All Programs->Accessories->Command Prompt to open a command window, then at the prompt enter nslookup followed by newline.

Under Mac OS-X (to use dig) first navigate to the Applications/Utilities folder, then launch, then enter the dig command.

Now for the actual tests. You want to run both TCP (zone transfer) and UDP (regular DNS lookup) tests, since it is quite possible that even when diversion is in place, it may not affect both UDP and TCP, though UDP diversion will be the typical focal point.

The correct zone output for the DNS test zone -- control.hq -- is available right here. These data entries (including the test zone name itself) are subject to change at intervals to discourage copying of this data into other servers in an attempt to dilute this test.

The tests involve doing DNS lookups and comparing the results with the official zone ip address entries (note the trailing "." following the "hq" in the entries below).

Using dig:

TCP: dig control.hq. axfr

UDP: dig control.hq.
dig aardvark.control.hq.
dig [ other host entries ending in hq. ]

Using nslookup ([enter] means the "enter" or "return" key):

nslookup [enter]
> server [enter]
> control.hq. [enter]              
(this is the UDP test)
> ls -d control.hq. [enter]       (this is the TCP test)
OR: If "ls" is not implemented in your version of nslookup, instead of "ls" use:
> set type=axfr [enter]
> control.hq. [enter]

When finished:
> exit [enter]

These are only examples of the possible tests -- feel free to run other combinations on the test zone as you wish. If you get back results that show the same ip addresses as the official test zone output (remember to verify these at the link since they're subject to change) then your DNS is probably not being diverted. If you get nothing back or in particular if you get different ip addresses back (as in that HughesNet example mentioned above), then that's a smoking gun for low-level DNS diversion.

Please report instances of suspected diversions -- in as much detail as possible -- directly to me. Thanks very much!

[ Wearing my NNSquad Moderator hat ... ]

Posted by Lauren at March 16, 2008 06:59 PM | Permalink
Twitter: @laurenweinstein
Google+: Lauren Weinstein