If you encounter unexpected behavior or inability to contact specific Internet hosts with a DSL connection, reboot your DSL modem or router before exploring other solutions.
Yesterday (Wednesday 11/17/2010) afternoon, my wife and I encountered a slowdown in connecting to certain Internet hosts, such as microsoft.com, msdn.com, yahoo.com, cloudapp.net (Windows Azure) and others with our ATT DSL connection. Other hosts, such as google.com and twitter.com, behaved as expected. I attributed the problem to temporary congestion or a routing mixup, but didn’t investigate further and turned the four computers in the house off.
This morning, I started my Windows Server 2003 R2 domain controller, as well as Windows Vista and Windows 7 clients and found none were able to connect to microsoft.com, msdn.com, yahoo.com, cloudapp.net and att.com. I didn’t receive immediate 404 errors; IE 8 remained in a “Connecting” state for several minutes. But google.com, twitter.com, and a few other hosts continued to behave as expected. Gmail and CompuServe (AOL) mail worked as usual, but Microsoft Online Services wouldn’t connect.
I believed that ATT’s DNS servers were the source of the problem because it affected only specific hosts. I contacted ATT Internet customer service, who claimed that “customers were experiencing problems with IE 8,” asked me to try Firefox (same problem), and then escalated the issue. When I describe the problem to the next-level agent at (877) 825-6033, she said it wasn’t an ATT problem and offered to connect me to a technician for a prepaid charge of US$139.00. I declined the offer.
I use Windows Server 2008 R2 Routing and Remote Access services to provide Network Address Translation (NAT) to my internal network, so I opened a command prompt and issued an ipconfig /flushdns command to make sure some rogue site hadn’t poisoned my DNS cache. That didn’t solve the problem.
Next, I checked the TCP/IP properties (settings) on the NIC connected to the router. The single DNS server address was 127.0.0.1 (loopback) instead of the original 126.96.36.199 (preferred) and 188.8.131.52 (alternate) entered when I configured the server. I set those DNS addresses, rebooted the server, but still no luck with the affected hosts.
Headslap! I hadn’t rebooted the old-timey Cayman 3220-H modem/router provided by Pacific Bell; rebooting usually was required to restore dropped DSL connections. I pulled the power cable, waited 15 seconds, plugged it back in, and received the expected “three green” (same as for aircraft retractable landing gear in the down and locked position.)
Eureka! The reboot solved the problem. All hosts behaved as expected. I have no idea why the router had problems with only certain hosts.
Note: I was one of Pacific Bell’s first DSL customers in the East Bay (CA) region and have a set of fixed IP addresses. I suffered through routing table hell during PacBell’s transition to Southwestern Bell and Yahoo! as the service provider (which is why I have a sbcglobal.net email alias), and then through the ATT name change.