 Site Administration Page 8 - Fundamentals (of Linux Networking) |
| Site Administration Page 8 - Fundamentals (of Linux Networking) |
The Domain Name System - AdministrationThis article discusses the various types of networks, the methods for connnecting networks, how network data is moved from network to network, and the protocols used on today's popular networks. It is excerpted from chapter one of the book The Definitive Guide to Linux Networking Programming, written by Keir Davis et. al. (Apress, 2004; ISBN: 1590593227).
print this article SEARCH DEV SHED |
We’ve discussed how it isn’t necessary for every node on every network to store information about how to reach all of the other nodes on the network. Because of the gateway rule, a node only needs to know how to reach nodes on its own network or a gateway. With IP addresses 32 bits long, there are plenty of addresses to go around (and when we run out, there’s always IPv6, which is covered in Appendix A). We still have a problem, though. While computers can take advantage of the gateway rule, people can’t. It’s not enough to instruct our computers to make a connection—we have to specify the other end of the connection, even if we don’t have to specify exactly how our packets will get there. We still need a system people can use to point computers to the other endpoint of our connections, without requiring them to remember nearly endless lists of numbers. A system exists that lets us assign easily remembered names to their corresponding IP addresses, without having to remember the addresses themselves. This system is called the Domain Name System (DNS). You can think of DNS as a type of phone book for computers. Rather than remember the addresses of every network node you may want to reach, you instead can assign meaningful names to those nodes, and use DNS to translate the names that people like to use into the numbers that computers must use. To contact the other computer, your computer performs a DNS lookup, the result of which is the address of the other computer. Once the address is known, a connection can be made. Performing a DNS lookup is much like using a phone book. You know the name of the other computer, and you want to find the number, or address. You “look up” the name, and the phone book tells you the number that has been assigned to that name. From there, you make your call, or in our case, your connection. How often do new phone books come out? What happens if someone changes his or her phone number before the new phone book is printed? Just like people change their phone numbers, computers change their addresses all the time. Some, in the case of dial-up networks, might change their addresses every day, or even several times a day. If our name-to-number system required that we all pass a new phone book around every day, our networks would come to a standstill overnight, since managing such a database of names and numbers and keeping it current for the number of computers connected together on today’s networks is impossible. DNS was designed to be easily updateable, redundant, efficient and, above all, distributed, by using a hierarchical format and a method of delegation. Just like the gateway rule, a DNS server isn’t required to know the names and addresses of every node on our networks. Instead, it’s only necessary for a DNS server to know the names and addresses of the nodes it’s managing, and the names and addresses of the authoritative servers in the rest of the hierarchy. Thus, a particular DNS server is delegated the responsibility for a particular set of addresses and is given the names and addresses of other DNS servers that it can use if it can’t resolve the name using its own information. The hierarchical nature of DNS can be seen in the names commonly used on the Internet. You often hear the phrase dot-com and routinely use domain names when making connections. The first level of our hierarchy contains what are known as the top-level domains (TLDs). Table 1-9 contains a list of the more popular TLDs and their purpose. Table 1-9. Popular Top-Level Domains
A registrar is responsible for managing domain registrations. This means keeping them current, including accepting new registration requests as well as expiring those domains that are no longer valid. An example of a domain would be “apress.com”. Domain names are read right to left, with the leftmost name typically being the host name or name of a specific network node. Thus, a name such as www.apress.com would be translated as “the network node known as www within the domain apress within the TLD .com.” Another node within the same domain might have a name such aswww2.apress.com. The actual names used are up to the discretion of the owner, with the following restrictions:
The TLDs are managed by special domain name servers known as root servers. The root servers are special servers set up in redundant fashion and spread out across the Internet. The root servers are updated twice daily by the registrars. As of this writing, there are 13 root servers. You can see a list of their names, and the organizations responsible for them, athttp://www.root-servers.org. Even though there are 13 root servers, there are actually more than 13 physical servers. The root servers are typically set up redundantly in diverse locations to spread out the load, and in general the closest one to the node making the request is the one that answers the request. Each root server has a list of the active domains and the name servers that are responsible for those domains. Remember that DNS is hierarchical and delegated. The root servers have a list of subordinate domain name servers, each one responsible for one or many domains such asapress.comoryahoo.comorgoogle.com. Thus, the root servers for .com have a list of the servers handling a particular domain. A request for that particular name is handled by the server responsible, not by the root servers. Further delegation is possible, because a company or other organization can have its own domain name servers. Let’s look at an example. You would like to visit the Apress website to download the source code used in this book. Putting everything we’ve discussed so far in this chapter together, that means your web browser is the client application, and the web server at Apress is the server application. You know that to make a successful connection, you need four pieces of information: source address, source port, destination address, and destination port. You know from your list of reserved ports that web servers are typically available on port 80, and you know that your client application can use any port it likes as the source port for the request, as long as the port isn’t already in use on your own computer. You also know your own address. Thus, the only thing you need to determine before making your TCP/IP connection and web page request is the address of the web server that is accepting requests for the Apress website. To get the address, you’ll perform a DNS lookup onwww.apress.com. Note that the lookup happens transparently to the user and is performed by the client application, or the application “making the call.” The goal is to translate the namewww.apress.cominto an address that your web browser can use to make its network connection. In this case, the name lookup happens in a series of steps:
The domain name system is transparent and public. You can make DNS queries in a number of different ways, from using thehostandwhoiscommands on your Linux system to using any of the web-based query sites. Let’s walk through the query process forapress.comthat we just described, using the command line. To query the root name servers for information, you usewhois: [user@host user]$ whois apress.com After the whois command executes, you’ll see output that looks like this: Domain Name: APRESS.COM The information is self-explanatory. You see that the registrar used to register the domain name is Network Solutions, and you see that the domain was registered in 1998 and is paid up through 2007. This is the information held at the TLD level—it still doesn’t tell you the IP address of the web server, which is what you need. The information you do have, though, includes the names and IP addresses of the name servers delegated to handle further information for apress.com, namelyauth111.ns.uu.netandauth120.ns.uu. net, with addresses of198.6.1.115and198.6.1.154, respectively. Either one of those name servers can help you find the address of the web server. The next step is to use thehostcommand to make a specific request of one of the name servers. You want the IP address of the machine with the namewww.apress.com: [user@host user]$ host www.apress.com auth111.ns.uu.net Thehostcommand takes two parameters: the name you want to translate into an IP address and the name (or address) of the server you want to use to make the translation. Using one of the name servers returned by thewhois query, you ask for the IP address of the web server, and the name server responds with the IP address65.215.221.149. At this point, your web browser would have the four pieces of information it needs to make a successful TCP/IP connection. Incidentally, you can see the port information for DNS in the name server’s reply shown previously. Note the#53tacked onto the end of the name server’s IP address. As shown earlier in Table 1-3, the port used by DNS is port 53. Thehostcommand can also be used without specifying the name server as a parameter. If you just use the name that you want to translate, you’ll get an abbreviated response with just the IP address, without the other information. You can use thehostcommand to make all sorts of domain name queries by using command-line parameters such as–tfor type. For example, using a type of “MX” will return the IP addresses of the machines handling mail for a given domain name. Using a type of “NS” will return an abbreviated version of thewhoisinformation, listing the name servers themselves. Let’s see which machines handle mail and name serving forlinux.org: [user@host user]$ host -t mx linux.org linux.org mail is handled by 10 mail.linux.org. The two queries tell you that mail for addresses in thelinux.orgdomain is handled by a machine namedmail.linux.org. Likewise, the name servers forlinux.orgare listed. If you wanted to send mail to someone atlinux.org, you would use the name server information to resolve the namemail.linux.org into an IP address and make your connection from there. A list of common DNS record types and their purpose is shown in Table 1-10. Table 1-10. Common DNS Record Types
Table 1-10. Common DNS Record Types (continued)
As you can see, DNS information is public information, and you can easily obtain it once you know what to look for and which commands to use. On your Linux system, use the command to get more information on and . Older systems use a utility called , which performs essentially the same functions as It’s also possible to have private DNS information, since any Linux system is capable of acting as a name server. Many companies and organizations use both private, or internal, DNS and public, or external, DNS. Internal DNS is used for those machines that aren’t available to the public. Summary In this chapter, we discussed the basic ingredients for today’s popular networking technologies. Here’s a summary of what we covered:
|
/ 22