Bus error: Jake Billo’s weblog

While it may seem like all I write about these days is Rogers, it’s really the only thing I’ve been dealing with on the service provider front. All my other corporate relations have been going well: I pay people money and they provide a service without bothering me unduly. (I must congratulate the wireless business for their 6GB data plan extension and forthcoming reasonably priced data packages, although one could make the case that Telus and Bell really forced them into it.) This time, it’s about the Internet side of the equation.

Beginning July 18th, Rogers began implementing a provider-wide SiteFinder-style service, where users are redirected to a “search” page with sponsored results for mistyped and nonexistent domains. On a technical level, I fundamentally disagree with this change: it breaks the concept of NXDOMAIN (a useful “domain does not exist” response) and makes things much more difficult to troubleshoot with respect to network architecture. The only reason I haven’t bitched and whined about this much earlier is that I’ve been using OpenDNS for completely unrelated reasons. It was only when my roommate Alex complained about VPN connectivity that I actually looked into the issue.

It turns out that Rogers’ marketing effort completely bricks internal domain resolution for a lot of common VPN clients, including the default Windows XP offering. So if your company, like many others, has internal domains such as corpweb.example.com, Rogers’ search will open up with the terms “corpweb example” at the minimum. This practice has data exposure implications: not only does Rogers now know about an internal domain you’re trying to access, but a third party provider like Yahoo now knows.

If you were an employee of a competing search engine and trying to VPN from home, Yahoo would now know something about your internal network structure; this is bad news all around. Hitting a favourite or quick launch link to corpweb.example.com/livelink/llsapi.exe?doc=Network_Security_Breach_Sept0408.doc would reveal the choice of LiveLink as a corporate CMS, a dependence on Microsoft Word and a document detailing a potentially classified incident.

OpenDNS isn’t any better by default, either. They redirect search results and mistyped domains, and in the process intercept VPN traffic. To get around this, you have to create an account and blacklist corporate VPN connections from “helpful results” on a per-domain basis. The solution also involves downloading and maintaining a dynamic IP address update client, or setting a Tomato-enabled router to perform the same task.

What I’ve done for now is listened to the accurate advice on trevoro.ca and changed my primary Rogers DNS server to an unadvertised IP address: altdns.rnc.net.cable.rogers.com, or 64.71.255.202. This server seems reasonably quick for name resolution and returns proper responses when a domain is not found, allowing VPN software to resolve internal addresses.

As the informal network weasel in my new place, I get the wonderful joy of troubleshooting malfunctioning appliances and making sure that the router eats as few Xbox Live sessions as possible. Since I’m just lazy enough not to want to set up a Linux routing box, the current approach for networking is two connections into two routers:

• Rogers Hi-Speed Internet Extreme (95GB cap), into a Linksys WRT54GL running Tomato 1.19 firmware and
• TekSavvy, unlimited cap, DSL dry loop, into yet another Linksys WRT54GL running Tomato 1.19

The main server with two network cards accesses the Internet over the TekSavvy line, using a combination of manual interface metric settings and a MAC address block at the Rogers router.

It’s not the TekSavvy line that’s been giving problems, though - and the Rogers connection is solid, even with four computer science types all wanting their pornography and HD movies updated Java Development Kits seven times a week. It’s the Rogers DNS servers that cause problems looking up domains - I’ll often receive 60 to 120 second timeouts just seeking a match for facebook.com. Boo, you fail!

The solution is to switch DNS services to OpenDNS at the router level. Tomato provides an excellent internal DNS cache service, which still allows Linux systems to access internal hostnames - and OpenDNS returns lookups reliably and without fail. The price you pay for this is a page of sponsored search results on a domain typo or non-existing hostname, but this is fairly similar to how most browsers function anyway.

To activate OpenDNS in Tomato firmware, you can change the “Static DNS” settings in your router administration panel. On default configurations, the address is 192.168.1.1 with username root, password admin. Then it’s just a matter of adding the server entries 208.67.222.222 and 208.67.220.220:

There you have it - DNS that still resolves local systems, but is significantly more reliable than the ISP-provided service.