Internet Performance Delivered right to your inbox

DNS Proxies, IETF 75 and Hijacking

There’s a lot of conversation at this IETF 75 over Comcast’s recent draft regarding DNS redirect services. It’s a heated topic with many arguments. One argument is for standardizing the behavior and one for not condoning the practice. One for showing how it should be done and another for documenting all of the things that go wrong. These are really interesting questions for protocol engineers and operators to ponder.

Ironically, I’m staying at the Rica Hotel Kungsgatan and connected to a network with an SSID called “Wayport” and am now dealing with this very issue on a personal level. Being a DNS geek, I started seeing a couple of weird things and dug into what was a pretty profound manipulation of my traffic.

One tool that picks this up is the Berkeley ICSI Netalyzer. Open it up and let it run for a couple minutes. They keep the records and are planning on releasing a study in the near future.

A DNS proxy or firewall caused the applet’s direct DNS request to be sent from another address. Instead of your IP, the request came from

Eh, not the best of worlds. I’m obviously behind a NAT and they are conserving IP addresses. I’ll sleep better knowing that it is IPv4 exhaustion causing this.

A DNS proxy or firewall generated a new request rather than passing the applet’s request unmodified.

Well, that’s just not necessary. What’s more, there are some pretty interesting/scary things that they do. Take a look at this:

Rewritten TTL

$ dig
;; ANSWER SECTION:         0       IN      A

My TTL is rewritten to be 0 seconds meaning that they will have to go out and query the authoritative name server every time. Since it’s already a slow connection, that means that my entire experience is slower.

Port 53 is p0wn3d

$ dig
;; ANSWER SECTION:         0       IN      A

Looks like they hijack anything port 53—but my favorite.

Hijack queries

$ dig @ +short
$ dig +tcp @ +short

For those of you who don’t know what OpenDNS does, they run recursive DNS servers and provide an end-user test to see if you are using OpenDNS or not. Basically, they return differently because they are NOT hijacking the TCP DNS query. Wayport is controlling my Internet and I have no way of knowing what is real and what is not.

I took a look through the acceptable use policy, the privacy policy, and the security information and they all say nothing about this practice.

There isn’t consensus on the Comcast draft and how it should continue but there are a few things to think about:
* We don’t have to worry about this practice starting because of a draft because that ship has sailed.
* Choice, notification, and opt-out are important. I have none of those because of the hotel I chose (my cell modem card only works in the US).

I’d suggest for the ICSI Netalyzer to perform a test like this to see whether it hijacks queries and maybe even publish that list. And if you’re from Wayport and reading this, please stop it.

Share Now

To current Dyn Customers and visitors considering our Dynamic DNS product: Oracle acquired Dyn and its subsidiaries in November 2016. After June 29th, 2020, visitors to will be redirected here where you can still access your current Dyn service and purchase or start a trial of Dynamic DNS. Support for your service will continue to be available at its current site here. Sincerely, Oracle Dyn