Please Whitelist This Site?
I know everyone hates ads. But please understand that I am providing premium content for free that takes hundreds of hours of time to research and write. I don't want to go to a pay-only model like some sites, but when more and more people block ads, I end up working for free. And I have a family to support, just like you. :)
If you like The TCP/IP Guide, please consider the download version. It's priced very economically and you can read all of it in a convenient format without ads.
If you want to use this site for free, I'd be grateful if you could add the site to the whitelist for Adblock. To do so, just open the Adblock menu and select "Disable on tcpipguide.com". Or go to the Tools menu and select "Adblock Plus Preferences...". Then click "Add Filter..." at the bottom, and add this string: "@@||tcpipguide.com^$document". Then just click OK.
Thanks for your understanding!
Sincerely, Charles Kozierok
Author and Publisher, The TCP/IP Guide
NOTE: Using software to mass-download the site degrades the server and is prohibited.
If you want to read The TCP/IP Guide offline, please consider licensing it. Thank you.
DNS Design Goals, Objectives and Assumptions
(Page 1 of 2)
we just saw in the preceding topic, the
elapsed time from the first RFC discussing TCP/IP domain names to the
publishing of the official standards describing the operation of DNS
was over six years. This is a very long time for the development of
a system, but it doesn't surprise me. A lot of thought had to go into
the creation of DNS, to be certain that it would meet all of the many
demands that would be placed upon it.
The first problem was that the creators
of DNS had to worry about both how to define the new system and how
to migrate from the old one. Considerable time was spent figuring out
how all the existing hosts would be moved over to the new DNS name space
and how the new protocols for exchanging DNS information would be implemented
The creators of DNS knew they were
making the new system because the old one didn't scale very well; they
also knew that if migration was a difficult problem with the small number
of hosts in existence at that time, it would be much more difficult
if they had to go to another new system in the future. This made the
key challenge in DNS to create a system that would meet the needs of
the Internet not just the day it was introduced, or the following year,
but even ten years or more down the road.
DNS Design Goals and Objectives
Back in the 1980s, nobody had any
idea how the Internet would grow as it has in the last decade. That
DNS still works as well as it does is a testament to the skill of its
designers. Much of this success is due to the early groundwork put into
the design of the system. DNS engineers documented some of what they
considered to be the main design goals in creating it, which can help
us understand not just what DNS does but why:
- Creation Of A Global, Scalable, Consistent
Name Space: The name space had to be capable of spanning a large,
global internetwork containing millions of machines. It was necessary
that it provide a consistent and predictable method for naming devices
and resources so they could be easily found. It was also, obviously,
essential that name duplication be avoided, even when conflicts could
potentially be between devices on different continents.
- Local Control Over Local Resources: Administrators
of networks and small internetworks on the Internet as a whole needed
to be able to have control over the naming of their own devices. It
would not be acceptable to have to go through a central authority for
naming every single object, nor would it be acceptable for every administrator
to need to know the names of everyone else's networks and machines.
- Distributed Design To Avoid Bottlenecks:
The designers of DNS knew that they would have to abandon the idea of
a centralized database in favor of a distributed approach to data storage,
to avoid the bottlenecks that would result in using DNS with many devices.
- Application Universality: The system had
to be general enough that it would support a wide variety of applications.
For example, it needed to support host identification, mail delivery
and other functions.
- Multiple Underlying Protocol Support:
DNS needed to be inherently able to support different underlying protocols.
(Many people don't realize, for example, that DNS can support not just
IP addresses but other types of addresses, simply because IP is so dominant
in networking today.)
- Hardware Universality: Both large and
small computers needed to be able to use the system.
Keep these objectives in mind as
you learn more about DNS, and it will help you understand better why
certain design attributes were chosen. For example, if we consider the
first two objectives listed above, they seem almost contradictory: how
can we have a global name space with unique names if individual administrators
were able to assign local names? The answer, as we will see, is that
this is where the power of the DNS
hierarchical name space shines through.
|If you find The TCP/IP Guide useful, please consider making a small Paypal donation to help the site, using one of the buttons below. You can also donate a custom amount using the far right button (not less than $1 please, or PayPal gets most/all of your money!) In lieu of a larger donation, you may wish to consider purchasing a download license of The TCP/IP Guide. Thanks for your support!|
Table Of Contents - Contact Us
The TCP/IP Guide (http://www.TCPIPGuide.com)
Version 3.0 - Version Date: September 20, 2005
© Copyright 2001-2005 Charles M. Kozierok. All Rights Reserved.
Not responsible for any loss resulting from the use of this site.