Home / Blogs

Just Say No, to Your ISP Subverting Your DNS Queries

Over the past few weeks I have been seeing reports that some ISP's are actually subverting DNS queries to their own DNS server. Oh the humanity! What this means is that when you (your computer) does a UDP or TCP Port 53 DNS query the ISP is intercepting that and directing it to their own servers. Has anyone been told by their ISP that they are doing this? No? I didn't think so. Subversion of DNS, even for your own good, is not a good thing. This has the effect of controlling wherever you go on the internet. It is a good thing our ISP's know better than we do. Not!

I need your help here. I would like you to run some simple tests and report your results to me. I need you to run an NSLOOKUP or DIG to a specific name server on a specific zone that the DNS has not been made aware of. Using the zone for the query will cause any subverted queries to return non-existent domain (NXDOMAIN). If you have a few minutes please go to the following link on my home page and give it a try. Go to http://www.paulparisi.com/queryproject and input your findings. Once we get a critical mass we will start to publish the report.

By Paul Parisi, Chief Technology Officer at DNSstuff.com

CircleID Newsletter The Weekly Wrap

More and more professionals are choosing to publish critical posts on CircleID from all corners of the Internet industry. If you find it hard to keep up daily, consider subscribing to our weekly digest. We will provide you a convenient summary report once a week sent directly to your inbox. It's a quick and easy read.

I make a point of reading CircleID. There is no getting around the utility of knowing what thoughtful people are thinking and saying about our industry.

VINTON CERF
Co-designer of the TCP/IP Protocols & the Architecture of the Internet

Comments

Or not... By David A. Ulevitch  –  Jun 26, 2009 5:22 pm PDT

Paul, I think it's a great idea to expose this stuff but there's a better way to do it than through a form on your personal website.

ICSI at Berkeley has been collecting large swaths of data about this for some time: http://netalyzr.icsi.berkeley.edu/ and will be coming out with reports soon.  I suggest we all coordinate efforts and recommend folks submit to the same place.  Also, all these tests should be automated, asking folks to run nslookup or dig is kinda a pain (and probably one of the many reasons your great site dnsstuff.com exists).

Based on an erroneous story By Jason Livingood  –  Jun 29, 2009 10:13 am PDT

Paul - I suspect this is based in part on the (incorrect) "story" on Slashdot a couple weeks ago where a user complained that Comcast was blocking them from using the DNS provider of their choice.  This was an erroneous post by an anonymous Slashdot user, and Comcast does not block port 53.  As David points out, the Netalyzr tool enabled other users to quickly demonstrate that port 53 was not being blocked or force through ISP DNS servers, and I second his recommendation to use that excellent tool.

Are you aware of any ISPs in the U.S. that are blocking port 53?

Sprint Wireless By David A. Ulevitch  –  Jun 29, 2009 12:47 pm PDT

Sprint Wireless blocks outbound 53.  I've never been able to get someone on the other end of the line that even knows that that means.  Some of our savvier Sprint wireless users talk to us on 5353. :-)

David,The http://netalyzr.icsi.berkeley.edu/ tool is pretty impressive, hope By Jeremy Hitchcock  –  Jun 30, 2009 4:19 am PDT

David,
The http://netalyzr.icsi.berkeley.edu/ tool is pretty impressive, hope everyone gives it a try on obscure networks.  Be great to look at the results when they come out.  Are you involved with it at all?

Anyone know if EFF was going anywhere with the Switzerland Network Testing Tool or publishing any general studies on which ISPs muck with ports?  I could probably come up with a good list of 25/80 outbound/inbound ports but the blocks change.

Two bugs in the form By Stephane Bortzmeyer  –  Jul 20, 2009 5:36 am PDT

Usage instructions for dig with TCP are wrong ("Warning, ignoring invalid type cp") and "postal code" without any indication of the country is meaningless.

Add Your Comments

 To post your comments, please login or create an account.

Related

Topics

Cybersecurity

Sponsored byVerisign

Whois

Sponsored byWhoisXML API

Cybercrime

Sponsored byThreat Intelligence Platform

IP Addressing

Sponsored byIPv4.Global

Brand Protection

Sponsored byAppdetex

Domain Names

Sponsored byVerisign

DNS Security

Sponsored byAfilias

New TLDs

Sponsored byAfilias