Oh, the pleasures of being a programmer! In the old days of paper
documentation we used to leaf through countless pages to figure out a
parameter type passed to a function. Then came the books on CD where we
could search for that mysterious parameter if we had the CD. Most of the
time someone had taken it home, you know the one built in the Bermuda
triangle. Then came the Web and we were finally released from our books
and CDs. I have to admit, I never knew the extent to which I had become
dependent on the Internet until we had the recent series of microsoft.com
outages (last week of January extending to the first week of February).
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 ] |