Slashdot Mirror


RoadRunner Intercepting Domain Typos

shaunco writes "Sometime around midnight on February 26th (at least for the SoCal users), TimeWarner's RoadRunner service started intercepting failed DNS requests, redirecting them to RoadRunner's own search and advertising platform. To see if this has been enabled in your area, try visiting {some random string}.com in your Web browser. This feature subverts user preferences set within browsers, which allow the user to select which search engine receives their typos and invalid domains. RoadRunner users can disable this function — or they can just use OpenDNS. Here is an example RoadRunner results page.

9 of 337 comments (clear)

  1. OpenDNS Guide by Anonymous Coward · · Score: 5, Insightful

    or they can just use OpenDNS But OpenDNS does the exact same thing!
    1. Re:OpenDNS Guide by mrbcs · · Score: 5, Insightful

      Yes, but the difference is that YOU get control of how these are handled, not your ISP.

      --
      I'm not anti-social, I'm anti-idiot.
    2. Re:OpenDNS Guide by tjohns · · Score: 5, Informative

      I'm not quite sure how it tracks those opt-outs (by ip address perhaps?), as I didn't delve into it too deeply.

      They're tracking by the cable modem's MAC address. There's a page explaining this (and how it's insecure) here:

      http://rgov.org/road-runners-dns-wildcard

  2. Squatting www.jkshdfkljh23sadf.com by daveywest · · Score: 5, Funny

    Seems like I should be registering this and pointing it to my porn/phishing site right now.

  3. Re:Even happening with Lynx by orclevegam · · Score: 5, Funny

    Just tried it in West Hollywood area using lynx as the browser. Even then it is getting diverted to their page. Pretty sneaky. ... you don't really understand how this whole DNS lookup thing works do you?
    --
    Curiosity was framed, Ignorance killed the cat.
  4. HAHAHA by GodCandy · · Score: 5, Informative

    How ironic... someone registered www.jkshdfkljh23sadf.com as a parked domain. Wow these ppl need help.

  5. Re:So? by Todd+Knarr · · Score: 5, Informative

    The problem here is that what TW is doing breaks DNS. By the RFCs, when I try to resolve a name that doesn't exist, I'm supposed to get an NX "record does not exist" result. What I get instead is an affirmative A record "name exists at this address" response. What happens at the browser level is irrelevant, TW's DNS system has already lied about the state of the DNS records associated with a given domain. This badly breaks a lot of things that aren't browsers that use HTTP and depend on correct NX responses to tell them when the server they're trying to talk to doesn't exist.

    As long as TW doesn't block direct use of non-TW DNS servers this can be worked around. If they start blocking that access, or redirecting all DNS traffic to their servers, then we've got a major problem on our hands.

  6. Re:So? by Todd+Knarr · · Score: 5, Insightful

    Say you've got a program on an embedded device that automatically downloads updates. It retrieves "http://updates.devicecompany.com/model/latest-firmware.txt" to check what the latest offered version of the firmware is, and if the latest is greater than what's installed it retrieves "http://updates.devicecompany.com/model/firmware-.dat" and installs it. If the company goes out of business or stops providing updates, updates.devicecompany.com won't resolve anymore or will return a 404 error, so the device doesn't need to do a whole lot of error checking. And error checking means more code, which means more memory needed to hold that code, and this device is designed to be as cheap as possible so it omits anything it doesn't need.

    Now, suppose the company goes out of business. No problem for the device, the host it's at is supposed to not resolve anymore so it won't try to contact it. But now TW intervenes. Instead of failing to resolve or getting a 404 error, the grab of the latest firmware version returns garbage (an HTML page, not a properly formatted indication of the latest firmware version). Bam, device crashes. Or worse, it misparses the results and tries to download new firmware. Again, garbage (HTML page) instead of a valid firmware image. But since there's no error checking, it tries to load that HTML page into memory as a firmware image. Bam, one insta-brick.

    Or suppose the device isn't even using HTTP. The DNS servers don't know what protocol the device intends to talk, it could be logging into an FTP server or querying data via SNMP for all TW knows. The application gets bogus DNS responses anyway, even though it's not using HTTP or the Web at all. Breakage is the least problem here. The application's sending things like passwords up to the server. Even if it uses SSL to protect against eavesdropping, the TW server is an endpoint and SSL won't stop the endpoint from seeing the data. Do you want to have applications handing your vendor-support-site passwords over to TW because of a typo in a hostname? I sure don't.

    This isn't a problem when it's a human running a browser looking at pages. But there's a large chunk of traffic that isn't humans, isn't a browser, and isn't using the Web at all. And TW's change breaks everything except that small, select chunk that's humans looking at a browser window. Bad thing, that.

  7. Re:Actually, OpenDNS is even worse! by raju1kabir · · Score: 5, Informative

    The plot thickens. Have a look at this OpenDNS blog entry which explains the rationale for the Google interception. At least it's a plausible justification, though I don't have a Dell and I'd prefer my Googling to go straight to the source without intermediaries, so I'm keeping OpenDNS off.

    --
    "Patriotism is your conviction that this country is superior to all other countries because you were born in it." -- GBS