Section 10.5 AOL s DNS Change Fiasco

   


10.5 AOL's DNS Change Fiasco

All of a sudden, the help desk at AOL started getting complaints from users that e-mail was not being received by them. No doubt the initial response was "perhaps the sender mistyped your address" or "the network must be slow." Certainly, later AOL started to suspect network problems when the calls mounted.

I wonder if it was a sharp SysAdmin at a non-AOL site investigating why his user's e-mail was not getting to the recipient who figured it out. For some reason, the top-level DNS server for .com was pointing to the wrong MX address for aol.com. Some tiny little company was receiving a deluge of e-mail intended for one of the busiest sites on the Internet!

Someone simply had asked Network Solutions, Inc. (NSI), at the time the only registrar for .com domains, to update AOL's entry and NSI had. This is still a problem.


How hard was this? NSI offers domain owners a choice of three ways to authenticate an update request for your domain data.

  1. By providing your public PGP key to NSI and then signing e-mail with your private key.

  2. By supplying a password with NSI, storing only the DES encrypted version (more accurately called a one-way hash).

  3. By sending a request from the e-mail address registered with NSI. This is the default. This is a really bad idea.

Well, there is a fourth way. Claim that a domain name that someone else owns is an infringement on your trademark, even if it is such a generic name that you have a very questionable legal claim, and have tough-talking attorneys, and NSI might give you the domain. Unfortunately, this is a common occurrence. (Read your contract with NSI.)

The fifth way is to sue either in a court of law or, now, in the United Nations. Although cybersquatting is a questionable practice, the U.S. trademark laws are very specific in saying that a trademark only protects that mark in a particular industry and a generic name of a domain site probably does not qualify unless its owner is using it in an industry-specific way.

Should one company have a claim to a common Irish surname? Should another billion dollar company have a claim to theworldontime.com or should they have to try to buy it from the company, in a different industry, that registered it and also might have been using that slogan for a long time?

In the first case, mcdonalds.com was given to the burger flipper by one of the principal developers of Apache, without personal remuneration, in return for McDonald's funding a T1 connection to a certain Brooklyn High School forever. Such are the people who do open source.

By the time you read this, Federal Express's suit against a small medical data company probably still will be going on, as will the countersuit for harassment.


Yes, the craker spoofed e-mail from AOL to NSI. E-mail address spoofing is discussed in "Mail Spoofing" on page 253 and it took all of five minutes to create the example (which is a real spoofed message, not merely keyed text). Almost everyone reading this is vulnerable to this attack.

Once AOL discovered the problem they sent another domain update to NSI, which only uploads data to the root DNS server once a night. Worse, the thousands of name servers in the world cache this data for days or even weeks. The bad publicity could hurt.

AOL got a more powerful computer on the next plane to the site and arranged to increase its bandwidth to better support the many thousands of e-mail messages as well as the site's intended business. Fortunately sendmail, running at many of the sites trying to send mail to AOL subscribers, will keep retrying for days until the mail gets through.

The obvious lesson is do not allow your domain data to be "protected" from update by crackers with a mere e-mail address. This is a ticking time bomb for the vast majority of sites out there.

If you see yourself in this position, take care of this "real soon now."


   
Top


Real World Linux Security Prentice Hall Ptr Open Source Technology Series
Real World Linux Security Prentice Hall Ptr Open Source Technology Series
ISBN: N/A
EAN: N/A
Year: 2002
Pages: 260

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net