April 2001

BY ROBERT VAHID HASHEMIAN

Love them or hate them, it's clear that Microsoft does an excellent job of documenting their products. As TMCnet.com is a Microsoft-infested site (ok, we have some important Linux servers too), I find myself spending a considerable amount of time on their MSDN and KB sites looking up documentation and technical specs.

USER ERROR, INDEED
During that week, I finally realized how much productivity was lost when I couldn't access the Microsoft site. Not to mention the Hotmail, MSNBC, and MSN sites. I am sure I wasn't alone. Microsoft must have been bombarded with users' gripes. At the heart of the outage was a serious DNS problem that originally started at mydomain.com. A technician, purportedly, had misconfigured their DNS servers, which caused the traffic bound for microsoft.com and yahoo.com to be hijacked to mydomain.com. Then came the string of outages on sites operated by Microsoft. Microsoft originally attributed these to DNS misconfiguration by one of their technicians. Later however, Microsoft admitted that a more sinister reason was behind the problems. A DoS (Denial of Service) attack had shut out most of the traffic bound for those sites. Given the level of frustration I had with these problems, I decided to channel my frustration to a positive cause and devote this column to shed some light on how DNS works and why it is an important part of the Internet.

BACK IN THE DAY...
In the old days of the Internet, people communicated with the machines using their IP addresses. Yes it was a nerdy thing to do (especially when they used Hex numbers), but it got the job done. Then as more people and systems were hooked up to the net, someone came up with the idea of using human-recognizable names for those systems. A static file was crafted on each machine with simple lines that started with the IP addresses followed by the designated names. For example:
208.231.189.151 www.tmcnet.com
207.46.230.218 www.microsoft.com
On most machines this file was named "hosts" and any self-respecting UNIX-head knew its location was "/etc/hosts." Believe it or not, "hosts" files still live, even in Windows. If you use Windows, then you should be able to place a "hosts" file in your Windows folder mapping IP addresses to whatever names you would like. Now browsing to those names will direct you to the IP addresses you have specified in the file rather than where you would normally go. It is a cool trick to play on your unsuspecting friends.

As the Internet grew even larger, the static files were not going to cut it as a viable option to translate names to IP addresses. First off, they would grow prohibitively large and second, people had to constantly make changes to them to keep them up to date. So in 1987, DNS (Domain Name System) was introduced to effectively allow for a distributed approach to query for IP addresses. DNS's first incarnation was a package named BIND (Berkeley Internet Name Domain), which comprised the name server module (named); the resolver (used by clients to query name servers); and other supporting tools. When you surf to a Web site it is the resolver's job to query the DNS; and it is the name server's job to return a response in the form of an IP address.

DNS works as a hierarchy (sort of an inverted tree with lots of branches) starting with the "." root followed by the next level "com." or "net." followed by the next part such as "tmcnet.com." or "microsoft.com." et al. At the root of the DNS hierarchy there are 13 name servers (overseen by ICANN), which -- on average -- handle about 300 million queries per day each. As you move down the list, other name servers handle queries for their respective domain names (known as zones).

RECURSIVE NAME RESOLUTION
To best understand the operation of DNS, let's take a typical and simplistic trip to www.microsoft.com on my IE5.5 browser. After entering the Web site's name, my Windows resolver attempts to locally figure out the IP address by looking inside its cache and consulting the "hosts" file. If that fails, the resolver will query our local name server for the address. Our local name server looks inside its own cache to see if it can come up with the address. If not, it forwards the query to one of the 13 root servers. The query is then forwarded to what is known as an authoritative name server for "com." which in turn forwards the query to an authoritative name server for "microsoft.com." Finally, that server sends back the IP address of "www.microsoft.com." to our name server, which in turn passes it back to my PC and also places it in its local cache so it can service such queries much faster. Now with the IP address at hand, my browser is ready to traverse the Internet yet again and reach that address (but that's the subject of another column). What you just read was a typical name resolution that happens billions of times a day on the Internet known as "recursive name resolution".

So what happened to Microsoft's site during the outage? Well, the DoS attack (which could have been of any garden variety such as the SYN flood) overloaded the "microsoft.com." name servers such that they couldn't respond to the queries and thus the ensuing frustration. But, what about my resolver's cache or our local name server's cache? As it turns out the cache is only good for a certain amount of time (most are set for 24 hours) after which it is cleared, making local name resolution impossible. Now if I only knew the address 207.46.230.218 at that time I could have bypassed DNS altogether but that wouldn't have done me much good either as just about all of the images and links on a Web page are specified using server names which would have made for a very unsatisfying browsing experience. (The latest rumors are that Microsoft has begun hosting some of its name servers with Akamai, which would give it a much better chance of surviving such attacks in the future.) Unfortunately BIND (which is the most widely used name server on the Internet) has had its own string of bad news. The latest has been the discovery of a malicious buffer overflow weakness (known as TSig) which if exploited, could compromise the name server allowing a malicious user to modify the entries within the server and hijack traffic to another server (the recently released BIND 9 is immune from this attack).

SO, NOW WHAT?
All this begs a simple question. As we become increasingly dependent on the Internet, how can we protect ourselves from these acts of sabotage? As the Internet becomes a more popular medium for communications, I hope we can come up with more pre-emptive ways to keep the bad guys at bay. Now back to the MSDN site before it goes down again --just in case, here's its IP address: 207.46.130.161. 

Robert Vahid Hashemian provides us with a healthy dose of reality each month in his Reality Check column. Robert currently holds the position of director for TMCnet.com -- your online resource for CTI, Internet telephony, and call center solutions. He can be reached at rhashemian@tmcnet.com.

[ Return To The April 2001 Table Of Contents ]