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.

The TCP/IP Guide  9  TCP/IP Application Layer Protocols, Services and Applications (OSI Layers 5, 6 and 7)       9  Name Systems and TCP/IP Name Registration and Name Resolution            9  TCP/IP Name Systems: Host Tables and Domain Name System (DNS)                 9  TCP/IP Domain Name System (DNS)                      9  DNS Overview, Functions and Characteristics

DNS Overview, History and Standards 1 2 DNS Components and General Functions

As 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 on them.

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.

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.

DNS Overview, History and Standards 1 2 DNS Components and General Functions