Comcast DNS Abuse

by dhovel 4. November 2010 02:37

In the middle of debugging some code on my Mac, I discovered that Comcast has done it again.  Acted against the interests of its customers, that is.   My Mac code, intended for an iPhone app, was "pinging" various web sites; I discovered that non-existent web sites showed up as actually present.   At first I thought it was my app, so I kept trying to look for bugs.  After a while, I brought up the Mac OS X "Networking" utility and found that virtually all non-existent web addresses were being redirected to address 208.68.143.50.  Not only was this bogus node replying to pings, but it would act as a spurious web site by servicing HTTP requests over port 80!

In other words, Comcast has changed the way the internet behaves in order to push advertising.  Of course, in their propaganda they claim that this is some sort of "service" to users to give them alternatives, but in reality it's just another intrusive and error-provoking means of earning revenue.

I later found that there is an option in my Comcast account to disable this unwanted "helper" service.  I've turned it off, of course, and as yet I see no change in behavior.  Maybe their expensive databases will take a week or two to propagate an update from my account to their overly clever DNS servers.   Here is the explanatory the link at Comcast.

It's sort of like going into a restaurant and ordering sushi, only to find canned tuna on the plate and a note saying that you were given lower-quality food because it may be lower in mercury.  The fundamental behavior of the internet is important and should be protected from the vagaries of oppressive marketing and the never-ending quest for yet another dollar.

Maybe I'm just too old for this crap.

Later note: I woke up this morning to find that their "opt out" feature actually works.  At least they got that right.  I'm dubious about all this, but at least I don't have to use it.

Update (10/2011):  I just found that the "DNS Helper" service had been turned back on; I have no idea why.  I went back to Comcast to change it again and discovered that it's very important to log in with your full Comcast email account name; otherwise, the "DNS Helper" option won't appear.  It seems they want to make this very difficult.

Tags:

networking

An Interop Note about IPv4 and IPv6 on Windows Vista and 7

by dhovel 28. July 2010 15:41

As most of you know, most Ethernet (and other) network cards these days have drivers that support IPv6, even though there are very few real, live IPv6 infrastructures around to test.   I’ve found with Vista and Win 7 that ‘ping’ and other utilities routinely report IPv6 information on intranets.  This is troublesome because it actually broke one of my programs and I’ve had to fix it.  It also makes things hard to diagnose.
Here are the results of a ping from my Vista laptop my wife’s:

>ping bonniehp
Pinging BonnieHP [fe80::f058:d36e:9a4:8145%10] from fe80::b035:5a09:7a3f:d16d%10 with 32 bytes of data:
Reply from fe80::f058:d36e:9a4:8145%10: time=1ms
Reply from fe80::f058:d36e:9a4:8145%10: time=1ms
Reply from fe80::f058:d36e:9a4:8145%10: time<1ms
Reply from fe80::f058:d36e:9a4:8145%10: time<1ms
Ping statistics for fe80::f058:d36e:9a4:8145%10:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 1ms, Average = 0ms

The long IPv6 addresses are not too useful, at least to me.  However, if I add the ‘-4’ flag to the command line, I get what I was expecting:

>ping bonniehp -4
Pinging BonnieHP [192.168.1.102] with 32 bytes of data:
Reply from 192.168.1.102: bytes=32 time=1ms TTL=128
Reply from 192.168.1.102: bytes=32 time<1ms TTL=128
Reply from 192.168.1.102: bytes=32 time<1ms TTL=128
Reply from 192.168.1.102: bytes=32 time<1ms TTL=128
Ping statistics for 192.168.1.102:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 1ms, Average = 0ms

Back when I wanted to disable IPv6 on my Vista machine, I found this web page, which explains it clearly.  The problem is this: If you disable IPv6, you ALSO BREAK NORMAL PINGING.  My Vista machine could no longer ping Bonnie’s, although everyone could ping me and I could ping all down-level machines.

In other words, Microsoft, in its wisdom, made some subtle but necessary feature of IPv4 networking part of IPv6—lose IPv6 and you lose pinging to same-level machines.  Barf.

Anyway, if you read the fine print at the bottom of the linked web page, you’ll see a Registry hack involving a value called ‘DisabledComponents’.  What’s interesting is the line:

Prefer IPv4 over IPv6   0×20

This little trick appears to work.  If you set the DisabledComponents value (usually 0x0) to 0x20, the ping command (and other programs that do pings) will see the IPv4 address FIRST in the collection of returned addresses.  It also causes the .Net runtime to return IPv4 addresses first from GetHostEntry(). This makes life much simpler for me.

Tags:

networking