Note: Some of this will be really basic for a lot of folks, but bear with me — in looking at the entire system as a system, there are going to be parts of each piece you’ll already know, and other parts you don’t know.
Let’s begin where most users will recognize they’re interacting with the Internet — by opening a web page in their browser. In the end, you’re trying to retrieve a set of files that a piece of software on your local computer (your web browser) will display as a web page. But let’s begin with what you type into the location bar in your browser.
The location you type in is called a “uniform resource locater,” or URL; it represents either a file or a service someplace on the Internet. It’s important to note the file or service here, as you’re actually looking for a web server here — a service — but you’re also looking for a file (or a set of files). We’ll talk about the format of this file a little later (mostly in the context of standards bodies); for now, just think about this entire transaction in terms of transferring a file from a remote computer to your local computer using some fancier-than-average transfer “stuff.”
The first question we need to deal with is — what does the browser do with that “www.ericsson.com” string? The string is, in real world terms, something like the name of a business. If I were looking for a specific hamburger joint in my neighborhood (Little Bits!), then I might look in a local phone book. I wouldn’t use a phone book that classifies things by the type of business (commonly called the “yellow pages”), but rather a phone book that lists businesses by their name (commonly called the “white pages”). Search engines and directories are really the yellow pages of the Internet; the Domain Name System (DNS) is the white pages.
What the local computer wants to know is the address of the server you’re trying to reach (in this case, ericsson.com). Assuming a nice fresh start (no caching!), the browser asks the local operating system (OS) for this information, and the local OS will form a DNS query, asking for the address of “www.ericsson.com.” Obviously the local OS needs to know the address of a DNS server; we’ll bypass this problem for the moment.
Let’s look at what happens when this query arrives at the local server (again, assuming there is nothing cached). The local DNS server, normally called a caching name server. We’ll assume this server is also a recursive server, since most of them actually are. The diagram embedded here illustrates the process of finding the address of a server on the Internet based on the name typed into the location bar in the browser. Step 1 in the diagram is the initial query from the local OS towards the caching server.
After receiving this query, the caching server examines its local cache, and determines it doesn’t have an entry for www.ericsson.com. So this server examines the last section of the name in question and determines it belongs in the .com domain. A domain is actually nothing more than a section of the DNS name — we often use domains and subdomains, but subdomains are completely relative to the domain your in. This gets really confusing really fast, so we’ll just use domain throughout here.
In fact, let’s go so far as to say the caching server doesn’t even know how to reach the top level domain (TLD) server for the .com domain, so the first step is to figure out where to send queries about com. To get this information, the caching server sends a query to one of the thirteen root servers scattered throughout the Internet; this is step 2 in the diagram. The root server returns the address of the TLD server for .com in step 3. With this information in hand, the caching server builds a query for ericsson.com and sends it to the .com TLD server, step 4 in the diagram. In step 5, the TLD replies with the location of the authoritative name server for ericsson.com.
Let’s assume this answer is something like, “contact ns1.ericsson.com for information about ericsson.com.” We just hit a circular reference, didn’t we? What now? There are two answers to this problem; the first, and simplest, is for the domain name owner to make certain there is more than one authoritative server available for the domain, some of which (at least) are in some other domain than the domain they’re acting as the authoritative server for. In other words, you might contract with your service provider, or a domain name service provider (such as Verisign), to manage a server in some domain that isn’t in the actual domain being served (such as verisign.com).
Another option is to put glue records in the entry for ericsson.com at the TLD. In this case, the domain owner (ericsson.com) adds extra information to the DNS record at the .com TLD server, so it returns not only the name of the authoritative server (in this example, ns1.ericsson.com), but also the address of the authoritative server. This breaks the loop without involving yet another service provider.
Now that the caching server knows how and where to reach the authoritative server, it sends a query asking where www.ericsson.com is (step 6 in the diagram). The authoritative server replies with the correct address to the caching server (step 7), which then caches the entry in its local database, and finally returns the address of www.ericsson.com to the host (step 8).
We’re now finally ready to send our first IP packet towards www.ericsson.com — but before we get there, we’re going to spend a little more time in the DNS system, looking at how the DNS system works as a business. Who pays for what, and why? Ultimately, of course, you as the end user pay for all the equipment and management of the DNS system, but let’s see how that works in a little more detail before we move on to routing.