Revisiting the Domain Name System (DNS), Part 3

The Domain Name System (DNS) distributes the responsibility of assigning domain names and mapping those names to IP addresses by designating authoritative name servers for each domain. Authoritative name servers are assigned to be responsible for their particular domains and, in turn, can assign other authoritative name servers for their sub-domains. This mechanism has made DNS distributed, fault tolerant, and helped avoid the need for a single central register to be continually consulted and updated.

In general, DNS also stores other types of information, such as the list of mail servers that accept email for a given Internet domain. By providing a worldwide, distributed keyword-based redirection service, the Domain Name System is an essential component of the functionality of the Internet.

DNS also defines the technical basics of the functionality of this database service. For this purpose it defines the DNS protocol, a detailed specification of the data structures and communication exchanges used in DNS, as part of the Internet Protocol Suite (TCP/IP).

Every domain has a domain name server somewhere that handles its requests, and there is a person maintaining the records in that DNS. This is one of the most amazing parts of the DNS system. It is completely distributed throughout the world on millions of machines administered by millions of people, yet it behaves like a single, integrated database!

Name servers do two things 24/7:

  • They accept requests from users to convert domain names into IP addresses.
  • They accept requests from other name servers to convert domain names into IP addresses.

When a request comes in, the name server can do one of four things with it:

  • It can answer the request with an IP address because it already knows the IP address for the domain.
  • It can contact another name server and try to find the IP address for the name requested. It may have to do this multiple times.
  • It can say, “I don’t know the IP address for the domain you requested, but here’s the IP address for a name server that knows more than I do.”
  • It can return an error message because the requested domain name is invalid or does not exist.

When you type a URL into your browser, the browser’s first step is to convert the domain name and host name into an IP address so that the browser can go request a Web page from the machine at that IP address. To do this conversion, the browser has a conversation with a name server.

When you set up your machine on the Internet, you, or the software that you installed to connect to your ISP, had to tell your machine what name server it should use for converting domain names to IP addresses. On some systems, the DNS is dynamically fed to the machine when you connect to the ISP. On other machines it is hard-wired. Any application on your machine that needs to talk to a name server to resolve a domain name knows what name server to talk to because it can get the IP address of your machine’s name server from the operating system.

Then, the browser contacts its name server and basically says, “I need for you to convert a domain name to an IP address for me.” For example, if you type www.bicycle.com into your browser, the browser needs to convert that URL into an IP address. The browser will hand www.bicycle.com to its default name server and ask it to convert it.

The name server may already know the IP address for www.bicycle.com. That would be the case if another request to resolve www.bicycle.com came in recently. In normal operation, name servers cache IP addresses to speed things up. In that case, the name server can return the IP address immediately. Let’s assume, however, that the name server has to start from scratch.

A name server would start its search for an IP address by contacting one of the root name servers. The root servers know the IP address for all of the name servers that handle the top-level domains. Your name server would ask the root for www.bicycle.com and, assuming no caching, the root would say, “I don’t know the IP address for www.bicycle.com, but here’s the IP address for the COM name server.” Obviously, these root servers are vital to this whole process, so there are many of them scattered all over the planet.

Every name server has a list of all of the known root servers. It contacts the first root server in the list and, if that doesn’t work, it contacts the next one in the list, and so on.

Every name in the COM top-level domain must be unique, but there can be duplication across domains. For example, bicycle.com and bicycle.org are completely different machines.

The left-most word, such as www or encarta, is the host name. It specifies the name of a specific machine, with a specific IP address in a domain. A given domain can potentially contain millions of host names as long as they are all unique within that domain.

Because all of the names in a given domain need to be unique, there has to be a single entity that controls the list and makes sure no duplicates arise. For example, the COM domain cannot contain any duplicate names and there are recognized organizations in charge of maintaining this list. When you register a domain name, it goes through one of several dozen registrars who work with these organizations to add names to the list. These organizations, in turn, keep a central database known as the whois database that contains information about the owner and name servers for each domain. If you go to the whois form, you can find information about any domain currently in existence.

As you can surmise from many of my previous Blogs, there are literally hundreds of individual processes and protocols that blend together to form large enterprises and the Internet as an entity. And, a serious study of each of these will help make your overall understanding of the network processes much more robust and complete.

Author: David Stahl

In this article

Join the Conversation