Fundamentals (of Linux Networking) - The Domain Name System (Page 8 of 8 )
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
TLD | PURPOSE |
.com | Commercial use |
.net | Commercial use, though originally for use only by network |
| | service providers |
.org | Noncommercial use by organizations and individuals |
.mil | Military use |
.edu | Educational institution use |
.gov | Government use |
The six domains in Table 1-9 are the original TLDs. In recent years, as the Internet became more and more popular, other TLDs were created, such as .biz, .name, .info, .pro, .coop, .aero, and .museum. In addition, every country in the world is assigned its own TLD, which is a two-letter English designation related to the country name. For example, the country TLD for the United Stated is .us, while the country TLD for Ireland is .ie and the country TLD for China is .cn. Each TLD is managed by a , an organization that handles registration of domain names within a particular TLD. For some TLDs, such as .com, .net, and .org, there are many registrars. For others, such as .gov or .mil, there is only one.
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:
- Names are restricted to letters and numbers, as well as a hyphen.
- Names cannot begin or end with a hyphen.
- Not including the TLD, names cannot exceed 63 characters.
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 browser queries one of the root servers for .com and asks for the IP addresses of the domain name servers (there are usually two, a primary and a backup) managing the domain named “apress”.
- The root server consults its database for a name matching “apress” and, if found, replies with the list of IP addresses of the domain name servers delegated to handle those requests.
- The browser queries one of the servers in that list and asks it for the IP address of the network node with the name of “www”.
- The domain name server managing the domain named “apress” consults its database for the name “www” and, if found, returns the IP address associated with that name.
- If the browser receives an answer from the domain name server with the IP address forwww.apress.com, the browser makes a connection to port 80 at that IP address and requests the web page.
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
Registrar: NETWORK SOLUTIONS, INC.
Whois Server: whois.networksolutions.com
Referral URL:
http://www.networksolutions.com
Name Server: AUTH111.NS.UU.NET
Name Server: AUTH120.NS.UU.NET
Status: ACTIVE
Updated Date: 19-apr-2002
Creation Date: 23-feb-1998
Expiration Date: 22-feb-2007
Registrant:
Apress (APRESS-DOM)
2560 Ninth Street
Suite 219
Berkeley, CA 94710
US
Domain Name: APRESS.COM
Administrative Contact, Technical Contact:
Apress (23576335O) wanshun_tam@apress.com
2560 Ninth Street
Suite 219
Berkeley, CA 94710
US
510-549-5930 fax: 123 123 1234
Record expires on 22-Feb-2007.
Record created on 23-Feb-1998.
Database last updated on 18-Jan-2004 22:43:05 EST.
Domain servers in listed order:
AUTH111.NS.UU.NET 198.6.1.115 AUTH120.NS.UU.NET 198.6.1.154
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
Using domain server:
Name: auth111.ns.uu.net
Address: 198.6.1.115#53
Aliases:
www.apress.com has address 65.215.221.149
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.
[user@host user]$ host -t ns linux.org linux.org name server ns.invlogic.com. linux.org name server ns0.aitcom.net.
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
TYPE | NAME | PURPOSE |
A | Host Address | A 32-bit IP address identifying a specific |
| | host. |
CNAME | Canonical Name | A name used as an alias for an A record. |
MX | Mail Exchanger | The name of the host acting as a mail |
| | exchanger for the domain. |
NS | Name Server | The name of an authoritative domain name |
| | server for this domain. |
Table 1-10. Common DNS Record Types (continued)
TYPE | NAME | PURPOSE |
PTR | Pointer | A record that points an IP address to a name. |
| | This is the reverse of an A record. |
SOA | Start of Authority | A multiple-field record specifying particulars |
| | for this domain, such as timeouts. |
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:
- In general, networks are either packet-switched or circuit-switched, with the Internet being an example of a packet-switched network.
- All networks need a common, physical medium to use for communications, the most popular of which is Ethernet. Ethernet uses a system of frames containing header and data portions.
- Networks require the use of addressing so that one network node can find another network node. Addressing takes different forms, from MAC addresses used to identify physical network hardware interfaces to IP addresses used to identify virtual software addresses used by the TCP and IP network protocols.
- The gateway rule means that a node does not need to know how to reach every other node on a network. It only needs to know how to reach the nodes on its own network, and how to reach the gateway between its own network and all other networks.
- Using a system of protocol layering and encapsulation, IP and TCP “wrap” and “unwrap” each packet of header and data information as it travels up or down the protocol stack at each endpoint of the connection.
- TCP/IP networks use the client-server model, in which the source of the communication is known as the client, and the server is the destination. The server is the network node providing services consumed by the client. Depending on whether the communication is a request or a response, the roles of client and server may change back and forth.
- Because people find it easier to remember names instead of numbers, networks use name translation systems to translate familiar names into the actual IP addresses of the other network nodes. The most popular naming system is the Domain Name System (DNS), which is a collaborative, distributed, hierarchical system of managing namespaces where specific responsibilities for certain domains are delegated from root servers to subordinate servers.
/ 19 
