Digging into DNS: ignore it at your peril

As CTO of InfoWorld, I have to admit that I spend more time than most CTOs on the bleeding edge of technology pondering the next big thing. A few years ago, all the Web services talk around the office had me digging into SOAP and XML-RPC; and as Weblogs and RSS emerged, I had a front-row seat, as pioneers, such as our own Jon Udell, led the way. During the past couple of weeks, however, I’ve been thinking about a particular three-letter acronym a little more than usual. BPM ? No. BRM (business rules management)? Not quite. Good ol’ CRM? No, not even close. I’ve been thinking about boring, old DNS.

Underneath the excitement of the Internet sits DNS, the little mouse running on the wheel that keeps the whole thing going. When that wheel stops turning, or even just gets a little misaligned, the shock to the Internet can be profound. Working DNS makes the Internet; unavailable or misconfigured DNS breaks the Internet. CTOs not on top of DNS are certain to run into problems — and it’s not always your own DNS that you have to debug to get business done.

My first encounter with serious DNS problems occurred years ago when I took over the operations of a troubled IT department. DNS administration in the group was haphazard at best, and because DNS was being administered via an over-simplified GUI on Windows NT, the administrators didn’t have to understand how DNS really worked.

Then one day, e-mail stopped coming in. And then the phones started ringing when our Web site became unavailable. After a long and grueling process, we discovered that a bug in our GUI-based DNS software had resulted in a truncated zone file -- the back-end text configuration file where the DNS rubber meets the name-resolution road -- and our domain was gradually (but surely) falling off the Internet itself, taking all our Internet services with it. We dumped the buggy GUI for open source BIND (Berkeley Internet Name Domain). I handed over DNS duties to a talented Linux sysadmin who manually edited the zone file, and we never had those problems again.

You would think that the impact of isolated DNS failures, such as the one described above, would be mitigated in 2004. Think again. As outsourcing and Web services have become facts of life, dependence on absolutely fundamental (but distributed) systems, including DNS, can sometimes leave businesses high and dry. In June, Akamai attributed a major slowdown at customer Web sites -- including the likes of Microsoft, Yahoo, and Google -- to a “global DNS attack.” In July, an attack on the DNS servers at DoubleClick caused “severe disruption” at many top Web sites, InfoWorld.com included. DNS is so fundamentally tied into everything that DNS problems can quickly turn firm Internet footing into treacherous quicksand.

Just this week, one of our salespeople was frustrated that a key client was unable to e-mail anything to us, fundamentally disrupting our ability to do business. On the surface, it appeared that our mail system was rejecting all e-mail from the client. It wasn’t our problem, however; it was a bad DNS config on the client’s end. Yet it was our customer, so naturally we spent time helping fix it.

The bottom line is that someone in your IT organization needs to understand DNS. You can get by with outsourcing your DNS to companies such as Ultra DNS, but in the end, DNS is one of those low-level technologies that you need to have a strong handle on. Or else.

• Bookmark this page
• Share this article
  •  
  • facebook
  • slashdot
  • digg
  • Reddit
  • stumbleupon
  • linkedin
  • twitter
• Got more on this story? Email Computerworld
• Follow Computerworld on twitter

• Share
  Share this article

  •  google+
  • facebookfacebook
  • slashdotslashdot
  • diggdigg
  • RedditReddit
  • stumbleuponstumbleupon
  • linkedinlinkedin
  • twittertwitter
• print
• email
• Bookmark