Website Connectivity Woes and Woe-Nots
by Allan Sieker
The story you are about to hear is true and should be of interest to all web developers – be you .NET or not.
A few businesses I know had issues with web site connectivity a few weeks ago. Some computers could connect while others could not. IE 8 seemed to have more of a problem than IE 7. The client could access other web sites ok. Client locations were across the US and not all local (the St. Louis area).
Computers were rebooted. Cookies were deleted. Browser security was lowered. Nothing really seemed to help. In some cases, one desktop connected ok while another desktop in the same office could not.
The web server’s IP could be pinged ok from the client location, but the website just wouldn’t come up. There was no rhyme or reason to the problem. Quite a mystery. Does this perk your interest? If so, read on.
As it turned out, the problem was not the web server at all. No, it wasn’t IE either. An email from register.com solved the mystery but not without creating new concerns. You see, register.com had been hit by a “massive denial-of-service attack”.
The client connectivity issues were caused because the browser could not resolve the url of some of the web sites because the domain name service (DNS) of register.com was bogged down by the DOS attack. Some computers and browsers had the IP cached and could connect ok until the cache expired or the computer rebooted.
This got me to thinking about how easy it was for a problem with a basic Internet infrastructure operation – one that is probably taken for granted these days – to bring down so many web sites when such a simple work around was available for Windows users.
If you have been developing web sites since the 90s, chances are you know what the HOSTS file is all about. For those who don’t, let me take a minute to tell you about it.
The HOSTS file is located in the WINDOWS\system32\drivers\etc folder and contains a list of IPs and host names. In most cases Windows will check the HOSTS file before it performs a DNS query.
So a simple work around to the DOS attack was to add the web site host name to the HOSTS file.
Yes, sir. The HOSTS file is a handy thing to understand. Another thing you can use it for is to speed up the loading of web sites with all of that doubleclick.net crap. Do a browser View-Source for a web site and scan the code for doubleclick links. When you find one, add a line for it in the HOSTS file that forces it to resolve to 127.0.0.1, which is the local computer and a dead end.
Example:
127.0.0.1 localhost
127.0.0.1 doubleclick.com
127.0.0.1 doubleclick.net
127.0.0.1 fls.doubleclick.net
127.0.0.1 ad.doubleclick.net
Well, that’s it for now.
May 1st, 2009 at 10:41 pm
[...] [...]