Did you every wonder how IP addresses like 64.236.29.72 relate to domain names such as eng-server? Have you ever wished that you could type in something easy to remember, such as eng-server rather than an IP address to get to a local server? This month we will look at what a Domain Name System (DNS) does and how to use it.
Hosts files
DNS was created for people who can't remember long strings of numbers. It is a lot easier to remember cartoonnetwork.com rather than a four octet IP address. Even if you commit the IP address to memory, Cartoon Network might need to switch to a different IP address at a later time. Or the network might want to send people to several different Web servers with identical content so that it can balance the load between multiple servers. DNS does this and more. Conceptually, DNS is a huge distributed database that contains IP addresses and the hosts domain names.
Computers do not use domain names to send messages to a remote host on the Internet. Instead, the domain name, sometimes called the host name (e.g. cartoonnetwork.com) is resolved to an IP address (e.g. 64.236.29.72). The IP address is what used to communicate with the host.
Early on, programmers invented HOSTS.TXT files as a way to translate between names that are easy to remember and the IP addresses actually used on the network. The HOSTS.TXT file was centrally maintained. Administrators could e-mail HOSTS.TXT changes to the central administrators. The administrators modified the master HOSTS.TXT file and then posted it on a server. Anyone who needed a copy could download it and install it on their computer. HOSTS.TXT files still exist, but the names have been modified to hosts files. Figure 1 illustrates a hosts file from a UNIX server.
If you search your Mac or Windows machine, you will find a hosts file. If you prefer to type the name router instead of typing the IP address of your local router, you can add a line to the hosts file as follows:
192.168.0.1 router
(Be sure to substitute the IP address of your router for 192.168.0.1 in the example above.) If your router has a Web page that allows configuration, you can now access this page by starting a Web browser on your computer and entering router instead of 192.168.0.1.
How DNS works
The hosts file was a great solution when networks were small, but when people began to connect computers together to create the Internet, the hosts file quickly became unmanageable. Something better was needed.
The end result has proved to be a flexible solution, which has served the Internet well as it has grown beyond what the original DNS designers ever envisioned.
DNS works by setting up servers that have the last word (known as authoritative servers) regarding the domain name/IP address relationship for a particular domain. DNS servers are authoritative for a specific zone, or area of a domain. A DNS server that is authoritative for an entire domain — all of examplebroadcaster.com, for example — may delegate responsibility for a subdomain such as engineering.examplebroadcaster.com to another DNS server.
This allows small organizations to control DNS for an entire organization in one place. It also allows larger organizations to distribute control of subdomains on a departmental or other level. Only one DNS server is allowed to be authoritative for any given domain.
By giving control of domains on the Internet to many different DNS servers, the information is distributed throughout the Internet. DNS has become an Internet mission-critical system. Backup DNS servers automatically track changes made to the primary servers.
BIND servers
The Berkeley Internet Name Domain (BIND) is a DNS server commonly used on the Internet. In BIND, DNS servers are designated as master servers if they are authoritative for their zone. They are designated slave servers if they are backup servers for a zone. Once a server has been configured as a slave, and once the master has been made aware of the existence of the slave, any changes made to the master DNS server will automatically be sent to the backup. If the master DNS goes down, the client trying to resolve the domain name will automatically check with the backup to get the IP address for the domain. If everything works properly, and it almost always does, you will never know the master is down.
If these servers are located all over the Internet, does this mean that every time someone types cartoonnetwork.com into an Internet browser, the authoritative DNS server for this domain has to answer? Once local DNS servers have gone to the authoritative server for a domain, the results are saved locally. When another client asks the DNS server to perform a lookup, it uses its local cache rather than performing another search on the Internet. This reduces the load DNS places on the Internet.
Root servers
By now, some of you may have spotted a problem with this system. What if you do not know the authoritative DNS server for cartoonnetwork.com? How do you find the DNS server and get the IP address you need?
When you configure your computer to operate on a network using TCP/IP, you will need to enter the address of the local DNS server. Or if you are using Dynamic Host Configuration Protocol (DHCP), information about your local DNS server is automatically provided to your computer. This nearby DNS server knows about domains under its control, but how does it find out about domains it does not control?
If you ask your local DNS server for the IP address of cartoonnetwork.com, assuming the DNS server is not authoritative for that domain, it begins by sending a query to other DNS servers upstream from it. With this particular domain, the query will probably not have to go far before it finds a name server that has the information in its cache, because cartoonnetwork.com is quite popular. But if the domain information is not cached somewhere, the query will work its way up to the top level Internet domain name servers, sometimes known as root DNS servers.
Because the root servers are authoritative for every domain under their control, the DNS server that is authoritative for the “.” (root) domain may not know about cartoonnetwork.com, but it will know which server is authoritative for the “.com” domain, because it has been configured to delegate the “.com” zone to that server.
Once the query reaches the root servers, it is then sent back down the tree to the appropriate server responsible for that zone. The “.com” server knows which server is authoritative for cartoonnetwork.com because it has delegated control of that zone to that DNS server. It asks the server for the IP address, and the authoritative server gives the answer.
The answer is then relayed to the server that originated the query. Now the local DNS server knows the answer, but so do all the servers along the way. If someone else asks the same question, it can be answered without having to go back to the authoritative server because the answer has been cached locally. We can easily experiment with this. Figure 2 is the result of a dig command from one of my FreeBSD servers.
From Figure 2, you can see that my DNS server passed a question to my local DNS server at 205.152.0.5 and received an answer (64.236.29.72) from twdns-01.ns.aol.com. Actually, you might notice that I got two answers. It appears that cartoonnetwork.com has two valid IP addresses.
Conclusion
Experiment with this on your computer. If you have a UNIX-type machine, use either dig or nslookup. If you have a Windows machine, use nslookup.
You may be surprised to know that after all this, many routers do not use IP addresses, but instead use MAC addresses to properly route packets to their destination. I'll discuss more about this topic next month.
Brad Gilmer is president of Gilmer & Associates, executive director of the AAF Association and executive director of the Video Services Forum.
Send questions and comments to:brad.gilmer@penton.com
